Hi, Pascal Hambourg wrote: > Why then does parted complain about a block size discrepancy ?
Because the Apple Partition Map announces to count blocks with size 2048 whereas the Linux device file announces 512 (via ioctl(BLKSSZGET) ?)). It is quite a poor choice of parted to hop on the Apple Partition Map rather than onto the MBR partition map, which will be of interest for much more firmwares and operating systems. (I should really pester debian-cd more about that inappropriate option -isohybrid-apm-hfsplus in the xorriso run.) I wrote: > > > But if only a few MB were copied (for what strange reason ever) there > > remains the riddle why it booted and probably loaded the initrd. > > Why does it fail when it looks for the ISO filesystem ? > Probably because the MBR and the boot files are located at the beginning of > the image and were part of the data which were actually written. Well, Kent obviously experienced a running Linux kernel and the attempt to execute software from the initrd. The message "Load installer components from CD" can be found in initrd.gz as package Description which belongs to "load-cdrom" https://packages.debian.org/stretch/load-cdrom This package is not to see as file in the ISO. It could be that there is no problem with finding the "CD-ROM" but rather with installing or activating that package. So maybe it could not even begin its work. About its role in debian-installer https://d-i.alioth.debian.org/doc/talks/debconf6/paper/ says "The first three stages are where the fundamental difference between installation methods can be seen. All components (udebs) used there need to be included in the initrd[2] with which the installer is booted." and lists "load-cdrom (anna) [...] Retrieve and unpack additional components" as part of stage 2. ----------------------------------------------------------------------- So the problem obviously occurs while the installer is still using the initrd. The filename in the ISO is /install.amd/gtk/initrd.gz or /install.amd/initrd.gz. In debian-9.4.0-amd64-xfce-CD-1.iso the initrds and the kernel are stored in the lower blocks indeed. ("Startlba" is the logical block address with 2048 bytes per block. "Blocks" is the number of occupied blocks.): Startlba , Blocks , Filesize , ISO image path =============================================== ... 5642 , 19182 , 39282964 , '/install.amd/gtk/initrd.gz 24824 , 1 , 66 , '/install.amd/gtk/install.b 24825 , 2063 , 4224800 , '/install.amd/gtk/vmlinuz' 24825 , 2063 , 4224800 , '/install.amd/vmlinuz' 26888 , 7667 , 15700220 , '/install.amd/initrd.gz' 34555 , 1 , 45 , '/install.amd/install.bat' ... In debian-buster-DI-alpha2-amd64-xfce-CD-1.iso : Startlba , Blocks , Filesize , ISO image path =============================================== ... 5694 , 19570 , 40077490 , '/install.amd/gtk/initrd.gz' 25264 , 1 , 66 , '/install.amd/gtk/install.bat' 25265 , 2181 , 4466448 , '/install.amd/gtk/vmlinuz' 25265 , 2181 , 4466448 , '/install.amd/vmlinuz' 27446 , 7811 , 15995172 , '/install.amd/initrd.gz' 35257 , 1 , 45 , '/install.amd/install.bat' ... The messages Load installer components from CD There was a problem reading data from the CD-ROM. are well known to the web. But occurences show no pattern about particularly bad releases or spin-off distros. The reported remedies are not much convincing as technical improvements, but they all involve re-copying the ISO onto USB stick. I.e. they all could simply have helped by trying again and having more success with copying. Kent could try to damage the USB stick content for experiments. First: # Damage ISO after the end of initrds and kernel dd if=/dev/zero bs=2048 count=350000 seek=50000 of=/dev/sdc And after checking out the effects of that damage: # Damage the GTK initrd itself dd if=/dev/zero bs=2048 count=40000 seek=10000 of=/dev/sdc (This does not damage the USB stick. Only its content data.) ----------------------------------------------------------------------- Have a nice day :) Thomas
