Description of problem: grub.cfg entries have e.g. linuxefi /boot/vmlinuz-4.6.2-desktop-2.mga6 root=/dev/sdb4 ro splash quiet noiswmd resume=UUID=1097bb8c-3820-4b3a-b796-b417c9aa56d Note the "root=/dev/sdb4" This breaks boot if another HD is added and the device enumeration changes. At one time the root=/dev/... was needed, but now I find that simply removing it allows the system to boot normally despite the root having moved to /dev/sdc. Since grub2 uses UUIDs by default there should really be no need to specify a device by ID as well - it sort of defeats the object. Can anyone (Colin, tmb ?) comment on this? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
I don't know what happen. When running update-grub2, the right UUID entries are used. Looks like it mis used /etc/fstab while installing.
CC: (none) => thierry.vignaudBlocks: (none) => 416
My bad - this was entry in my 'master' causing the issue not real system :\ Closing invalid.
Status: NEW => RESOLVEDResolution: (none) => INVALID
I have just hit this again and it seems to be the installer that creates menu entries with device IDs. I just made a clean net-install from cauldron and backed up the grub.cfg from the newly installed system. I then ran update-grub2 and took a diff of the two grub.cfg files. The difference is the same for all entries so here is just one as example: -linuxefi /boot/vmlinuz-4.6.3-desktop-1.mga6 root=/dev/sda4 ro splash quiet noiswmd resume=UUID=1097bb8c-3820-4b3a-b796-b417c9aa56d8 vga=791 + linuxefi /boot/vmlinuz-4.6.3-desktop-1.mga6 root=UUID=93ccb9dc-ef4e-401a-9e24-c4ee130f08ec ro splash quiet noiswmd resume=UUID=1097bb8c-3820-4b3a-b796-b417c9aa56d8 vga=791 As you can see the original from the installer uses root=/dev/sda4 where the one created by update-grub2 uses root=UUID=.... I don't think this is relevant, but the install was on btrfs / with "Don't touch MBR/ESP", otherwise it was a default Plasma install to real hardware.
Resolution: INVALID => (none)Status: RESOLVED => REOPENED
Created attachment 8084 [details] full diff of grub.cfg from install and from update-grub2 in system
AFAIC that's a grub2's grub2-mkconfig bug. /etc/fstab is the same in the installer & in the rebooted system
You could do the installer up to the point it offers to reboot, then: - got to tty2 - chroot /mnt - cp /boot/grub2/grub.cfg{,.bak} - update-grub2 if it's broken, you can run "urpmi strace" then "strace -e file -f /bin/update-grub2" in order to find out if it misses something in the install chroot
All went OK up to the strace. The original grub.cfg in the chroot used /dev/* and running update-grub2 in the chroot produced the same. Running update-grub2 under strace (which was installed) did not give me any clues as it all scrolled past and there was not much scrollback available when it finished. I re-ran the installer (opting to upgrade the same installation) and did the same again with the intention of getting a file output from strace, however this time grub.cfg had UUIDs. I have spent hours and am giving up for today. I will have another go tomorrow some time.
The goal is to redirect strace to some /tmp/ file and the browse it with less
It only seems to happen if one doesn't click the "bootloader" button in summary
Ah - that's maybe why I have been struggling to reproduce as I always do in order to "not touch ESP" :\
Maybe grub2-mkconfig got confused by being run in a chroot (discrepancy between /etc/fstab & /proc/mounts)?
CC: (none) => mageia, tmb
Created attachment 8195 [details] /etc/grub.d/10_linux debug patch
Created attachment 8196 [details] sh -x grub2-mkconfig output diff (w/ & w/o previous patch)
Created attachment 8197 [details] commands output one can see the uptodate output of blkid (which matches /etc/fstab) doesn't match outdated /dev/disk/by-uuid/ contents
This discrepancy is what cause grub.cfg to contains root=/dev/vda6 instead of root=UUID=... Colin, is there a way to make those links be updated? Some kind of udevadm command?
Source RPM: grub2/dracut/systemd => systemd, grub2
@Colin: you can reproduce all of this by doing an install where you recreate partitions, then go to summary, etc. But before rebooting, go to tty2, run "chroot /mnt" and you'll see that /boot/grub2/grub.cfg doesn't use uuid for root fs, but root=/dev/... instead. You can redo the above change in /etc/grub.d and check my findings... I used an autoinst with clearall + auto_allocate + partitions so you should be able to reproduce by clearing the whole disk/...
Created attachment 8198 [details] my autoinst file in order to ease testing, to be used with eg: "auto_install=http://192.168.0.10/auto_inst.cfg.pl"
Summary: grub.cfg entries include /dev/sdXY which breaks boot if devices change order. => grub.cfg entries uses "root=/dev/sdXY" (instead of "root=UUID...") which breaks boot if devices change order
@Barry: one solution would be to patch /etc/grub.d/10_linux so that the UUID check (the one verifying the presence of /dev/disk/by-uuid/foobar) is skipped if DURING_INSTALL is set. Can you do that in the meantime? Thanks
OK I will take a look - have a good holiday ;)
Created attachment 8207 [details] proposed patch Could someone please check that this patch is likely to achieve the desired result (as suggested by Thierry) before I push it? Thanks, Barry
Comment on attachment 8207 [details] proposed patch I think that's wrong - too many inversions, my brain hurts :\ I think it should be: ... + || ( ! test -e "/dev/disk/by-uuid/${GRUB_DEVICE_UUID}" && [ "x${DURING_INSTALL}" != "x1" ] ) \ We need false (from the bracketed expression) if we are in the installer whatever the test says so we drop through to the else. I will think more later - must go.
Yes that now looks right to me. It should now only *not* drop through to 'else' when the uuid check fails and we are *not* in the installer. r1042593 | barjac | 2016-07-19 18:11:06 +0100 (Tue, 19 Jul 2016) | 3 lines - Patch to ignore test of disk/by-uuid when in installer - workaround for Mga#18780 ( grub.cfg entries use root=/dev/sdXY instead of root=UUID...) Submitted.
Created attachment 8213 [details] report_bug from install using grub2-common-2.02-0.git10457.11.mga6 @Thomas Is there any reason why $DURING_INSTALL would not be visible to grub2 in the installer? ...or is my logic flawed?
Forgot to mention that the amended patch in grub2-common-2.02-0.git10457.11.mga6 failed to fix this issue.
@Thierry Hope you had a good break. I tried with this but $DURING_INSTALL seems invisible to grub2 (or indeed to me) in the installer chroot (or the installer). So, the current situation is unchanged except for a non-working patch in grub2. I checked at various points in an install and could not see $DURING_INSTALL so I'm obviously missing something here.
Is this bug still valid?
Assignee: bugsquad => zen25000CC: (none) => marja11
(In reply to Marja van Waes from comment #26) > Is this bug still valid? I would imagine so as nobody updated this bug with news of a fix and Colin never replied to Thierry (here). If you or any testers have a clean fresh install of cauldron: cat /boot/grub2/grub.cfg|grep "=/dev/" ... will check - any output will show it's still valid. Note that a kernel or grub2 update or running update-grub2 will have removed the evidence.
CC: (none) => silvershadesa
Assignee: zen25000 => bugsquad
CC: (none) => fri
New installation of Mageia 7 and Cauldron uses UUID for root and swap device as long as nothing is modified in DrakX default setup. Even if user choose custom partitioning, generated fstab uses UUID and so does Grub2. I think this should be closed.
Resolution: (none) => FIXEDCC: (none) => ouaurelienStatus: REOPENED => RESOLVED