Debian Bookworm RC 1 installer- a Bug?

Peter Ehlert

unread,

Apr 5, 2023, 10:30:06 AM4/5/23

to

Debian Bookworm RC 1 installer
Damned nice, the improvements are appreciated.

using the new debian-bookworm-DI-rc1-amd64-netinst.iso
Legacy install, GPT partition
graphic install, manual partitioning
Mate Desktop (others were deselected)

WiFi firmware:
with a cheap USB WiFi adapter plugged in and my network cable unplugged
the USB was shown, and both of the network cards were detected
USB was highlighted, and I was prompted for the password
*the obscure firmware was properly installed!

1. after the install, the WiFi password was retained
2. reboot, with network cable plugged in, WiFi was still active.
3. disconnect WiFI from the control panel and the network was still
active, using the correct network card (the only one plugged in)
4. reboot with cable plugged in, and USB present- WiFi was active
5. reboot with cable plugged in, no USB - network active
6. plug in the USB, it switched to WiFi

Boot Loader:
all disk drives were detected, however the one with the bios_grub
partition was highlighted

=============
second try, using the debian-live-bkworm-DI-rc1-amd64-mate.iso
same machine and again Legacy install, GPT partition
however I did NOT install from the live session:
I chose to go directly to install rather than the Calamares installer
then manual partitioning

Boot Loader:
all drives were detected, however the one with the bios_grub partition
was NOT highlighted, but I did select it.
GRUB was Not properly installed, my former grub menu was still active.
*** I tried a second time, same as above being super careful, same result.

I then booted with my default system, ran grub-install /dev/sde &&
update-grub
then "new" system was on my boot menu.
then booted and it ran as expected.

back to the WiFi dongle, again the obscure firmware was properly installed

Is this a Bug or a user/hardware issue?

David Wright

unread,

Apr 9, 2023, 12:00:06 PM4/9/23

to

On Wed 05 Apr 2023 at 07:03:41 (-0700), Peter Ehlert wrote:
> Debian Bookworm RC 1 installer
> Damned nice, the improvements are appreciated.

I ran rc1 in my usual manner, and the only difference I noticed was
the one extra question about non-free firmware, to which I replied
yes. (There may well be improvements under the hood, so to speak.)
Oh, and the initrd is somewhat larger, as per usual.

> using the new debian-bookworm-DI-rc1-amd64-netinst.iso
> Legacy install, GPT partition

I assume Legacy means BIOS booting. Same here, but only one disk.

> graphic install, manual partitioning
> Mate Desktop (others were deselected)

Non-graphical here, a suitable partition existed, and only
standard and SSH server software was installed.

> WiFi firmware:

Untested as this machine is a 2006-vintage mini-tower lacking wifi.

[ snipped narrative of later network-switching ]

> Boot Loader:
> all disk drives were detected, however the one with the bios_grub
> partition was highlighted

I can't recall seeing anything other than the first item highlighted,
ie "Enter device manually", at least with the non-graphical installer
in expert mode. I selected the (sole) hard drive, item 2. The only
remaining item was the USB stick containing the installer ISO.

As expected nowadays, when the machine rebooted, the Grub menu
had only two lines, both pointing to the newly installed system.
(I hadn't made any attempt to counteract GRUB_DISABLE_OS_PROBER
during my installation.) So Grub was correctly installed in the
MBR, and the rest of Grub occupied d400 bytes of /dev/sda1 (the
3MB BIOS boot partition on the single disk).

> =============
> second try, using the debian-live-bkworm-DI-rc1-amd64-mate.iso
> same machine and again Legacy install, GPT partition
> however I did NOT install from the live session:
> I chose to go directly to install rather than the Calamares installer
> then manual partitioning
>
> Boot Loader:
> all drives were detected, however the one with the bios_grub partition
> was NOT highlighted, but I did select it.
> GRUB was Not properly installed, my former grub menu was still active.

How did you determine that it was the previous menu. Wouldn't it look
just the same?

> *** I tried a second time, same as above being super careful, same result.
>
> I then booted with my default system, ran grub-install /dev/sde &&
> update-grub
> then "new" system was on my boot menu.
> then booted and it ran as expected.

Which method did you use to boot the "default" system (which I assume
is bullseye, in a different partition on one or other of the disks),
in view of the rather sparse menu from grub.cfg on the new system?

> back to the WiFi dongle, again the obscure firmware was properly installed
>
> Is this a Bug or a user/hardware issue?

Presumably we are now back to talking about Grub.

If you still have access to the bookworm system, you can check whether
it claimed to have completed installing Grub successfully. You should
see lines like:

grub-installer: info: Installing grub on '/dev/sda'
grub-installer: info: grub-install does not support --no-floppy
grub-installer: info: Running chroot /target grub-install --force "/dev/sda"
grub-installer: Installing for i386-pc platform.
grub-installer: Installation finished. No error reported.
grub-installer: info: grub-install ran successfully

in /var/log/installer/syslog.

You could install and run boot-info-script, which provides details of
how the system boots, particularly where the MBR code looks for the
BIOS boot partition (ie core.img). BTW do any other disks in this
machine have BIOS boot partitions? (I've one on all my internal disks.)

But as far as we're concerned, I think more information is needed,
like what disks there are on the system, which disk the BIOS is
reading the MBR from, the final listing from the partitioner,
particularly any BIOS boot partitions, and so on. Without all that
in the narrative, there's no telling whether it's a bug or not.

Cheers,
David.

Peter Ehlert

unread,

Apr 16, 2023, 10:30:05 AM4/16/23

to

On 4/9/23 08:57, David Wright wrote:
> On Wed 05 Apr 2023 at 07:03:41 (-0700), Peter Ehlert wrote:
>> Debian Bookworm RC 1 installer
>> Damned nice, the improvements are appreciated.
> I ran rc1 in my usual manner, and the only difference I noticed was
> the one extra question about non-free firmware, to which I replied
> yes. (There may well be improvements under the hood, so to speak.)
> Oh, and the initrd is somewhat larger, as per usual.
>
>> using the new debian-bookworm-DI-rc1-amd64-netinst.iso
>> Legacy install, GPT partition
> I assume Legacy means BIOS booting. Same here, but only one disk.

correct. different term, same thing. Not UEFI

I enable GRUB_DISABLE_OS_PROBER so that the various other operating
systems are shown
if the new GRUB is properly installed I get the "new" one item only GRUB
display.
then when I boot the new OS I again enable GRUB_DISABLE_OS_PROBER and
update GRUB

>
>> *** I tried a second time, same as above being super careful, same result.
>>
>> I then booted with my default system, ran grub-install /dev/sde &&
>> update-grub
>> then "new" system was on my boot menu.
>> then booted and it ran as expected.
> Which method did you use to boot the "default" system (which I assume
> is bullseye, in a different partition on one or other of the disks),
> in view of the rather sparse menu from grub.cfg on the new system?

I boot with the "old" GRUB menu as explained above...it has Several
operating systems listed, my old default OS is still at the top of the list.

>
>> back to the WiFi dongle, again the obscure firmware was properly installed
>>
>> Is this a Bug or a user/hardware issue?
> Presumably we are now back to talking about Grub.
>
> If you still have access to the bookworm system, you can check whether
> it claimed to have completed installing Grub successfully. You should
> see lines like:
>
> grub-installer: info: Installing grub on '/dev/sda'
> grub-installer: info: grub-install does not support --no-floppy
> grub-installer: info: Running chroot /target grub-install --force "/dev/sda"
> grub-installer: Installing for i386-pc platform.
> grub-installer: Installation finished. No error reported.
> grub-installer: info: grub-install ran successfully
>
> in /var/log/installer/syslog.

Thanks, I did not know where to look or what to look for.

===================
Apr 5 12:59:44 grub-installer: info: Identified partition label for
/dev/sdb12: gpt

Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb'
Apr 5 13:01:03 grub-installer: info: grub-install does not support
--no-floppy
Apr 5 13:01:03 grub-installer: info: Running chroot /target
grub-install --force "/dev/sdb"

====
5 12:59:44 grub-installer: info: Identified partition label for
/dev/sdb12: gpt
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-legacy which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-amd64-bin which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-amd64-signed which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-amd64 which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-ia32-bin which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-ia32 which isn't installed

Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb'
Apr 5 13:01:03 grub-installer: info: grub-install does not support
--no-floppy
Apr 5 13:01:03 grub-installer: info: Running chroot /target
grub-install --force "/dev/sdb"
Apr 5 13:01:03 grub-installer: Installing for i386-pc platform.
Apr 5 13:01:13 grub-installer: grub-install: warning: this GPT
partition label contains no BIOS Boot Partition; embedding won't be
possible.
Apr 5 13:01:13 grub-installer: grub-install: warning: Embedding is not
possible. GRUB can only be installed in this setup by using
blocklists. However, blocklists are UNRELIABLE and their use is
discouraged..
Apr 5 13:01:13 grub-installer: Installation finished. No error reported.
Apr 5 13:01:13 grub-installer: info: grub-install ran successfully

====

New Information:
in my effort to eliminate the hardware possibility I made several new
installs on three other machines, all with multiple drives, and only one
with the bios_grub partition

at the close of the install we are presented with a "Install the GRUB
boot loader" window/menu
it asks "install the GRUB boot loader to your primary drive" with Yes
and No options

* if I select No it presents a list of my physical drives...
choosing the one with the bios_grub partition does not work, GRUB is not
installed and the same fails are shown in the log.

* if I select Yes it again presents the same list of my physical drives...
choosing the one with the bios_grub partition Does work, GRUB is
installed as expected

logically, I select NO because I have no clue which is the Primary Drive
and fully understand that it needs to point to the one with the
bios_grub partition.

SO: where do I report this Bug/Anomaly?
I assume it should go to the debian-boot list

>
> You could install and run boot-info-script, which provides details of
> how the system boots, particularly where the MBR code looks for the
> BIOS boot partition (ie core.img). BTW do any other disks in this
> machine have BIOS boot partitions? (I've one on all my internal disks.)

thanks for that thought

Peter Ehlert

unread,

Apr 16, 2023, 10:40:07 AM4/16/23

to

On 4/9/23 08:57, David Wright wrote:

> On Wed 05 Apr 2023 at 07:03:41 (-0700), Peter Ehlert wrote:
>> Debian Bookworm RC 1 installer
>> Damned nice, the improvements are appreciated.
> I ran rc1 in my usual manner, and the only difference I noticed was
> the one extra question about non-free firmware, to which I replied
> yes. (There may well be improvements under the hood, so to speak.)
> Oh, and the initrd is somewhat larger, as per usual.
>
>> using the new debian-bookworm-DI-rc1-amd64-netinst.iso
>> Legacy install, GPT partition
> I assume Legacy means BIOS booting. Same here, but only one disk.

correct. different term, same thing. Not UEFI
>

I enable GRUB_DISABLE_OS_PROBER so that the various other operating
systems are shown
if the new GRUB is properly installed I get the "new" one item only GRUB
display.
then when I boot the new OS I again enable GRUB_DISABLE_OS_PROBER and
update GRUB
>

>> *** I tried a second time, same as above being super careful, same result.
>>
>> I then booted with my default system, ran grub-install /dev/sde &&
>> update-grub
>> then "new" system was on my boot menu.
>> then booted and it ran as expected.
> Which method did you use to boot the "default" system (which I assume
> is bullseye, in a different partition on one or other of the disks),
> in view of the rather sparse menu from grub.cfg on the new system?

I boot with the "old" GRUB menu as explained above...it has Several
operating systems listed, my old default OS is still at the top of the list.
>

>> back to the WiFi dongle, again the obscure firmware was properly installed
>>
>> Is this a Bug or a user/hardware issue?
> Presumably we are now back to talking about Grub.
>
> If you still have access to the bookworm system, you can check whether
> it claimed to have completed installing Grub successfully. You should
> see lines like:
>
> grub-installer: info: Installing grub on '/dev/sda'
> grub-installer: info: grub-install does not support --no-floppy
> grub-installer: info: Running chroot /target grub-install --force "/dev/sda"
> grub-installer: Installing for i386-pc platform.
> grub-installer: Installation finished. No error reported.
> grub-installer: info: grub-install ran successfully
>
> in /var/log/installer/syslog.

Thanks, I did not know where to look or what to look for.

===================
Apr 5 12:59:44 grub-installer: info: Identified partition label for
/dev/sdb12: gpt

Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb'

Apr 5 13:01:03 grub-installer: info: grub-install does not support
--no-floppy

Apr 5 13:01:03 grub-installer: info: Running chroot /target
grub-install --force "/dev/sdb"

====
5 12:59:44 grub-installer: info: Identified partition label for
/dev/sdb12: gpt
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-legacy which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-amd64-bin which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-amd64-signed which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-amd64 which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-ia32-bin which isn't installed
Apr 5 12:59:45 grub-installer: dpkg: warning: ignoring request to
remove grub-efi-ia32 which isn't installed

Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb'

Apr 5 13:01:03 grub-installer: info: grub-install does not support
--no-floppy

Apr 5 13:01:03 grub-installer: info: Running chroot /target
grub-install --force "/dev/sdb"
Apr 5 13:01:03 grub-installer: Installing for i386-pc platform.
Apr 5 13:01:13 grub-installer: grub-install: warning: this GPT
partition label contains no BIOS Boot Partition; embedding won't be
possible.
Apr 5 13:01:13 grub-installer: grub-install: warning: Embedding is not
possible. GRUB can only be installed in this setup by using
blocklists. However, blocklists are UNRELIABLE and their use is
discouraged..
Apr 5 13:01:13 grub-installer: Installation finished. No error reported.
Apr 5 13:01:13 grub-installer: info: grub-install ran successfully

====

New Information:
in my effort to eliminate the hardware possibility I made several new

installs on three other machines, all with multiple drives, and only one
with the bios_grub partition

at the close of the install we are presented with a "Install the GRUB
boot loader" window/menu
it asks "install the GRUB boot loader to your primary drive" with Yes
and No options

* if I select No it presents a list of my physical drives...
choosing the one with the bios_grub partition does not work, GRUB is not
installed and the same fails are shown in the log.

* if I select Yes it again presents the same list of my physical drives...
choosing the one with the bios_grub partition Does work, GRUB is
installed as expected

logically, I select NO because I have no clue which is the Primary Drive
and fully understand that it needs to point to the one with the
bios_grub partition.

SO: where do I report this Bug/Anomaly?
I assume it should go to the debian-boot list

>

> You could install and run boot-info-script, which provides details of
> how the system boots, particularly where the MBR code looks for the
> BIOS boot partition (ie core.img). BTW do any other disks in this
> machine have BIOS boot partitions? (I've one on all my internal disks.)

thanks for that thought

David Wright

unread,

Apr 16, 2023, 12:40:06 PM4/16/23

to

So you installed Grub on /dev/sde.

> > Which method did you use to boot the "default" system (which I assume
> > is bullseye, in a different partition on one or other of the disks),
> > in view of the rather sparse menu from grub.cfg on the new system?
> I boot with the "old" GRUB menu as explained above...it has Several
> operating systems listed, my old default OS is still at the top of the
> list.
> >
> > > back to the WiFi dongle, again the obscure firmware was properly installed
> > >
> > > Is this a Bug or a user/hardware issue?
> > Presumably we are now back to talking about Grub.
> >
> > If you still have access to the bookworm system, you can check whether
> > it claimed to have completed installing Grub successfully. You should
> > see lines like:
> >
> > grub-installer: info: Installing grub on '/dev/sda'
> > grub-installer: info: grub-install does not support --no-floppy
> > grub-installer: info: Running chroot /target grub-install --force "/dev/sda"
> > grub-installer: Installing for i386-pc platform.
> > grub-installer: Installation finished. No error reported.
> > grub-installer: info: grub-install ran successfully
> >
> > in /var/log/installer/syslog.
> Thanks, I did not know where to look or what to look for.

I've tidied these lines:

> ===================
> Apr 5 12:59:44 grub-installer: info: Identified partition label for
> /dev/sdb12: gpt

> Apr 5 13:01:03 grub-installer: info: Installing grub on '/dev/sdb'
> Apr 5 13:01:03 grub-installer: info: grub-install does not support
> --no-floppy
> Apr 5 13:01:03 grub-installer: info: Running chroot /target
> grub-install --force "/dev/sdb"

> Apr 5 13:01:03 grub-installer: Installing for i386-pc platform.
> Apr 5 13:01:13 grub-installer: grub-install: warning: this GPT
> partition label contains no BIOS Boot Partition; embedding won't be
> possible.
> Apr 5 13:01:13 grub-installer: grub-install: warning: Embedding is
> not possible. GRUB can only be installed in this setup by using
> blocklists. However, blocklists are UNRELIABLE and their use is
> discouraged..
> Apr 5 13:01:13 grub-installer: Installation finished. No error reported.
> Apr 5 13:01:13 grub-installer: info: grub-install ran successfully
>
> ====

So that was installing Grub on /dev/sdb. I'm confused. This is a BIOS
machine, so it boots via the MBR. Then it's meant to use blocklists?

But you installed Grub on /dev/sde. Is that using blocklists? Are you
always booting from the same MBR?

Without tying all this down 100%, you have no bug IMO. It seems you
have an extremely fragile boot implementation.

> New Information:
> in my effort to eliminate the hardware possibility I made several new
> installs on three other machines, all with multiple drives, and only
> one with the bios_grub partition
>
> at the close of the install we are presented with a "Install the GRUB
> boot loader" window/menu
> it asks "install the GRUB boot loader to your primary drive" with Yes
> and No options
>
> * if I select No it presents a list of my physical drives...
> choosing the one with the bios_grub partition does not work, GRUB is
> not installed and the same fails are shown in the log.

You're outside my comfort zone. My understanding is that you don't
refresh the MBR, and write a blocklist. (I didn't see failure in
the log, just a robust warning.) But I don't know where that blocklist
is (I don't use them). It would be very easy for them to be overwritten.
Perhaps boot-init-script would help here.

> * if I select Yes it again presents the same list of my physical drives...
> choosing the one with the bios_grub partition Does work, GRUB is
> installed as expected

I though you wrote earlier that that didn't work. (Nine lines after

"second try, using the debian-live-bkworm-DI-rc1-amd64-mate.iso"

including blank lines.)

> logically, I select NO because I have no clue which is the Primary
> Drive and fully understand that it needs to point to the one with the
> bios_grub partition.

What "needs to point to"? AIUI the Primary drive is the one the BIOS
reads the MBR from by default, ie if you haven't overridden it with
the one-shot boot device menu (ie what Dell typically put on F12).
So the BIOS has to point to the MBR which then points Grub at the
BIOS Boot Partition, when there is one (or more), and that gets you
to a Grub grub.cfg menu, and an OS.

So I'm not confident where your active MBR is (sda, or sdb, or sde;
each disk can have an MBR), and why Grub is writing blocklists
(implying it doesn't know where the BIOS Boot Partition is).
So I'd say the last paragraph, quoted below, still applies.

There's a fair amount of information on the web, too, about
dual-booting Grub, which might be worth perusing.

> SO: where do I report this Bug/Anomaly?
> I assume it should go to the debian-boot list

I would say it's rather premature as a bug report, but more
experienced eyes might help with what's going wrong where.

Peter Ehlert

unread,

Apr 17, 2023, 12:10:06 PM4/17/23

to

to my understanding (and experience) GRUB will not write to a GPT drive without a partition flagged bio_grub

I believe it does not use MBR

SO: where do I report this Bug/Anomaly?
I assume it should go to the debian-boot list

I would say it's rather premature as a bug report, but more
experienced eyes might help with what's going wrong where.

I did CC this thread to the debian-boot list.
hopefully they can parse and understand what is going on and make it more user friendly before Bookworm is final.

You could install and run boot-info-script, which provides details of
how the system boots, particularly where the MBR code looks for the
BIOS boot partition (ie core.img). BTW do any other disks in this
machine have BIOS boot partitions? (I've one on all my internal disks.)

thanks for that thought

But as far as we're concerned, I think more information is needed,
like what disks there are on the system, which disk the BIOS is
reading the MBR from, the final listing from the partitioner,
particularly any BIOS boot partitions, and so on. Without all that
in the narrative, there's no telling whether it's a bug or not.

Cheers,
David.

David: thanks for your response and assistance.

long story short:
GRUB install fails with the debian-live-bkworm-DI-rc1-amd64-mate.iso installer as described I (poorly) described above.

the debian-bookworm-DI-rc1-amd64-netinst.iso does work as expected.

David Wright

unread,

Apr 18, 2023, 12:50:06 AM4/18/23

to

No, that's wrong, and here's the evidence. I installed bookwork-RC1
onto my 2004-vintage laptop into partition four, but with the BIOS
Boot Partition (sda1) concealed from the Grub installer.

Command (? for help): p
Disk /dev/sda: 117210240 sectors, 55.9 GiB
Model: IC25N060ATMR04-0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 9B25D407-FA9E-4A0B-8701-6532B26FAE90
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 117210206
Partitions will be aligned on 2048-sector boundaries
Total free space is 5181 sectors (2.5 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 8191 3.0 MiB 0C01 Microsoft reserved
2 8192 2047999 996.0 MiB 8200 noah02
3 2048000 41943039 19.0 GiB 8300 Linux filesystem
4 41943040 117207039 35.9 GiB 8300 Linux filesystem

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sda.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
# reboot

The reboot was successful, and was just to check that sda1 is
undamaged (as it shouldn't be).

Here's the output from the partitioner during the installation,
showing no BIOS Boot Partition, and the intended 38.5GB root
filesystem:

│ │
│ SCSI1 (0,0,0) (sda) - 60.0 GB ATA IC25N060ATMR04-0 │
│ > 1.0 MB FREE SPACE │
│ > #1 3.1 MB Microsoft re │
│ > #2 1.0 GB ext2 noah02 │
│ > #3 20.4 GB ext4 Linux filesy │
│ > #4 38.5 GB F ext4 Linux filesy / │
│ > 1.6 MB FREE SPACE │
│ SCSI3 (0,0,0) (sdb) - 2.0 GB Generic Flash Disk │
│ │

… from the Grub installer:

┌─────────────────┤ [!] Install the GRUB boot loader ├──────────────────┐
│ │
│ The following other operating systems have been detected on this │
│ computer: Debian GNU/Linux 11 (bullseye) │
│ │
│ If all of your operating systems are listed above, then it should be │
│ safe to install the boot loader to your primary drive (UEFI │
│ partition/boot record). When your computer boots, you will be able to │
│ choose to load one of these operating systems or the newly installed │
│ Debian system │
│ │
│ Install the GRUB boot loader to your primary drive? [Yes]

┌──────────────────┤ [!] Install the GRUB boot loader ├───────────────────┐
│ │
│ You need to make the newly installed system bootable, by installing │
│ the GRUB boot loader on a bootable device. The usual way to do this │
│ is to install GRUB to your primary drive (UEFI partition/boot │
│ record). You may instead install GRUB to a different drive (or │
│ partition), or to removable media. │
│ │
│ Device for boot loader installation: │
│ │
│ Enter device manually │
│ /dev/sda (ata-IC25N060ATMR04-0_MRG308K3K7VGYH) │
│ /dev/sdb (usb-Generic_Flash_Disk_58F99DC1-0:0) │
│ [sda]

And the log is just like yours:

grub-installer: info: Installing grub on '/dev/sda'
grub-installer: info: grub-install does not support --no-floppy
grub-installer: info: Running chroot /target grub-install --force "/dev/sda"
grub-installer: Installing for i386-pc platform.

grub-installer: grub-install: warning:
grub-installer:
grub-installer: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible
grub-installer: .
grub-installer: grub-install: warning:
grub-installer:
grub-installer: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.
grub-installer: .

grub-installer: Installation finished. No error reported.
grub-installer: info: grub-install ran successfully

/bin/in-target: warning: /target/etc/mtab won't be updated since it is a symlink.

At the end of the installation, I rebooted, and the new system was
displayed in the Grub menu as expected, and ran without fuss.

One might opine that the use of blocklists should have been reported,
but the "bug" is on the part of the operator in this case: wrong
partitioning.

Here's what boot-init-script reports:

Boot Info Script 0.78 [09 October 2019]

============================= Boot Info Summary: ===============================

=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector
46412680 of the same hard drive for core.img. core.img is at this location
and looks for (,gpt4)/boot/grub. It also embeds following components:

modules
---------------------------------------------------------------------------
fshelp ext2 part_gpt biosdisk
---------------------------------------------------------------------------

I don't know how to find the sector number of the start of a file on
ext4, so I'll use a crude technique of listing the head of the file,
and then the code at sector 46412680:

$ hexdump -C /acer/boot/grub/i386-pc/core.img | head -n 25
00000000 52 56 be 1b 81 e8 39 01 5e bf f4 81 66 8b 2d 83 |RV....9.^...f.-.|
00000010 7d 08 00 0f 84 e2 00 80 7c ff 00 74 46 66 8b 1d |}.......|..tFf..|
00000020 66 8b 4d 04 66 31 c0 b0 7f 39 45 08 7f 03 8b 45 |f.M.f1...9E....E|
00000030 08 29 45 08 66 01 05 66 83 55 04 00 c7 04 10 00 |.)E.f..f.U......|
00000040 89 44 02 66 89 5c 08 66 89 4c 0c c7 44 06 00 70 |.D.f.\.f.L..D..p|
00000050 50 c7 44 04 00 00 b4 42 cd 13 0f 82 af 00 bb 00 |P.D....B........|
00000060 70 eb 66 66 8b 45 04 66 09 c0 0f 85 97 00 66 8b |p.ff.E.f......f.|
00000070 05 66 31 d2 66 f7 34 88 54 0a 66 31 d2 66 f7 74 |.f1.f.4.T.f1.f.t|
00000080 04 88 54 0b 89 44 0c 3b 44 08 7d 79 8b 04 2a 44 |..T..D.;D.}y..*D|
00000090 0a 39 45 08 7f 03 8b 45 08 29 45 08 66 01 05 66 |.9E....E.)E.f..f|
000000a0 83 55 04 00 8a 54 0d c0 e2 06 8a 4c 0a fe c1 08 |.U...T.....L....|
000000b0 d1 8a 6c 0c 5a 52 8a 74 0b 50 bb 00 70 8e c3 31 |..l.ZR.t.P..p..1|
000000c0 db b4 02 cd 13 72 46 8c c3 8e 45 0a 58 c1 e0 05 |.....rF...E.X...|
000000d0 01 45 0a 60 1e c1 e0 03 89 c1 31 ff 31 f6 8e db |.E.`......1.1...|
000000e0 fc f3 a5 1f be 23 81 e8 57 00 61 83 7d 08 00 0f |.....#..W.a.}...|
000000f0 85 24 ff 83 ef 0c e9 16 ff be 25 81 e8 42 00 5a |.$........%..B.Z|
00000100 ea 00 82 00 00 be 28 81 e8 36 00 eb 06 be 2d 81 |......(..6....-.|
00000110 e8 2e 00 be 32 81 e8 28 00 eb fe 6c 6f 61 64 69 |....2..(...loadi|
00000120 6e 67 00 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 |ng......Geom.Rea|
00000130 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 |d. Error........|
00000140 46 8a 04 3c 00 75 f2 c3 00 00 00 00 00 00 00 00 |F..<.u..........|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 89 33 c4 02 00 00 00 00 37 00 20 08 |.....3......7. .|
00000200 ea 1c 82 00 00 00 00 00 02 5b 00 00 a4 b1 00 00 |.........[......|
$

# dd bs=512 if=/dev/sda of=/dev/stdout skip=46412680 count=1 | hexdump -C
1+0 records in
1+0 records out
512 bytes copied, 0.00235733 s, 217 kB/s
00000000 52 56 be 1b 81 e8 39 01 5e bf f4 81 66 8b 2d 83 |RV....9.^...f.-.|
00000010 7d 08 00 0f 84 e2 00 80 7c ff 00 74 46 66 8b 1d |}.......|..tFf..|
00000020 66 8b 4d 04 66 31 c0 b0 7f 39 45 08 7f 03 8b 45 |f.M.f1...9E....E|
00000030 08 29 45 08 66 01 05 66 83 55 04 00 c7 04 10 00 |.)E.f..f.U......|
00000040 89 44 02 66 89 5c 08 66 89 4c 0c c7 44 06 00 70 |.D.f.\.f.L..D..p|
00000050 50 c7 44 04 00 00 b4 42 cd 13 0f 82 af 00 bb 00 |P.D....B........|
00000060 70 eb 66 66 8b 45 04 66 09 c0 0f 85 97 00 66 8b |p.ff.E.f......f.|
00000070 05 66 31 d2 66 f7 34 88 54 0a 66 31 d2 66 f7 74 |.f1.f.4.T.f1.f.t|
00000080 04 88 54 0b 89 44 0c 3b 44 08 7d 79 8b 04 2a 44 |..T..D.;D.}y..*D|
00000090 0a 39 45 08 7f 03 8b 45 08 29 45 08 66 01 05 66 |.9E....E.)E.f..f|
000000a0 83 55 04 00 8a 54 0d c0 e2 06 8a 4c 0a fe c1 08 |.U...T.....L....|
000000b0 d1 8a 6c 0c 5a 52 8a 74 0b 50 bb 00 70 8e c3 31 |..l.ZR.t.P..p..1|
000000c0 db b4 02 cd 13 72 46 8c c3 8e 45 0a 58 c1 e0 05 |.....rF...E.X...|
000000d0 01 45 0a 60 1e c1 e0 03 89 c1 31 ff 31 f6 8e db |.E.`......1.1...|
000000e0 fc f3 a5 1f be 23 81 e8 57 00 61 83 7d 08 00 0f |.....#..W.a.}...|
000000f0 85 24 ff 83 ef 0c e9 16 ff be 25 81 e8 42 00 5a |.$........%..B.Z|
00000100 ea 00 82 00 00 be 28 81 e8 36 00 eb 06 be 2d 81 |......(..6....-.|
00000110 e8 2e 00 be 32 81 e8 28 00 eb fe 6c 6f 61 64 69 |....2..(...loadi|
00000120 6e 67 00 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 |ng......Geom.Rea|
00000130 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 |d. Error........|
00000140 46 8a 04 3c 00 75 f2 c3 00 00 00 00 00 00 00 00 |F..<.u..........|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 89 33 c4 02 00 00 00 00 37 00 20 08 |.....3......7. .|
00000200
#

I think that confirms that boot-init-script is correct in its
assertion.

> I believe it does not use MBR

> *
> *

The Grub installer certainly doesn't use the MBR if you refuse it.
But the only way you can avoid using this MBR to boot the machine
is by using that MBR, where "this" and "that" are defined by
selections made in the CMOS settings. Most machines will boot from
a floppy/optical drive/USB stick/primary hard drive. Some allow
swapping primary/secondary drives. But one way or another, you
need to use an MBR, and you can chain to another boot record too.

> > > SO: where do I report this Bug/Anomaly?
> > > I assume it should go to the debian-boot list
> > I would say it's rather premature as a bug report, but more
> > experienced eyes might help with what's going wrong where.
> I did CC this thread to the debian-boot list.
> hopefully they can parse and understand what is going on and make it
> more user friendly before Bookworm is final.
> >
> > > > You could install and run boot-info-script, which provides details of
> > > > how the system boots, particularly where the MBR code looks for the
> > > > BIOS boot partition (ie core.img). BTW do any other disks in this
> > > > machine have BIOS boot partitions? (I've one on all my internal disks.)
> > > thanks for that thought
> > > > But as far as we're concerned, I think more information is needed,
> > > > like what disks there are on the system, which disk the BIOS is
> > > > reading the MBR from, the final listing from the partitioner,
> > > > particularly any BIOS boot partitions, and so on. Without all that
> > > > in the narrative, there's no telling whether it's a bug or not.
> >

> David: thanks for your response and assistance.
>
> long story short:
> GRUB install fails with the debian-live-bkworm-DI-rc1-amd64-mate.iso
> installer as described I (poorly) described above.
>
> the debian-bookworm-DI-rc1-amd64-netinst.iso does work as expected.

With the information above, you can easily see why saying No to
writing the MBR will fail.

The installation above wrote an MBR (ie Yes) that pointed to sector
46412680, where it had written Grub's core.img. Booting succeeds.

Now reinstall, but say No to writing the MBR. The d-i will have
written an entirely new filesystem, including all of the contents of
/boot. All the files will have slightly different inodes and sector
positions because the order they were written has a random element.
However, your unrefreshed MBR will still believe that core.img is in
sector 46412680, not knowing that ext2.mod is there instead, and so
booting will fail.

Cheers,
David.

Peter Ehlert

unread,

Apr 23, 2023, 9:00:09 AM4/23/23

to

thank you for your input.

my experience is contrary

My problem with GRUB is repeatable, with both the Live ISO and the Netinstall ISO.

I will make fresh installs and file installation-reports to sub...@bugs.debian.org in the near future

Peter Ehlert

unread,

May 5, 2023, 10:02:06 AM5/5/23

to

Again, thanks for the input and education.

it's an arduous process but I feel it is worth the effort to help eliminate the little glitches that make access to Debian a bit difficult.

FYI: Bug#1035096: installation-report Bookworm RC2 GRUB not installed

https://www.mail-archive.com/debia...@lists.debian.org/msg181034.html

David Wright

unread,

May 8, 2023, 12:20:06 PM5/8/23

to

[ … ]

> > >
> > > # dd bs=512 if=/dev/sda of=/dev/stdout skip=46412680 count=1 | hexdump -C
> > > 1+0 records in
> > > 1+0 records out
> > > 512 bytes copied, 0.00235733 s, 217 kB/s
> > > 00000000 52 56 be 1b 81 e8 39 01 5e bf f4 81 66 8b 2d 83 |RV....9.^...f.-.|

[ … ]

> > thank you for your input.
> >
> > my experience is contrary
> >
> > My problem with GRUB is repeatable, with both the Live ISO and the
> > Netinstall ISO.
> >
> > I will make fresh installs and file installation-reports to
> > sub...@bugs.debian.org in the near future
> >
> Again, thanks for the input and education.
>
> it's an arduous process but I feel it is worth the effort to help
> eliminate the little glitches that make access to Debian a bit
> difficult.
>
> FYI: Bug#1035096: installation-report Bookworm RC2 GRUB not installed
>
> https://www.mail-archive.com/debia...@lists.debian.org/msg181034.html

I hadn't realised that RC2 was out. I tried it and it works very well
here. I installed twice onto this system:

BIOS-booting laptop 500MB
Internal drive 60GB sda (noah) GPT
MBR Grub installed.
noah01 BOOT Bios partition BUT although it points at system on
noah03, it has been hidden by setting the partition type
to 8300. This doesn't prevent Grub booting noah03 (the
regular bullseye), but does prevent grub-install from
using it.
noah02 swap for noah03; not used during installation.
noah03 regular bullseye. /boot also contains hd-media's vmlinuz
and initrd.gz, and the RC2 ISO.
noah04 target partition, type 8300.
External USB drive 1TB sdb (quiz) GPT
MBR blank at start of experiment. It had only ever been
installed, and booted from, on UEFI computers.
quiz01 NTFS, unused.
quiz02 BIOS Boot partition to be used.
quiz03 ESP, unused.
quiz04 buster, unused.
quiz05 bullseye, unused.
quiz06 encrypted filesystem, unused.

Installation 1.

BIOS set to boot normally, ie from the internal drive.
MBR → noah01 (core.img) → noah03 /boot's Grub menu.
Select custom entry for hd-media's vmlinuz&initrd.gz
Scan /dev/sda3 for the d-i ISO
Boots up debian-bookworm-DI-rc2-i386-netinst.iso
Expert install
Manual partitioning:
F noah04 Format, use as /
K quiz02 BIOS Boot partition, Reserved BIOS boot area
no other partitions to be used.
Confirm no swap, write changes.
Software installed: ssh server, standard system utilities.

Install the boot loader
Interesting change here for RC2: it asks if you want to run
the os-prober (as in bullseye) or not (as in RC1).
Answered yes.

Device for boot loader installation:
Enter device manually
/dev/sda

/dev/sdb

Yes, there's a bug here, so my reply on this run (/dev/sdb) was
ignored, and Grub was installed on /dev/sda. Of course, this
tests the ability of Grub to be installed without a BIOS Boot
partition, which it passed, just as in the example quoted above,
where the MBR pointed through blocklists to the core.img in /boot
on partition four.

The difference on RC2 is that now we get a full Grub menu on
rebooting, assuming we asked for it.

============================= Boot Info Summary: ===============================

=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector

46412992 of the same hard drive for core.img. core.img is at this location

and looks for (,gpt4)/boot/grub. It also embeds following components:

modules
---------------------------------------------------------------------------
fshelp ext2 part_gpt biosdisk
---------------------------------------------------------------------------

=> No boot loader is installed in the MBR of /dev/sdb.

================================================================================

Installation 2.

Restarting the process with the hd-media ISO, everything was done
the same, as far as:

Install the boot loader
Run the os-prober? yes.

Device for boot loader installation:
Enter device manually
/dev/sda

/dev/sdb

The workaround, selecting Enter device manually, and typing
/dev/sdb
in the next screen, works perfectly. The d-i installs Grub
in sdb's MBR and quiz02. To boot it, I have to set the BIOS
to boot from the USB disk in preference to the internal one.
The sequence then is quiz's MBR → quiz02 → script listed below
→ noah04's UUID (ie, hd0,gpt4).

============================= Boot Info Summary: ===============================

=> Grub2 (v2.00) is installed in the MBR of /dev/sda and looks at sector

46412992 of the same hard drive for core.img. core.img is at this location

and looks for (,gpt4)/boot/grub. It also embeds following components:

modules
---------------------------------------------------------------------------
fshelp ext2 part_gpt biosdisk
---------------------------------------------------------------------------

=> Grub2 (v2.00) is installed in the MBR of /dev/sdb and looks at sector
1302349824 of the same hard drive for core.img. core.img is at this
location and looks for /boot/grub. It also embeds following components:

modules
---------------------------------------------------------------------------
fshelp ext2 part_gpt biosdisk search_fs_uuid
---------------------------------------------------------------------------

config script
---------------------------------------------------------------------------
search.fs_uuid fc1a7f1d-d65e-4899-912a-1f0423398d23 root hd0,gpt4
set prefix=($root)'/boot/grub'

---------------------------------------------------------------------------

Comments on the bug #1035096 report:

#30 Pascal asked "Are you sure that the machine rebooted from this disk ?"

#35 You replied "apparently so. I know of none other."

You have five disks including the installer. If the installer is
removable, then presumably you removed it. Typically, the BIOS
will then boot from the same disk as before, ie the production
system. The BIOS doesn't know that another disk has a fresher MBR.

"GRUB menu showed all of the other systems as before the install."
Well, it would.

If the installer in non-removable, then you'd have to tell the BIOS
to boot from a different disk (unless you're installing to another
partition on the installer's disk.

#45 "User says disk X
DI attempts to install on Drive Y
result ... GRUB does not get installed at all"

As we have seen in previous messages, you get blocklists
on drive Y (which contains the new installation) and a
fresh MBR on drive Y.

"setting up BIOS to boot from a drive that does not have a bios_grub
flagged partition results in:
'GPT-formatted disk.
Legacy boot not supported. Press any key to reboot.'"

It would really help to post which drive you're talking about.
I suspect we have:

. 1 disk with installer on it (sda),
. 2 disk with new installation on it (Y, variously sdb and sdd),
. 3 disk with BIOS Boot partition on it (presumbly X, sde),
. 4 disk with production system on it (gave you old menu),
. 5 disk that you just set the BIOS to boot from.

That message looks like an old Windows message, Windows couldn't
boot from mixed MBR/GPT or UEFI/MBR combinations.

The /BIOS/ couldn't have issued that message as Legacy booting on
a GPT disk is precisely what it's doing here.

I guess there's another version of the installer to try out,
seeing as #70 has meanwhile appeared.

Cheers,
David.