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.
