Hi,
i wrote:
> > This would be a preparation for a method that works by unpacking.
Luis Speciale wrote:
> ?
There are two ways to bring a bootable ISO onto a USB stick:
- The old way is to create a partition with a filesystem (FAT32 is not
the best choice because it has so poor filenames),
to copy the files out of the ISO into the created filesystem,
and to install a boot loader which starts the same programs as the boot
loader in the ISO would do if the ISO gets booted from a DVD.
This needs knowlege about how the software in the ISO works. So you
normally find instructions for a particular GNU/Linux distro like
Debian, Ubuntu, Fedora, OpenSuSE, Arch, Gentoo, ...
- The new way needs a hybrid ISO image with a Master Boot Record and a
partition table with EFI system partition. These two structures get used
by PC BIOS or EFI, respectively, when they encounter the ISO on a hard
disk or USB stick.
To become recognizable by the firmware, the MBR has to sit at block 0
of the disk or USB stick. It also hosts the partition table or the
indication that there is a GUID partition table (GPT). So both firmwares
demand that the ISO image copy begins at block 0.
Thus the ISO needs to be copied onto the overall disk device file,
not onto a disk partition device file, and especially not into the
directory where some filesystem of the USB stick is mounted.
No filesystem of the USB stick should be mounted when it gets overwritten,
because afterwards its old data are likely to be gone.
> > I expect that now your self-made FAT32 is gone from the USB stick,
> > because the partition table was overwritten by the ISO.
> > Nevertheless, there is again a FAT filesystem, which contains initial EFI
> > boot equipment of the ISO.
> ??
By using the second way, you overwrote the MBR and partition table of the
USB stick. So now it bears the MBR and partition table of the ISO.
The partition table of the ISO contains this
$ /sbin/fdisk -l firmware-9.1.0-amd64-netinst.iso
Disk firmware-9.1.0-amd64-netinst.iso: 325 MiB, 340787200 bytes, 665600
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: 0x7db1c45b
Device Boot Start End Sectors Size Id Type
firmware-9.1.0-amd64-netinst.iso1 * 0 665599 665600 325M 0 Empty
firmware-9.1.0-amd64-netinst.iso2 3984 4815 832 416K ef EFI
(FAT-12
Partition 1 can be used to mount the ISO. Its type 0 = "Empty" is
a necessity of our crammed hybrid ISO. We need to please EFI firmware.
As you can see, partition 2 is a FAT12 of type 0xef = "EFI". Let's have a
look into it:
$ sudo mount -o loop firmware-9.1.0-amd64-netinst.iso /mnt/iso
mount: /dev/loop0 is write-protected, mounting read-only
Being involved expert, i know that /boot/grub/efi.img is the ISO filename
of the data file which is marked by partition 2:
$ sudo mount -o loop /mnt/iso/boot/grub/efi.img /mnt/fat
(There are ways to find out the name or to mount it by its partition info.)
Now i can list the files in the FAT filesystem
$ find /mnt/fat
/mnt/fat
/mnt/fat/efi
/mnt/fat/efi/boot
/mnt/fat/efi/boot/bootx64.efi
So the FAT12 filesystem contains just the single data file which EFI will
look for on a amd64 machine, normally known by its DOS name:
\EFI\BOOT\BOOTX64.EFI
This file was made by program grub-mkimage. Its only purpose is to find
the device on which the ISO is presented and to load and start the GRUB2
configuration in the ISO directory /boot. At its end one can see these
GRUB2 configuration commands as human readable text:
search --file --set=root /.disk/info
set prefix=($root)/boot/grub
source $prefix/x86_64-efi/grub.cfg
(memdisk)/boot/grub
The existence of file /.disk/info is considered a unique property of the
Debian ISO (Steve: Is this really good enough ?). So the first filesystem
with that file gets used as source of further GRUB brain.
The starting point of that brain is file
/mnt/iso/boot/grub/x86_64-efi/grub.cfg
which loads
/mnt/iso/boot/grub/grub.cfg
In there you will find texts which you also can see in the first menu
of the booting Debian ISO:
menuentry --hotkey=g 'Graphical install' {
menuentry --hotkey=i 'Install' {
submenu --hotkey=a 'Advanced options ...' {
menuentry --hotkey=s 'Install with speech synthesis' {
Let's revoke "sudo mount" before we go on:
$ sudo umount /mnt/fat
$ sudo umount /mnt/iso
> I forgot to tell that I omited this jessie part. I only did
> apt-get update
> apt-get install firmware-realtek
> apt-get install firmware-linux-nonfree
First:
Very very good you skipped the reference to the old-stable system.
Obviously the non-free-firmware ISO already is prepared to use the
non-free repository of Debian 9.
Second:
I understand you got no good graphics but were able to enter shell
commands like apt-get.
Right ?
(Your previous reports stated that installation hung at some late stage.)
> I was near (a couple of times) of giving up.
That's a good sign. If it does not offer resistence then it s not worth.
As software developer i am always mistrusting if a new feature does not
show buggy behavior on the first test. Then it hides something evil ...
Have a nice day :)
Thomas
