Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1024346: cdrom: debian-11.5.0-amd64-netinst.iso boots to Grub CLI on Dell Optiplex 5090
43 views
Skip to first unread message
Rob Klingsten
Nov 17, 2022, 5:00:03 PM11/17/22
to
Package: cdrom
Severity: important
Tags: d-i
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Downloaded debian-11.5.0-amd64-netinst.iso, verified SHA512 signature and flashed to USB stick (dd if=<debian.iso> of=/dev/sdb). The
Dell Optiplex 5090 is a UEFI-only system. In the BIOS, I previously disabled TPM, Secure Boot and Absolute (computer Lojack).
Booting from the netinst USB stick, the computer boots into the Grub CLI. 'ls' shows the following:
(proc) (hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (cd0) (cd0,msdos2)
There does not appear to be any usable partition detected on the USB stick that contains a kernel. The contents of (cd0,msdos2) are
just an 'efi' directory.
I have tried multiple USB sticks, downloaded the ISO several times all with a good SHA512, tried dd and also cp <iso> /dev/sdb, makes
no difference. I've tried the live Gnome image as well, same problem.
I expect the computer to boot properly into the Debian installer.
Severity: important
Tags: d-i
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
Downloaded debian-11.5.0-amd64-netinst.iso, verified SHA512 signature and flashed to USB stick (dd if=<debian.iso> of=/dev/sdb). The
Dell Optiplex 5090 is a UEFI-only system. In the BIOS, I previously disabled TPM, Secure Boot and Absolute (computer Lojack).
Booting from the netinst USB stick, the computer boots into the Grub CLI. 'ls' shows the following:
(proc) (hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (cd0) (cd0,msdos2)
There does not appear to be any usable partition detected on the USB stick that contains a kernel. The contents of (cd0,msdos2) are
just an 'efi' directory.
I have tried multiple USB sticks, downloaded the ISO several times all with a good SHA512, tried dd and also cp <iso> /dev/sdb, makes
no difference. I've tried the live Gnome image as well, same problem.
I expect the computer to boot properly into the Debian installer.
Andrew M.A. Cater
Nov 19, 2022, 8:00:04 AM11/19/22
to
Rob - see below, you might want to subscribe to the bug too.
Suggestion is to use firmware .iso and a more verbose dd line to ensure
you've actually written the whole image correctly.
Also, I would suggest enabling TPM and secure boot unless you are *absolutely*
sure that you don't need them. Secure boot is well supported in Debian.
Hope this helps,
Andy Cater
On Fri, Nov 18, 2022 at 08:33:29PM +0100, Franco Martelli wrote:
> On 17/11/22 at 23:11, Andrew M.A. Cater wrote:
> > First of all:
> >
> > It may be better to use a longer dd line and also to use the unofficial
> > firmware image available at https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/amd64/iso-cd/firmware-11.5.0-amd64-netinst.iso
> >
> > dd if=firmware-11.5.0-amd64-netinst.iso of=/dev/sdb bs=4M oflag=sync status=progress
> >
> > That makes absolutely sure that the transfer is synced to ensure that it is
> > written to the stick and also gives you some idea of how well the transfer
> > is going.
> >
> > Using the firmware .iso will potentially solve any problems with missing
> > firmwware.
> >
> > The writing to a stick *should* work well.
> >
> > All the very best, as ever,
> >
> > Andy Cater
> >
> I'm not sure but maybe Rob Klingsten is not on the list so I'm not sure that
> he has read your reply please consider to re-send your answer to
> 102...@bugs.debian.org
>
> kind regards
> --
> Franco Martelli
>
Suggestion is to use firmware .iso and a more verbose dd line to ensure
you've actually written the whole image correctly.
Also, I would suggest enabling TPM and secure boot unless you are *absolutely*
sure that you don't need them. Secure boot is well supported in Debian.
Hope this helps,
Andy Cater
On Fri, Nov 18, 2022 at 08:33:29PM +0100, Franco Martelli wrote:
> On 17/11/22 at 23:11, Andrew M.A. Cater wrote:
> >
> > It may be better to use a longer dd line and also to use the unofficial
> > firmware image available at https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.5.0+nonfree/amd64/iso-cd/firmware-11.5.0-amd64-netinst.iso
> >
> > dd if=firmware-11.5.0-amd64-netinst.iso of=/dev/sdb bs=4M oflag=sync status=progress
> >
> > That makes absolutely sure that the transfer is synced to ensure that it is
> > written to the stick and also gives you some idea of how well the transfer
> > is going.
> >
> > Using the firmware .iso will potentially solve any problems with missing
> > firmwware.
> >
> > The writing to a stick *should* work well.
> >
> > All the very best, as ever,
> >
> > Andy Cater
> >
> I'm not sure but maybe Rob Klingsten is not on the list so I'm not sure that
> he has read your reply please consider to re-send your answer to
> 102...@bugs.debian.org
>
> kind regards
> --
> Franco Martelli
>
r...@tekhax.io
Nov 19, 2022, 10:50:05 AM11/19/22
to
Thanks, after messing with it for quite awhile, I finally got it to work with the standard ISO.
I booted with the Arch live image and did:
wipefs -a /dev/nvme0n1
dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=100000
then I used efibootmgr to delete all existing entries.
Once I did that, the netinst booted into the installer immediately. Not sure if it was the actual existence of valid partitions on the drive, or just the existence of EFI entries in the table.
I can further test to see which scenario it is. I would still consider this a bug?
------- Original Message -------
> > > The writing to a stick should work well.
I booted with the Arch live image and did:
wipefs -a /dev/nvme0n1
dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=100000
then I used efibootmgr to delete all existing entries.
Once I did that, the netinst booted into the installer immediately. Not sure if it was the actual existence of valid partitions on the drive, or just the existence of EFI entries in the table.
I can further test to see which scenario it is. I would still consider this a bug?
------- Original Message -------
On Saturday, November 19th, 2022 at 07:48, Andrew M.A. Cater <amac...@einval.com> wrote:
>
>
> Rob - see below, you might want to subscribe to the bug too.
>
> Suggestion is to use firmware .iso and a more verbose dd line to ensure
> you've actually written the whole image correctly.
>
> Also, I would suggest enabling TPM and secure boot unless you are absolutely
>
>
> Rob - see below, you might want to subscribe to the bug too.
>
> Suggestion is to use firmware .iso and a more verbose dd line to ensure
> you've actually written the whole image correctly.
>
Steve McIntyre
Nov 19, 2022, 5:20:04 PM11/19/22
to
Hi Rob,
I see Andy has been helping you!
On Sat, Nov 19, 2022 at 03:38:33PM +0000, r...@tekhax.io wrote:
>Thanks, after messing with it for quite awhile, I finally got it to work with the standard ISO.
>
>I booted with the Arch live image and did:
>
>wipefs -a /dev/nvme0n1
>dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=100000
>
>then I used efibootmgr to delete all existing entries.
>
>Once I did that, the netinst booted into the installer
>immediately. Not sure if it was the actual existence of valid
>partitions on the drive, or just the existence of EFI entries in the
>table.
If your system has (had) existing EFI boot entries, then the firmware
would normally attempt to boot those. AIUI you selected the USB stick
and that failed to boot?
The partitioning on Debian images is slightly complex, to make them
work as a so-called "isohybrid". (This means that you can use the same
image both when written to optical media and when written to a USB
stick.) But the partitions should still show up. For example, looking
at the netinst image file here:
$ fdisk -l debian-11.5.0-amd64-netinst.iso
Disk debian-11.5.0-amd64-netinst.iso: 382 MiB, 400556032 bytes, 782336 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5004a58b
Device Boot Start End Sectors Size Id Type
debian-11.5.0-amd64-netinst.iso1 * 0 782335 782336 382M 0 Empty
debian-11.5.0-amd64-netinst.iso2 4064 9247 5184 2.5M ef EFI (FAT-12/16/32)
The first partition covers the whole of the image; the second one is
*just* the EFI boot setup that you've seen already. If you're only
seeing the second partition then it appears there is some other
problem here.
Checking your original report here, you said you wrote to the USB
stick using dd if=<debian.iso> of=/dev/sdb. Did you run "sync" or
similar to make 100% sure that the image was all flushed to the USB
stick before removing it / booting it? Unless you tell it otherwise,
Linux will cache writes to USB drives and it can appear that writes
have completed well before the data is actually written to the
drive. This is a common cause of confusion for people in this
situation, I'm afraid.
Andy already mentioned a different way to force writing data, using
the "oflag=sync" option to dd. Using that with "bs=4M" should also
give good performance when writing out an image to a USB stick.
Could you possibly retry this and check if it works for you please?
--
Steve McIntyre, Cambridge, UK. st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"
I see Andy has been helping you!
On Sat, Nov 19, 2022 at 03:38:33PM +0000, r...@tekhax.io wrote:
>Thanks, after messing with it for quite awhile, I finally got it to work with the standard ISO.
>
>I booted with the Arch live image and did:
>
>wipefs -a /dev/nvme0n1
>dd if=/dev/zero of=/dev/nvme0n1 bs=512 count=100000
>
>then I used efibootmgr to delete all existing entries.
>
>Once I did that, the netinst booted into the installer
>immediately. Not sure if it was the actual existence of valid
>partitions on the drive, or just the existence of EFI entries in the
>table.
would normally attempt to boot those. AIUI you selected the USB stick
and that failed to boot?
The partitioning on Debian images is slightly complex, to make them
work as a so-called "isohybrid". (This means that you can use the same
image both when written to optical media and when written to a USB
stick.) But the partitions should still show up. For example, looking
at the netinst image file here:
$ fdisk -l debian-11.5.0-amd64-netinst.iso
Disk debian-11.5.0-amd64-netinst.iso: 382 MiB, 400556032 bytes, 782336 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5004a58b
Device Boot Start End Sectors Size Id Type
debian-11.5.0-amd64-netinst.iso1 * 0 782335 782336 382M 0 Empty
debian-11.5.0-amd64-netinst.iso2 4064 9247 5184 2.5M ef EFI (FAT-12/16/32)
The first partition covers the whole of the image; the second one is
*just* the EFI boot setup that you've seen already. If you're only
seeing the second partition then it appears there is some other
problem here.
Checking your original report here, you said you wrote to the USB
stick using dd if=<debian.iso> of=/dev/sdb. Did you run "sync" or
similar to make 100% sure that the image was all flushed to the USB
stick before removing it / booting it? Unless you tell it otherwise,
Linux will cache writes to USB drives and it can appear that writes
have completed well before the data is actually written to the
drive. This is a common cause of confusion for people in this
situation, I'm afraid.
Andy already mentioned a different way to force writing data, using
the "oflag=sync" option to dd. Using that with "bs=4M" should also
give good performance when writing out an image to a USB stick.
Could you possibly retry this and check if it works for you please?
--
Steve McIntyre, Cambridge, UK. st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"
r...@tekhax.io
Nov 19, 2022, 10:10:05 PM11/19/22
to
Thanks for the detailed message. I started everything over to try to reproduce the problem.
I wiped out the NVMe drive again (wipefs -a and dd if=/dev/zero of=/dev/sdb bs=512 count=100000), and re-installed Pop!OS 22.04 non-NVidia version, which was successful. The computer was operating normally and booting into Pop!OS, no problem.
I then downloaded a new Debian 11.5.0 netinst ISO, checked the SHA512, wrote it to the USB drive with extra parameters mentioned earlier.
I powered off the computer, inserted the USB 3.0 stick into a USB 3.0 port and powered on. I hit F12 to reach the Dell one-time boot menu and chose the USB stick to boot from.
It immediately boots into the Grub CLI as I described before. So either the presence of the Pop!OS partition or the presence of the entry in the UEFI boot table seems to be confusing the Debian USB stick.
------- Original Message -------
> just the EFI boot setup that you've seen already. If you're only
I wiped out the NVMe drive again (wipefs -a and dd if=/dev/zero of=/dev/sdb bs=512 count=100000), and re-installed Pop!OS 22.04 non-NVidia version, which was successful. The computer was operating normally and booting into Pop!OS, no problem.
I then downloaded a new Debian 11.5.0 netinst ISO, checked the SHA512, wrote it to the USB drive with extra parameters mentioned earlier.
I powered off the computer, inserted the USB 3.0 stick into a USB 3.0 port and powered on. I hit F12 to reach the Dell one-time boot menu and chose the USB stick to boot from.
It immediately boots into the Grub CLI as I described before. So either the presence of the Pop!OS partition or the presence of the entry in the UEFI boot table seems to be confusing the Debian USB stick.
------- Original Message -------
Steve McIntyre
Nov 24, 2022, 9:00:03 PM11/24/22
to
On Sun, Nov 20, 2022 at 02:59:10AM +0000, r...@tekhax.io wrote:
>Thanks for the detailed message. I started everything over to try to reproduce the problem.
Thanks for that!
>Thanks for the detailed message. I started everything over to try to reproduce the problem.
>I wiped out the NVMe drive again (wipefs -a and dd if=/dev/zero
>of=/dev/sdb bs=512 count=100000), and re-installed Pop!OS 22.04
>non-NVidia version, which was successful. The computer was operating
>normally and booting into Pop!OS, no problem.
>I then downloaded a new Debian 11.5.0 netinst ISO, checked the
>SHA512, wrote it to the USB drive with extra parameters mentioned
>earlier.
>
>I powered off the computer, inserted the USB 3.0 stick into a USB 3.0
>port and powered on. I hit F12 to reach the Dell one-time boot menu
>and chose the USB stick to boot from.
>
>It immediately boots into the Grub CLI as I described before. So
>either the presence of the Pop!OS partition or the presence of the
>entry in the UEFI boot table seems to be confusing the Debian USB
>stick.
By pure lucky coincidence, yesterday another Debian developer saw a
very similar issue on a Lenovo machine (see bug #1024720), and we
debugged his problem together. I'm thinking that you may have another
instance here. Could you please check for me: does the Pop!OS
installation include a file in the path "/.disk/info" on any of its
partitions?
If so, that will be the cause of the problem here. If so, if you
(temporarily) rename that file then you should find that the Debian
installer will work just fine.
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead
r...@tekhax.io
Nov 24, 2022, 10:40:03 PM11/24/22
to
------- Original Message -------
Steve McIntyre
Nov 25, 2022, 9:10:03 PM11/25/22
to
On Fri, Nov 25, 2022 at 03:28:28AM +0000, r...@tekhax.io wrote:
>
>That seems to have been the problem. Thanks!
Awesome, thanks for confirming. I've just pushed a fix to the
>
>That seems to have been the problem. Thanks!
debian-cd build scripts which should fix this for future builds.
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
0 new messages