[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



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


Reply to: