SOLVED: update-grub produces improper grub.cfg

[anigramp]

Greetings!

I'm happily running the latest Mint LMDE XFCE, that has worked fine for several months. Marvellous achievement!

Err, except the partition I put it on is a bit small (8Gb).

I have a free 12Gb partition on the same drive, so I thought I'd redeploy LMDE there. I copied everything over with rsync, and turned to updating the boot loader.

I didn't do anything special, just ran update-grub. Yes, it sees the new Mint on the 12G partition.

Code: Select all

clip default # update-grub
Generating grub.cfg ...
Found background image: linuxmint.png
Found Debian background: linuxmint.png
Found linux image: /boot/vmlinuz-3.2.0-2-amd64
Found initrd image: /boot/initrd.img-3.2.0-2-amd64
Found Linux Mint Xfce Edition (1) on /dev/sda1
done

Restarted, selected the new partition, it booted OK... but it's still using the smaller partition for /

Looking at grub.cfg, I see the following (excerpted):

Code: Select all

### BEGIN /etc/grub.d/10_linux ###
menuentry 'LinuxMint GNU/Linux, with Linux 3.2.0-2-amd64' --class linuxmint --class gnu-linux --class gnu --class os {
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(/dev/sda,msdos3)'
        search --no-floppy --fs-uuid --set=root c36dccca-7fcb-4508-9f20-100c6ff9f83e
        echo    'Loading Linux 3.2.0-2-amd64 ...'
        linux   /boot/vmlinuz-3.2.0-2-amd64 root=/dev/sda3 ro  splash vga=773 quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-3.2.0-2-amd64
}
menuentry 'LinuxMint GNU/Linux, with Linux 3.2.0-2-amd64 (recovery mode)' --class linuxmint --class gnu-linux --class gnu --class os {
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(/dev/sda,msdos3)'
        search --no-floppy --fs-uuid --set=root c36dccca-7fcb-4508-9f20-100c6ff9f83e
        echo    'Loading Linux 3.2.0-2-amd64 ...'
        linux   /boot/vmlinuz-3.2.0-2-amd64 root=/dev/sda3 ro single  splash vga=773
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-3.2.0-2-amd64
}
### END /etc/grub.d/10_linux ###

That's for the original LMDE on the 8G partition (still working fine).

And here:

Code: Select all

### BEGIN /etc/grub.d/30_os-prober ###
menuentry "LinuxMint GNU/Linux, with Linux 3.2.0-2-amd64 (on /dev/sda1)" --class gnu-linux --class gnu --class os {
        insmod part_msdos
        insmod ext2
        set root='(/dev/sda,msdos1)'
        search --no-floppy --fs-uuid --set=root 322e43f7-863c-4c55-af8e-7c38b7849e25
        linux /boot/vmlinuz-3.2.0-2-amd64 root=UUID=c36dccca-7fcb-4508-9f20-100c6ff9f83e ro quiet
        initrd /boot/initrd.img-3.2.0-2-amd64
}
menuentry "LinuxMint GNU/Linux, with Linux 3.2.0-2-amd64 (recovery mode) (on /dev/sda1)" --class gnu-linux --class gnu --class os {
        insmod part_msdos
        insmod ext2
        set root='(/dev/sda,msdos1)'
        search --no-floppy --fs-uuid --set=root 322e43f7-863c-4c55-af8e-7c38b7849e25
        linux /boot/vmlinuz-3.2.0-2-amd64 root=UUID=c36dccca-7fcb-4508-9f20-100c6ff9f83e ro single
        initrd /boot/initrd.img-3.2.0-2-amd64
}
### END /etc/grub.d/30_os-prober ###

Silly os-prober has picked up the UUID of the 8G partition (root=UUID=c36...)! And furthermore, os-prober doesn't honour the setting in /etc/default/grub which says:

Code: Select all

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

I suppose I could use some rescue tool to write a valid boot loader, but I'd like to keep it in-house as it were (and help resolve bugs, if that's what's causing this).

Any suggestions?

[viking777]

I can't work out why that has happened, but if it were me, I would be tempted to stop the boot at the grub menu, highlight the msdos1 entry, press e to edit it and change the root=UUID line to read the same UUID as the set=root line above it and then press Ctl/x and see if it boots. If it does you could manually edit grub.cfg to the correct UUID (but that edit will be overwritten the next time update-grub is run so it doesn't do much really except satisfy my curiosity).

As for the GRUB_DISABLE_LINUX_UUID=true line in /etc/default/grub, I don't know why they bothered putting it there, it never has done anything that I can detect. You probably hate UUID's as much as I do, but partition references aren't much help (they change). Disk labels are the only sensible solution, but I don't know how to force tools like 'update-grub' to use those, that is why I still chainload all my grub2 partitions from grub1 it makes so much more sense to me.

To solve your problem I would wimp out and use something like boot-repair http://sourceforge.net/p/boot-repair/home/Home/ I was trying it out only this morning (on an old computer, I am not a fool ) It is an incredibly competent tool and the way it differs from cli tools like 'update-grub' is that it completely purges grub before reinstalling/reconfiguring it - and that technique works very well.

[titetanium]

Hi,

Did you update the /etc/fstab file on the new partition to show that / points to the new partition instead of the old one? I think that's the problem.....

[anigramp]

Aha! No I didn't. Good catch, that would be important later, but didn't affect it straight away... only matters when I'm booting the kernel that the fstab belongs to, still a GRUB problem.

I had to follow viking777's suggestion and edit the GRUB command line to identify the correct partition. That boot WAS from the right partition, worked fine! Then it was straightforward to redo update-grub and grub-install, and I'm away!

Many thanks guys, very helpful tips. Solved!