Debian Bug report logs - #686754
update-grub generates wrong grub.cfg

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Karsten Malcher <debian@dct.mine.nu>

To: submit@bugs.debian.org

Subject: update-grub generates wrong grub.cfg

Date: Wed, 05 Sep 2012 12:28:28 +0200

[Message part 1 (text/plain, inline)]

Package: grub2-common
Version: 1.99-22.1
Severity: important

Hello,

this bug seems only effect additional bootable partitions.
At this time i try to copy my primary installation to a SSD.

When i run update-grub my main partition is generated in the grub.cfg correct as

menuentry 'Debian GNU/Linux, mit Linux 3.2.0-3-amd64' --class debian --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 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
	echo	'Linux 3.2.0-3-amd64 wird geladen …'
	linux	/boot/vmlinuz-3.2.0-3-amd64 root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro  quiet
	echo	'Initiale Ramdisk wird geladen …'
	initrd	/boot/initrd.img-3.2.0-3-amd64
}


But the copy on my SSD is generated as

menuentry "Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (on /dev/sdb1)" --class gnu-linux --class gnu --class os {
	insmod part_msdos
	insmod ext2
	set root='(/dev/sdb,msdos1)'
	search --no-floppy --fs-uuid --set=root a1135478-503b-4213-86eb-f6011e35b596
	linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro quiet
	initrd /boot/initrd.img-3.2.0-3-amd64
}


You can see that the "search" has the correct UUID, but the "linux" the wrong UUID!
So the system is always booted from the harddisk instead of the SSD.
This error should be corrected.

The system is booting correct after manual correction of this error in the grub.cfg.

Regards
Karsten


-- System Information:
Debian Release: wheezy/sid
   APT prefers testing
   APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages grub2-common depends on:
ii  dpkg          1.16.8
ii  grub-common   1.99-22.1
ii  install-info  4.13a.dfsg.1-10

grub2-common recommends no packages.

[grub.cfg (text/plain, attachment)]

Message #10 received at 686754@bugs.debian.org (full text, mbox, reply):

From: Karsten Malcher <debian@dct.mine.nu>

To: 686754@bugs.debian.org

Subject: Is there any hope that this bug will be fixed?

Date: Tue, 14 Jan 2014 09:03:49 +0100

Again and again i have to correct the grub.cfg manually.
And you can see this bug in all depending distributions of Debian.

Example today:

# blkid
/dev/sda1: LABEL="P1EXT4-8G" UUID="c4aa8129-f5a0-4599-b487-3f63ff736c1b" TYPE="ext4"
/dev/sda2: UUID="5166cbb1-8234-4127-bb0b-bbfda1658b68" TYPE="ext4" LABEL="P2EXT4-30G"
/dev/sda5: UUID="448a6eb5-2173-43e3-b35a-62e9e81a2316" TYPE="swap"
/dev/sda6: LABEL="P3EXT20G" UUID="d37744be-c228-4add-9cf3-ce42aff94a7f" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda7: LABEL="P7-EXT4-900G" UUID="f4d36b10-bae9-4b22-a19b-0f34916337b3" TYPE="ext4"
/dev/sda3: LABEL="P3EXT4-30G" UUID="6bfc15a0-2e9d-4020-9346-9fd52d2696f5" TYPE="ext4"
/dev/sdb1: LABEL="SSD" UUID="5c902625-e63e-446f-a5c5-c24a1176dec7" TYPE="ext4"

grub.cfg

menuentry "Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (on /dev/sda3)" --class gnu-linux --class gnu --class os {
    insmod part_msdos
    insmod ext2
    set root='(/dev/sda,msdos3)'
    search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
    linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro quiet
    initrd /boot/initrd.img-3.2.0-3-amd64
}
menuentry "Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (Wiederherstellungsmodus) (on /dev/sda3)" --class gnu-linux --class 
gnu --class os {
    insmod part_msdos
    insmod ext2
    set root='(/dev/sda,msdos3)'
    search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
    linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single
    initrd /boot/initrd.img-3.2.0-3-amd64


But the first 2 partitions are right now. ;-)
It would be fine if i can boot from all partitions ...

Cheers
Karsten

Message #15 received at 686754@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: debian@dct.mine.nu, 686754@bugs.debian.org

Subject: Re: Bug#686754: Is there any hope that this bug will be fixed?

Date: Tue, 14 Jan 2014 18:00:25 +0000

On Tue, Jan 14, 2014 at 09:03:49AM +0100, Karsten Malcher wrote:
> menuentry "Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (on /dev/sda3)" --class gnu-linux --class gnu --class os {
>     insmod part_msdos
>     insmod ext2
>     set root='(/dev/sda,msdos3)'
>     search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
>     linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro quiet
>     initrd /boot/initrd.img-3.2.0-3-amd64
> }
> menuentry "Debian GNU/Linux, mit Linux 3.2.0-3-amd64
> (Wiederherstellungsmodus) (on /dev/sda3)" --class gnu-linux --class
> gnu --class os {
>     insmod part_msdos
>     insmod ext2
>     set root='(/dev/sda,msdos3)'
>     search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
>     linux /boot/vmlinuz-3.2.0-3-amd64 root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single
>     initrd /boot/initrd.img-3.2.0-3-amd64

GRUB doesn't generate those kernel parameters itself; it relies on
os-prober to fetch them from the boot loader configuration files on
those other systems.  It's quite possible that the problem is simply
that the boot loader configuration inside the filesystem on /dev/sda3
(or its associated /boot filesystem) is wrong.  Could you find the
relevant configuration file and attach it?

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #20 received at 686754@bugs.debian.org (full text, mbox, reply):

From: Karsten Malcher <debian@dct.mine.nu>

To: Colin Watson <cjwatson@debian.org>

Cc: 686754@bugs.debian.org

Subject: Re: Bug#686754: Is there any hope that this bug will be fixed?

Date: Wed, 15 Jan 2014 10:35:55 +0100

Am 14.01.2014 19:00, schrieb Colin Watson:
> GRUB doesn't generate those kernel parameters itself; it relies on os-prober to fetch them from the boot loader 
> configuration files on those other systems. It's quite possible that the problem is simply that the boot loader 
> configuration inside the filesystem on /dev/sda3 (or its associated /boot filesystem) is wrong. Could you find the 
> relevant configuration file and attach it? 

Hello Colin,

now i understand more.
I found this description of os-prober here:
http://joeyh.name/code/os-prober/

Calling os-prober only give this information:
# os-prober
/dev/sda2:Debian GNU/Linux (7.2):Debian:linux
/dev/sda3:Debian GNU/Linux (jessie/sid):Debian1:linux


It seems not to merge the information with the UUID of the partitions.
I found an other interesting effect, which explains that this bug has not been found.
Now an grub-update produces the correct grub.cfg.


menuentry "Debian GNU/Linux, mit Linux 3.12-1-amd64 (on /dev/sda3)" --class gnu-linux --class gnu --class os {
        insmod part_msdos
        insmod ext2
        set root='(/dev/sda,msdos3)'
        search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
        linux /boot/vmlinuz-3.12-1-amd64 root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro quiet
        initrd /boot/initrd.img-3.12-1-amd64
}
menuentry "Debian GNU/Linux, mit Linux 3.12-1-amd64 (Wiederherstellungsmodus) (on /dev/sda3)" --class gnu-linux --class 
gnu --class os {
        insmod part_msdos
        insmod ext2
        set root='(/dev/sda,msdos3)'
        search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
        linux /boot/vmlinuz-3.12-1-amd64 root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro single
        initrd /boot/initrd.img-3.12-1-amd64
}

What i did in the history:
1. I unpacked an backup of /dev/sdb1 (Grub partition with Debian wheezy) to /dev/sda3
2. I altered the fstab of the copy and run update-grub (After this i got this wrong grub.cfg)
3. I boot from /dev/sda3 and made an system-upgrade from wheezy to jessie
4. After the upgrade i run update-grub again from /dev/sdb1 to actualize the new kernel on /dev/sda3 (Now grub.cfg is 
correct)

Is it possible that the (wrong) information is extraced from initrd.img ?

Cheers
Karsten

Message #25 received at 686754@bugs.debian.org (full text, mbox, reply):

From: Lukas Schwaighofer <lukas@schwaighofer.name>

To: debian@dct.mine.nu

Cc: 686754@bugs.debian.org

Subject: Re: Bug#686754: Is there any hope that this bug will be fixed?

Date: Wed, 15 Jan 2014 11:48:21 +0100

Hi Karsten,

On Wed, 15 Jan 2014 10:35:55 +0100
Karsten Malcher <debian@dct.mine.nu> wrote:
> Calling os-prober only give this information:
> # os-prober
> /dev/sda2:Debian GNU/Linux (7.2):Debian:linux
> /dev/sda3:Debian GNU/Linux (jessie/sid):Debian1:linux

For type "linux" os-prober calles linux-boot-prober next with the
partition as a parameter. For /dev/sda3 it would call
# linux-boot-prober /dev/sda3
See /usr/share/doc/os-prober/README for more information.

> It seems not to merge the information with the UUID of the partitions.
> I found an other interesting effect, which explains that this bug has
> not been found. Now an grub-update produces the correct grub.cfg.
> (...)
> 
> What i did in the history:
> 1. I unpacked an backup of /dev/sdb1 (Grub partition with Debian
> wheezy) to /dev/sda3
> 2. I altered the fstab of the copy and run update-grub (After this i
> got this wrong grub.cfg)
> 3. I boot from /dev/sda3 and made an system-upgrade from wheezy to
> jessie
> 4. After the upgrade i run update-grub again from /dev/sdb1 to
> actualize the new kernel on /dev/sda3 (Now grub.cfg is correct)
> 
> Is it possible that the (wrong) information is extraced from
> initrd.img ?

To my knowledge linux-boot-prober does the following:
* Mount the given partition read-only to a temporary directory
* Read the /etc/fstab of this partition to check if /boot is on a
  separate partition. If so, it is also mounted.
* Read and parse the boot loader configuration from the temporary
  directory. For grub2 that is boot/grub/grub.cfg. The parameters to
  the linux kernel (the root=… directive that was wrong in your case)
  should be directly taken from this file.
* Unmount everything again

So your report from your message #15 makes sense, if
the /boot/grub/grub.cfg file on sda3 (I'm assuming you do not have a
separate boot partition) previously contained the "wrong" parameters for
the Linux kernel
(root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single).

Regards
Lukas

Message #30 received at 686754@bugs.debian.org (full text, mbox, reply):

From: Karsten Malcher <debian@dct.mine.nu>

To: Lukas Schwaighofer <lukas@schwaighofer.name>

Cc: 686754@bugs.debian.org

Subject: Re: Bug#686754: Is there any hope that this bug will be fixed?

Date: Wed, 15 Jan 2014 13:34:11 +0100

Am 15.01.2014 11:48, schrieb Lukas Schwaighofer:
> Hi Karsten,
>
> To my knowledge linux-boot-prober does the following:
> * Mount the given partition read-only to a temporary directory
> * Read the /etc/fstab of this partition to check if /boot is on a
>    separate partition. If so, it is also mounted.
> * Read and parse the boot loader configuration from the temporary
>    directory. For grub2 that is boot/grub/grub.cfg. The parameters to
>    the linux kernel (the root=… directive that was wrong in your case)
>    should be directly taken from this file.
> * Unmount everything again
>
> So your report from your message #15 makes sense, if
> the /boot/grub/grub.cfg file on sda3 (I'm assuming you do not have a
> separate boot partition) previously contained the "wrong" parameters for
> the Linux kernel
> (root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single).
>
> Regards
> Lukas

Hi Lukas,

then we have found the explanation for this problem - thank you!

The grub.cfg on the copy of the installation will be correct only after boot and update of this installation.
And i must run update-grub first on the standard installation to get the partition with the copy booted.

It's impossible to avoid this error under this circumstances!

So this bug can be closed.

Regards
Karsten

Message #35 received at 686754@bugs.debian.org (full text, mbox, reply):

From: Hendrik Boom <hendrik@topoi.pooq.com>

To: 686754@bugs.debian.org

Subject: why 686754 is not a bug

Date: Tue, 5 Sep 2017 16:22:50 -0400

I hit this bug, read the previous messages, and wondered why it had 
not been fixed in so long.  I resolved to fix it myself, and spent 
some time reading the code.

But then I was diverted to other tasks, and when I returned to the bug 
a week later, it suddenly dawned on me why it was not a bug.

When grub-install uses its varous tools to survey the disk and make 
proper boot stanzas, it tries as much as possible to figure out how 
the other OS's want to be booted and place that information in its 
boot stanzas.

And the copied OS plainly states how it wants to be booted in its  
copied boot stanzas -- namely, exactly like the originally uncopied 
OS, so in the newly created boot stanza, that's exactly what it gets 
-- a copy of the copy of the original stanza.

So that's what we get.  And to fix it we have to make sure that the 
copied system is altered to refer to itself, just as its /etc/fstab is 
altered to refer to itself.

-- hendrik

Send a report that this bug log contains spam.