Long Boot Times....

[whatthefunk]

Im experiencing some pretty long boot times lately. Most noticably, after GRUB there is a ten second time period where nothing appears to be happening and there is a blank screen. Here my bootchart:




I think half my problem may be that my swap partition isnt mounting properly. The UUID for swap listed in fstab and the UUID in /etc/initramfs-tools/conf.d/resume is different and both differ from the UUID given by blkid, which seems to be randomly generated each boot. Any ideas?

[GreyGeek]

Turn swap off and reboot to test your theory.

[oshunluvr]

And remove the UUID from fstab and use the device name instead.

[SteveRiley]

I think half my problem may be that my swap partition isnt mounting properly. The UUID for swap listed in fstab and the UUID in /etc/initramfs-tools/conf.d/resume is different and both differ from the UUID given by blkid, which seems to be randomly generated each boot. Any ideas?

I'd be surprised if the UUID keeps regenerating -- that's not supposed to happen.

But, indeed, if the UUIDs in these two files don't match, then boot time can take much longer. Run:

sudo blkid

and then ensure that the entries in both fstab and resume are correct. If you edit resume, then run

sudo update-initramfs -u

[oshunluvr]

Or just use /dev/sdWHATEVER...

[SteveRiley]

I've been convinced by various readings that UUIDs are safer than names based on the bus.

https://wiki.archlinux.org/index.php..._device_naming

This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like /dev/sda and /dev/sdb switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.

[oshunluvr]

Steve, as your own quote points out - "If your machine has more than one SATA, SCSI or IDE disk controller..."

Conversely. it could be construed that if one had only a solo hard drive, UUID's are an unnecessary complication.

In this case, I offered the suggestion as a work-around. However, in a single disk system when one has several partitions and might re-format one from time to time - thus changing the UUID - I find it much simpler and stable to use device names. You can even set GRUB (your Nemesis ) to not use UUID's when scanning during update.

As an owner of such a system - the type where device names change seemingly randomly - UUID's are nearly required...

...or at least remembering to unplug any USB drives before booting!

EDIT: p.s. Besides, you know those those Arch guys are wound a little tight! *


* It's a joke...

[oshunluvr]

I just had a brilliant idea!

What if UUID's were persistent (optionally) at mkfs? A simple cli switch to re-use the current UUID would be cool...

Just a thought.

[SteveRiley]

In general, I favor simplicity, and I would agree that in a single-disk, single-controller system, UUIDs add a layer of complexity. However, in various forums across the 'tubes, I've seen enough reports of partition numbers spontaneously changing that wouldn't have been a problem if UUIDs were used. I suspect complicated multi-boot schemes are the root causes of many of these problems. Or maybe it really is all those silly USB drives still lurking in ports across the land!

[oshunluvr]

Nothing like one of those little thumb drives to ruin a good boot-up!

I will admit when first introduced UUID's were a pain in my a**. Now that I'm prepared for them - I use them.

At least when I leave a thumb drive in and end up at the grub prompt> I need only pull and reset. When I forget to edit and fstab - yikes!

[whatthefunk]

I'd be surprised if the UUID keeps regenerating -- that's not supposed to happen.

But, indeed, if the UUIDs in these two files don't match, then boot time can take much longer. Run:

sudo blkid

and then ensure that the entries in both fstab and resume are correct. If you edit resume, then run

sudo update-initramfs -u

blkid gives this

/dev/sda1: UUID="63d30a64-dce6-4c8d-b608-c363a7f3664d" TYPE="ext4" 
/dev/sda5: UUID="b99dbd41-1e29-4359-b018-ff1813ebd36e" TYPE="ext4" 
/dev/sda7: UUID="9d45888e-2c51-4ba8-ad1b-06d3a0561186" TYPE="ext4" 
/dev/sda8: UUID="a07b32e9-feb5-4516-a60e-3c2b7d5fe186" TYPE="ext4" 
/dev/sdb1: UUID="78bb49c0-a640-43d5-9dff-c03b5d734723" TYPE="ext4" 
/dev/sdb2: UUID="6933927f-497c-4cf6-9b56-25c6fceedeba" TYPE="ext4" 
/dev/mapper/cryptswap1: UUID="94a04e6e-2f2a-4c24-8f61-c4b8f8aee3ff" TYPE="swap"

fstab

UUID=590c695d-64de-4dc1-826a-7c7ee45b2a07 none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

resume

RESUME=UUID=590c695d-64de-4dc1-826a-7c7ee45b2a07

I changed both to match the blkid output and when I updated initrams I got this error:

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.2.0-31-generic
cryptsetup: WARNING: target cryptswap1 has a random key, skipped

[SteveRiley]

Ah, you're using an encrypted swap file? Google says most of the time this error happens along with another one. See LP bug 497110, for instance. Perhaps some of the steps in that bug report will help.

[whatthefunk]

Im not using encrypet swap, but did on a previous install. Something funny happened so that every time I reinstalled, the computer thought swap was encrypted. Got it figured out though. I commented out the swap line in /etc/crypttab. Then I was able to access the partition and format it. I made a new swap file in the partition with "sudo mkswap /dev/sdax" where x is the partition number and then got the correct UUID number from blkid. I put this number into /etc/fstab/ and /etc/initramfs-tools/conf.d/resume updated initramfs, rebooted and the problem is gone. Sped up my boot a bit. Ill post a new bootchart later today.