I've found the error. This command is not good : find . -print -depth | cpio -o > ../../initrd.img-5.10.0-18-amd64
this one can allow the new generated kernel image to boot : find . | cpio --create --format='newc' > ../../initrd.img-5.10.0-18-amd64 I'm not a pro,as I said,but I suspect that the first command misses the part " --format='newc' ". What do you think ? Do you confirm ? Il giorno gio 27 ott 2022 alle ore 23:26 Mario Marietto < marietto2...@gmail.com> ha scritto: > Maybe it won't boot because I should sign again the new kernel file > produced ? > > Il giorno gio 27 ott 2022 alle ore 22:37 Mario Marietto < > marietto2...@gmail.com> ha scritto: > >> You are extremely technical or cpio is extremely technical. Or both,I >> don't know. For sure I'm a hobbyist and I have trouble understanding some >> technical concepts. So,I'm not sure that I have understood. But I tried to >> follow your directions,issuing the commands below. But I've got the same >> error as before : https://ibb.co/rm5WRSz >> >> mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels >> >> mkdir /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped >> >> mkdir >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64 >> >> mkdir >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64 >> >> mkdir >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64 >> >> mkdir -p usr/share/plymouth/ >> >> mkdir -p usr/share/plymouth/themes/homeworld/ >> >> cd /home/ziomario/Scrivania/PassT-Cubic/kernels/ >> >> gunzip -k initrd.img-5.10.0-18-amd64.gz >> gunzip -k initrd.img-5.10.0-19-amd64.gz >> gunzip -k initrd.img-5.19.0-15.2-liquorix-amd64.gz >> >> cpio -idvm < initrd.img-5.10.0-18-amd64 -D >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64 >> >> cpio -idvm < initrd.img-5.10.0-19-amd64 -D >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64 >> >> cpio -idvm < initrd.img-5.19.0-15.2-liquorix-amd64 -D >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64 >> >> cp -p usr/share/plymouth/debian-logo.png >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64/usr/share/plymouth/ >> >> cp -p 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 -p 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 >> >> cp -p usr/share/plymouth/debian-logo.png >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/ >> >> cp -p usr/share/plymouth/themes/homeworld/debian.png >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld >> >> cp -p usr/share/plymouth/themes/homeworld/logo.png >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64/usr/share/plymouth/themes/homeworld >> >> cp -p usr/share/plymouth/debian-logo.png >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/ >> >> cp -p usr/share/plymouth/themes/homeworld/debian.png >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld >> >> cp -p usr/share/plymouth/themes/homeworld/logo.png >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64/usr/share/plymouth/themes/homeworld >> >> mv initrd.img-5.10.0-18-amd64.gz initrd.img-5.10.0-18-amd64.gz-old >> mv initrd.img-5.10.0-19-amd64.gz initrd.img-5.10.0-19-amd64.gz-old >> mv initrd.img-5.19.0-15.2-liquorix-amd64 >> initrd.img-5.19.0-15.2-liquorix-amd64-old >> >> cd >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-18-amd64 >> cd >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.10.0-19-amd64 >> cd >> /home/ziomario/Scrivania/PassT-Cubic/kernels/unzipped/initrd.img-5.19.0-15.2-liquorix-amd64 >> >> find . -print -depth | cpio -o > ../../initrd.img-5.10.0-18-amd64 >> find . -print -depth | cpio -o > ../../initrd.img-5.10.0-19-amd64 >> find . -print -depth | cpio -o > >> ../../initrd.img-5.19.0-15.2-liquorix-amd64 >> >> cd ../.. >> >> gzip initrd.img-5.10.0-18-amd64 >> gzip initrd.img-5.10.0-19-amd64 >> gzip initrd.img-5.19.0-15.2-liquorix-amd64 >> >> Il giorno gio 27 ott 2022 alle ore 20:45 David Wright < >> deb...@lionunicorn.co.uk> ha scritto: >> >>> On Thu 27 Oct 2022 at 14:22:45 (+0200), Mario Marietto wrote: >>> > I tried to follow your directions,using cp >>> > usr/share/plymouth/debian-logo.png instead of cp >>> > /usr/share/plymouth/debian-logo.png. I hope that this is what you >>> intend. >>> >>> Not really. As far as cp is concerned, it copies file1 to file2, >>> or files1…n to directoryD, and dropping the initial "/" will >>> have no effect if PWD is /, and a dramtic effect if PWD is elsewhere. >>> That's pretty basic, though I will say that I would be using cp -ip >>> throughout, in order to maintain the files' metadata, like their >>> timestamps. This makes it easier to check the provenance of files >>> when listed: original files will be old, and files you're playing >>> with will be new, in general. (cpio would also need -m.) >>> >>> What my post was about is whether the initial "/" appears in the >>> pathnames inside the .cpio archive. Typically, .cpio archives are >>> built so that the pathnames inside it are relative. If you make >>> them with absolute paths, you may get surprises when you unpack them. >>> >>> Here's my toy example: >>> >>> /tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null >>> /tmp >>> /tmp/hosts.deny >>> /tmp/hosts.allow >>> /tmp/one >>> /tmp/one/two >>> /tmp/one/two/three >>> /tmp/one/two/three$ find /tmp/host* | cpio -ov --no-absolute-filenames >>> > /tmp/relative.cpio >>> cpio: Removing leading `/' from member names >>> /tmp/hosts.allow >>> /tmp/hosts.deny >>> 3 blocks >>> /tmp/one/two/three$ find /tmp/host* | cpio -ov > /tmp/absolute.cpio >>> /tmp/hosts.allow >>> /tmp/hosts.deny >>> 3 blocks >>> /tmp/one/two/three$ rm -i /tmp/host* >>> rm: remove regular file '/tmp/hosts.allow'? y >>> rm: remove regular file '/tmp/hosts.deny'? y >>> /tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null >>> /tmp >>> /tmp/one >>> /tmp/one/two >>> /tmp/one/two/three >>> /tmp/one/two/three$ >>> >>> So I now have two archives in /tmp, each containing the two well-known >>> original files that I then deleted from the filesystem. I'm currently >>> in /tmp/one/two/three/ (hence the prompt). >>> >>> Here's what will happen in a typical use of cpio archives: >>> >>> /tmp/one/two/three$ cpio -idv -D /tmp/one/two < /tmp/relative.cpio >>> tmp/hosts.allow >>> tmp/hosts.deny >>> 3 blocks >>> /tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null >>> /tmp >>> /tmp/one >>> /tmp/one/two >>> /tmp/one/two/tmp >>> /tmp/one/two/tmp/hosts.deny >>> /tmp/one/two/tmp/hosts.allow >>> /tmp/one/two/three >>> /tmp/one/two/three$ >>> >>> So the files have been placed where expected, in /tmp/one/two/tmp, >>> where /tmp/one/two comes from -D, and tmp/ comes out of the archive. >>> >>> Cleanup: >>> >>> /tmp/one/two/three$ rm -i /tmp/one/two/tmp/hosts.* ; rmdir >>> /tmp/one/two/tmp/ >>> rm: remove regular file '/tmp/one/two/tmp/hosts.allow'? y >>> rm: remove regular file '/tmp/one/two/tmp/hosts.deny'? y >>> /tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null >>> /tmp >>> /tmp/one >>> /tmp/one/two >>> /tmp/one/two/three >>> /tmp/one/two/three$ >>> >>> Here's what happens when you use an archive with absolute pathnames >>> inside it: >>> >>> /tmp/one/two/three$ cpio -idv -D /tmp/one/two < /tmp/absolute.cpio >>> /tmp/hosts.allow >>> /tmp/hosts.deny >>> 3 blocks >>> /tmp/one/two/three$ find /tmp -name [hot]\* 2>/dev/null >>> /tmp >>> /tmp/hosts.deny >>> /tmp/hosts.allow >>> /tmp/one >>> /tmp/one/two >>> /tmp/one/two/three >>> /tmp/one/two/three$ >>> >>> The files are placed in the "wrong" place, under /tmp, and not >>> /tmp/one/two/tmp/. >>> >>> > So,below there are the commands that I have issued : >>> > >>> > [ … ] >>> > >>> > no. Unfortunately the produced kernel files are not able to boot. In >>> Fact >>> > the size is bigger than the original ones. This is the error reported : >>> > >>> > https://ibb.co/rm5WRSz >>> > >>> > I don't know why. Inside the kernel files It seems that everything is >>> ok. I >>> > have placed the wrong files in my google drive. Maybe you want to test >>> them >>> > on your side ? Thanks for your very very useful support. I can tell for >>> > sure that the quality and your patience are the best that I found on >>> the >>> > internet. >>> > >>> > >>> https://drive.google.com/drive/folders/16z5INJTSB3YcpzE980q9eqRIRVG02-JH?usp=sharing >>> >>> I haven't checked all the many commands in the many posts submitted. >>> But I think I have seen along the way some cases where you've >>> archived absolute paths. Again, I haven't checked the fate of those >>> archives and where you might have unpacked them. >>> >>> As I have shown already, it is a simple matter for you to list .cpio >>> archives, and it makes sense to check them all out. Here's an example >>> of a command that should produce just one line unless there are >>> absolute pathnames present: >>> >>> ~$ cpio -t < /tmp/relative.cpio | grep '^/' # conventional >>> 3 blocks >>> ~$ cpio -t < /tmp/absolute.cpio | grep '^/' # unconventional >>> 3 blocks >>> /tmp/hosts.allow >>> /tmp/hosts.deny >>> ~$ >>> >>> Cheers, >>> David. >>> >>> >> >> -- >> Mario. >> > > > -- > Mario. > -- Mario.
