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 <st...@einval.com> wrote: > > > 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"
