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

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 <deblis@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.