Bug#1024346: cdrom: debian-11.5.0-amd64-netinst.iso boots to Grub CLI on Dell Optiplex 5090

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 -------
On Saturday, November 19th, 2022 at 17:10, Steve McIntyre <[email protected]> wrote:


> 
> 
> Hi Rob,
> 
> I see Andy has been helping you!
> 
> On Sat, Nov 19, 2022 at 03:38:33PM +0000, [email protected] 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. [email protected]
> < liw> everything I know about UK hotels I learned from "Fawlty Towers"