Re: USB Install Fails, Complains about CD-ROM
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
Reply to: