Re: Some of the parameters used in my genisoimage command don't produce a bootable ISO image

Il giorno mer 26 ott 2022 alle ore 23:04 Mario Marietto <marietto2008@gmail.com> ha scritto:

Hello to everyone.

I'm trying to understand the reasons why the kernel file that I generate does not work correctly. Maybe I've understood something,but I don't have a clear picture of the problem. I want to try to explain what's wrong using my method of _expression_ because I find it easier. A more "advanced" way may be able to help you,but it will not help me and the result will be that we will not understand each other. So. I've created the folder called "kernels" like this :

mkdir -p /home/ziomario/Scrivania/PassT-Cubic/kernels/

inside of it I have copied the following kernel file :

initrd.img-5.10.0-18-amd64.gz

it is unaltered. I haven't added any logos and pictures inside of it. After this,I have created two more folders :

mkdir -p /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped
mkdir -p /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64

and then I did :

cd /home/ziomario/Scrivania/PassT-Cubic/kernels/

gunzip -k initrd.img-5.10.0-18-amd64.gz

cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64

Every time I give the latest command (the cpio one),something odd happens and I don't understand the reason. Inside the folder "/usr/share/plymouth/themes/homeworld",two new files are created : debian.png and logo.png. The first one is correct. I mean,this is one of the pictures that I want to add inside the kernel file. But the second file,logo.png is wrong. It is an old picture that I used sometime ago and that I don't use anymore because I created a new logo. Let's say that the folder "/usr/share/plymouth" and "/usr/share/plymouth/themes/underworld" are two folders that I have created on my host os and inside of them I have stored the correct pictures that I want to add inside the kernel file. Later in the process,I issue the below commands to copy the correct images inside the kernel file before re-packing it.

cp /usr/share/plymouth/debian-logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/

cp /usr/share/plymouth/themes/homeworld/debian.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworld

cp /usr/share/plymouth/themes/homeworld/logo.png /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/themes/homeworld

At the moment I haven't reached that step because the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64) behavior is not expected.

Since I'm using unaltered kernel files,I don't know where the cpio command (cpio -idv < initrd.img-5.10.0-18-amd64 -D /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64) gets those images when I run it. And most of all,I don't know why those pictures are copied inside the folder "/usr/share/plymouth/themes/underworld",overwriting the already existing pictures that are already there. As I repeat,those files aren't stored inside the kernel file (initrd.img-5.10.0-18-amd64),because it is unaltered and it contains only the default debian pictures,which are different from mine. I hope that I have been clear. Sorry I don't have another way to explain what happens other than my narrative.

Il giorno mar 25 ott 2022 alle ore 22:50 Thomas Schmitt <scdbackup@gmx.net> ha scritto:
Hi,

Mario Marietto wrote:
> You seem to understand well what I'm trying to do and you are
> able to give good suggestions.

Probably i only have a good run of guessing here.

> It seems that there isn't any CPIO
> parameter that overwrites the old image. Is this correct ?

I am not aware of any. The nature of a sequential archive does not invite
for random access changes.

> I remember that
> the old method (unpack and repack the files inside the kernel image) failed.
> I'm not able to understand why.

Understanding what special detail spoils this normally well working
method whould probably be helpful for your goals. You'd have to compare
what's in a working appended initrd and one that was freshly packed up
and does not work. (cpio -t <initrd)

> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64_
> mv initrd.img-5.10.0-19-amd64 initrd.img-5.10.0-19-amd64-
> find [...] | cpio -ov > ../initrd.img-5.10.0-19-amd64

I find your re-usal of that lengthy file name confusing.
Consider to give the various intermediate archives and directories shorter
names and to use the name initrd.img-5.10.0-19-amd64.gz only at the start
and the end of your procedure.

Hopefully this will make more clear what causes the difference in size.
Comparing the cpio -t of both initrds might give important hints.

> Or maybe another solution is to append a new image inside the
> kernel image only when a new kernel is detected.

How about storing the paths and checksums of vmlinuz and initrd in a file
(or two) and comparing them with the checksums when the system boots up ?
md5sum should suffice to detect any change.

You'd have to determine the exact paths of the files to checksum. Maybe
they even change by the installation events, so that you have to repeat
that determination after each installation events.

You's also have to find a safe and persistent spot in the filesystem which
does not get influenced by installation events, where you can store the
file with the recorded paths and checksums.

Have a nice day :)

Thomas

--
Mario.