0

I'm experiencing boot errors after a recent install of Multiple OSes. I noticed the long boot times watching the boot loading code go by and getting apparently stuck on a start job that takes 90 seconds before finally kicking out to a fail that says [Timed] and [delay], hard to read the whole line as it runs off the screen continuing to boot. Its a delay on nearly all OSes on the machine during boot.

I ran journalctl -p err and found the following:

Jan 03 12:37:48 z-Inspiron-N5010 systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-d85dac55\x2d2393\x2d412a\x2d8080\x2d8cb24061f7b0.device.
Jan 03 12:42:51 z-Inspiron-N5010 systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-d85dac55\x2d2393\x2d412a\x2d8080\x2d8cb24061f7b0.device.
Jan 03 12:48:34 z-Inspiron-N5010 systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-d85dac55\x2d2393\x2d412a\x2d8080\x2d8cb24061f7b0.device.
Jan 03 13:06:28 z-Inspiron-N5010 systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-d85dac55\x2d2393\x2d412a\x2d8080\x2d8cb24061f7b0.device.
z@z-Inspiron-N5010:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda14 during installation
UUID=a78d855d-8b99-4920-8cf6-16dea3ff5d56 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda15 during installation
UUID=9c7b545a-642c-44ee-b9e6-f440b5aec755 /home           ext4    defaults        0       2
# swap was on /dev/sda5 during installation
UUID=d85dac55-2393-412a-8080-8cb24061f7b0 none            swap    sw              0       0
z@z-Inspiron-N5010:~$ 

After parsing the Timed Out Device dev-disk-by\x2duuid-d85dac55\x2d2393\x2d412a\x2d8080\x2d8cb24061f7b0.device. Extracting the x2d from each separated by "\" I come up with: UUID=d85dac55-2393-412a-8080-8cb24061f7b0 Comparing that with the fstab file it is easy to see the device related to the error is /dev/sda5. I then ransudo blkid /dev/sda5 and determined that partition actually is assigned UUID=bb3c892f-7584-42a3-a35a-0f0dfd517222

I realized the last OS installed was Debian 10 on Jan 03 2020. I also remembered the installer asked me to confirm that the partitions I defined / and /home were going to be formatted but it added swap on the list as well.

I booted into the Debian OS and ran blkid as well as looked at the Debian fstab file as shown below two swaps are defined - not manually, the installer made some error.

root@debian:/home/x# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda14 during installation
UUID=199f052c-ccf7-4b75-874c-de83d1c37300 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda15 during installation
UUID=ab46faec-c492-403d-8452-c6cd79af1ca1 /home           ext4    defaults        0       2
/dev/mapper/fedora_localhost--live-swap none            swap    sw              0       0
# swap was on /dev/sda5 during installation
UUID=bb3c892f-7584-42a3-a35a-0f0dfd517222 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
root@debian:/home/x#

Somehow Fedora swap and the shared /dev/sda5 swap are in Debian's fstab? All systems boot, all are delayed by 90 secs just on the swap timeout. I am playing around with a few distros since Ubuntu 16.04.6 is nearing ESM. Once I decide which OSes to keep and remove I may still have problems. Any technical help would be appreciated and thanks.

5
  • Why would each OS have a unique UUID for the shared swap? That seems wrong to me, and I'm used to sharing swap space (they have the same UUID otherwise they'd timeout waiting for the UUID to turn up that never will...) We don't support non-Ubuntu's here, and the only OS you mention is Fedora - askubuntu.com/help/on-topic
    – guiverc
    Jan 4, 2020 at 6:59
  • @guiverc My main OS is Ubuntu 16.04.6 which I edited in the title, I also use Ubuntu 19.10, Mint 19.3, Zorin 15, Debian 10, and Fedora 31, all on the same machine. I thought each OS defined its own UUID for the same dev/sdaX where X=number of the partition on the disk. I can edit the post to show the different numbers if that is necessary. Anyway thank you for Ubuntu Topic reminder. Jan 4, 2020 at 7:32
  • You want (need) the UUID in each fstab to match a partition which has that UUID to be used; on subsequent installs I either don't have it using swap (if the installer insists on formatting the swap partition thus changing UUID) & manually add swap later myself, OR extremely rarely (ie. when I forget it) let it format the swap, then correct all other systems to use the new UUID. This assumes it's not encrypted swap (it complicates things immensely) and I'm ignoring swap files (the easy way with encryption).
    – guiverc
    Jan 4, 2020 at 10:53
  • 1
    @guiverc Based on your last comment I began to research the error more thoroughly. I found this and was able to solve the UUID issue for all my OSes. If you would like to provide an answer to this question I'll be happy to give you the credit. Or I can answer it and bump up your referred answer, which ever you like is fine with me. Jan 7, 2020 at 6:32
  • I'm happy for you to do it. It'll possibly be better for future users that way, as you can be more specific in what worked for you. Thanks for option & credit; appreciated :)
    – guiverc
    Jan 7, 2020 at 6:41

1 Answer 1

1

During my research to solve my problem I came across this answer by guiverc which helped me understand what happened.

This problem was caused by a mismatch of the UUID assigned to the swap partition. Specifically the mismatch occurred between the Actual UUID assigned to swap and the UUID defined in /etc/fstab This was caused by multiple OSes installed on the same HDD on multiple logical partitions. The OSes were installed with the intent to share a swap partition, /dev/sda5 on my machine.

The swap partition was initially formatted as swap on /dev/sda5 a logical drive inside the second partition /dev/sda2, an extended partition, by the first OS installed, Ubuntu 16.04.6. The UUID assigned by Ubuntu 16.04.6 at that time also matched the UUID defined as swap in /etc/fstab. For completeness sake /dev/sda6 and /devsda7, / and /home were also assigned UUIDs and defined in /etc/fstab for Ubuntu 16.04.6.

Once the second OS installer defined and formatted / and /home it also reformatted /dev/sda5 as swap...AGAIN. In so doing the swap was assigned a new UUID which matched swap UUID defined in /etc/fstab of the second OS but now mismatched the first OS. Again for completeness sake /dev/sda8 and /devsda9, / and /home respectively were also assigned UUIDs and defined in /etc/fstab This same order of operations occurred for each of the OSes installed on this multiboot system.

In each new install the swap was reformatted and assigned a new UUID for that particular OS install.

The answer becomes self evident. The /etc/fstab of each OS installed needs to be edited to define the the current or last UUID assigned to swap. In other words every OS needs to use the same current swap UUID.

1)From within each OS installed open a terminal and type the following.

2) sudo blkid /dev/sda5 - to get the current UUID assigned to swap

3) sudo gedit /etc/fstab - this opens the file with admin privilage to edit

4) Inside /etc/fstab find the UUID=d85dac55-2393-412a-8080-8cb24061f7b0 defined for swap and replace it with the current UUID found in step 2 above. In my case current UUID is UUID=bb3c892f-7584-42a3-a35a-0f0dfd517222 as shown in the Debian /etc/fstab output in the question above. As stated in the question Debian was the last OS to be installed on my machine and therefor the last time the swap was assigned a new UUID aka the current UUID.

5) Save the file and open the next OS that needs to be configured properly repeat steps 2-5 until finished.

After following these steps I no longer incur the 90 sec timeout during boot as described in the question above.

*note: I commented out the odd Fedora swap defined in the Debian /etc/fstab just by adding the # in front of that line in that fstab and saving the file.

e.g. # /dev/mapper/fedora_localhost--live-swap

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .