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.
