90 second delay on boot

Dai_trying · 2016-02-22 13:46

This appears to be a problem for many users who are using more than on version of linux, I have suffered too with this issue and thought I would share a relatively simple fix for everyone. Before I start, this is NOT a q4os issue it can happen with any distro you use but will usually not affect the last one that was installed as it is usually caused by the installation reformatting the swap partition and it therefore gets a new UUID.

Firstly once your computer has started issue the command (from konsole)

sudo blkid | grep swap

This will return something along the lines of the below example

/dev/sda5: UUID="af789943-95ec-4699-bd7d-4378289ef13d" TYPE="swap" PARTUUID="d36c0e68-05"

Next type

cat /etc/fstab | grep swap

which should give you something like the below example

UUID=af789943-95ec-4699-bd7d-4378289ef13d	none	swap	sw	0	0

Notice in this example the UUID of the first example matches the UUID in the second example
if yours holds two different values this must be changes in the file /etc/fstab

WARNING THIS IS A VERY IMPORTANT SYSTEM FILE! TAKE CARE WHEN EDITING!
i use nano as I find it easiest to use

sudo nano /etc/fstab

And then enter the UUID value from the blkid command in place of the wrong UUID in the fstab.
CTRL + X then y then enter will exit and save the file.
Reboot and all should be well

Please note this is not the only reason a system can have this delay, but in my experience it is the most common

Dai

A quick bash one-liner to test would be

if [[ `sudo blkid | grep swap | awk '{print $2}' | tr -d '"'` == `cat /etc/fstab | grep swap | awk '{print $1}'` ]]; then echo "Swap values appear ok"; else echo "Swap values are INCORRECT"; fi

This assumes you only have one swap partition and only 1 entry in fstab for swap

Last edited by Dai_trying (2016-02-22 16:14)

Dai_trying · 2016-02-22 20:12

I figured a couple of posters have had the issue so it would stand to reason others may also have suffered the same thing. And as many people will be using a single pc/laptop for testing, multiboot issues will crop up more often.

Basil · 2016-02-22 22:40

Solid thinking, Dai #1, and thanks for the suggestion. I have just done what you propose, and will shortly be rebooting to taste the pudding. If it doesn't work, I'm in trouble; if it does work, I'm in confusion, because...:
If it works, it means that Q4OS on booting checks /etc/fstab for the UUID of the drive holding the swap partition, in my case popularly aliased as sda5. since the physical drive is regarded as sda by all the Linux versions on it or booting off CD (eg Puppy) and the partition table is common to all those distros, as can be confirmed by running GParted or similar under the various distros. But the UUID assigned to sda as reported by blkid is that assigned according to some algorithm by whichever distro last did something specific and highly-privileged to the partition table. (Space left here for educated explanation in Welsh words of less than 23 characters and having more than 0 vowels please.) Which distro automatically writes that UUID into the /etc/fstab on its own filesystem.

And seeks to use that UUID to identify the swap partition if any when it is being booted

Which is fine for it, but what about the other distros that have, in THEIR /etc/fstab files, the UUIDs that THEY calculated but have been superseded by the newcomers? When they boot, they can't find a swap partition because that's now assigned in some higher structure to a new UUID for the same piece of spinning rust that they fondly assigned a UUID to at some previous time...

The implication would be that we multibooters may often be in a situation where we need to update the numerous /etc/fstab files on our HDU(s) to bring them into line with the single UUID reported by blkid , if we want them all to enjoy swap privileges. Or am I even more confused than I thought I was?

Oh, and we should be sure to set swapon for the swap partition in GParted for each distro, or is it not necessary?

Now I'm going to send this off, then try rebooting Q4OS after the other 2 distros, with the help of the rehurbished /etc/fstab. Just thought I'd send this first, in case you never hear from me again. I've appreciated your help.

Dai_trying · 2016-02-22 22:51

@ Basil : Just to clarify, the UUID of the disk is created when the drive/partition is formatted and never changes, that is unless it is reformatted. I did notice from one of your posts that you have debian jessie installed, and that is one of the offenders in this case, as it will automatically format the swap partition unless you tell it not to. I am only guessing that you installed debian after q4os, and that it reformatted the swap, leaving q4os with outdated information in the fstab file.
I hope you will be back soon

Dai

EDIT : and swap will automatically be on if entered in fstab

Last edited by Dai_trying (2016-02-22 22:54)

Basil · 2016-02-22 22:57

OK, it worked, and I'm back, 90 seconds earlier than would normally have been the case. And having reread Dai #1, I see that the dangerous operation which generates a new UUID for the entire disk is reformatting the swap partition. As far as I can remember, I did this a while back while resizing partitions in a general cleanup and rationalization operation.

Thank you! Now to see how many other problems have been affected by doing this.

Dai_trying · 2016-02-22 23:10

You are welcome, I'm glad it worked

Dai

Q4OS Forum

#1 2016-02-22 13:46

90 second delay on boot

#2 2016-02-22 20:12

Re: 90 second delay on boot

#3 2016-02-22 22:40

Re: 90 second delay on boot

#4 2016-02-22 22:51

Re: 90 second delay on boot

#5 2016-02-22 22:57

Re: 90 second delay on boot

#6 2016-02-22 23:10

Re: 90 second delay on boot

Board footer