Please,check the images below. The image 1 and 2 come from the kernel file unpacked with 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),while on the picture n. 3 You can see all the pictures that are inside the kernel file when I have opened it with engrampa. I don't know where the truth is. I see only contradictory information. Something is lying : who is ? cpio or engrampa ?
1) https://ibb.co/0mCFCW7 2) https://ibb.co/pjGsTY5 3) https://ibb.co/k3TMFsk Il giorno mer 26 ott 2022 alle ore 23:04 Mario Marietto < marietto2...@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 <scdbac...@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. > -- Mario.
