Mkinitrd command launched

Hi! I made a new swap partition and i received “a start job is running for /dev/disk/by-uuid/…” for it. I solved this problem (changing /etc/fstab file and grub.cfg) but when i was attempting to fix it i launched mkinitrd. I have not noticed nothing strange, but i’m afraid that i’ve done something can create problems in future. Is this the case? What could i have done? Problems with modules?

Running “mkinitrd” (as root) should not cause problems. It is a needed step after some system changes.

After creating a swap partition, you may also need to update the bootloader. Look for the “resume=” parameter on the kernel command line. That should reference the swap partition, which is where a hibernation image is usually saved.

Indeed i had solved changing the “resume=” uuid reference from grub.cfg, but before that i had tried with mkinitrd and i was afraid to have done something bad. Now i’m sure it’s all ok, thanks!!

A next time, simply use YaST to make such changes and it will do all the necessary things for you.

I suppose not everything is okay.
How did you change /boot/grub2/grub.cfg? Did you modify /etc/default/grub then run sudo grub2-mkconfig -o /boot/grub2/grub.cfg?

If you change /boot/grub2/grub.cfg directly (there’s a warning DO NOT EDIT THIS FILE at the top), then using YaST you may not notice as the resume= parameter gets overwritten. Then you won’t be able to suspend to the new swap partition. Checkout cat /proc/cmdline for the correct UUID.

Also, mkinitrd in this case was unnecessary, it doesn’t contain grub2 data.

You all were right, initially was ok but the problem is still here this morning. This time obviously i’ve not changed directly grub.cfg, so now it seems to be ok.

We call this “learning the hard way”.

I’m glad you now have everything in place.

lol!lol! yes, we ever learn from everything!

???

The “initrd” keeps a copy of the kernel command line

# dracut -f
dracut: Executing: /usr/bin/dracut -f
...
dracut: *** Constructing GenuineIntel.bin ***
dracut: *** Store current command line parameters ***
dracut: Stored kernel commandline:
dracut: rd.driver.pre=i915
**dracut:  resume=UUID=ac73866e-fdf0-4466-b68b-c32207491517**
dracut:  root=UUID=eb7db6fb-09bb-4939-8ac0-ca573914cb78 rootfstype=ext4 rootflags=rw,noatime
dracut: *** Creating image file '/boot/initrd-5.6.4-1-default' ***
dracut: *** Creating initramfs image file '/boot/initrd-5.6.4-1-default' done ***
#

so if hibernation is enabled (i.e. there is a “resume=”-statement in the kernel commandline) the initrd MUST be rebuild when the SWAP-Partition gets a new UUID (because the SWAP-partition is where the hibernation image is usually saved).

Regards

susejunky

TIL, thanks!

How does dracut receives the kernel cmdline? I wasn’t able to find a reference to grub.cfg in mkinitrd/dracut.

I think that’s just from “/proc/cmdline”. It is the command line used for the session where the “initrd” was built.

i must admit that i never investigated this in detail.

I went through

> man dracut

and

> man dracut.cmdline 

The latter mentions /etc/conf.d/ and **/etc/cmdline.d/*.conf **however both directories do not exist on my system.

I doubt that /proc/cmdline of the session in which the initrd was built can be used because when you re-format your SWAP your /proc/cmdline should still contain the old (and now invalid) SWAP reference.

My guess is that dracut reads /etc/default/grub but that is just guessing!

Regards

susejunky

I run a few tests on a VM, I observed that it doesn’t read from /etc/default/grub, but from /etc/fstab. dracut has a --fstab flag although I couldn’t trace (just following source code, not by actual execution) to the exact place passing this flag.

I also removed resume= from the kernel parameters using YaST, resume= is missing from /etc/default/grub yet present in initrd as expected according to the previous test. Hibernation doesn’t work, resume= required to be present at /etc/grub2/grub.cfg, contrary to what online sources say (Arch wiki).

I can confirm this. When i did

# strace -f -o LOGFILE dracut -f

LOGFILE showed NO reference to /etc/default/grub but references to /etc/fstab.

Another “interesting” finding: Although i use “LABEL=SYSTEM_SWAP” in /etc/default/grub and /etc/fstab dracut will always include a “resume=UUID=xxx” in the initrd.

Regards

susejunky