Bug#722318: Re: Bug#722318: prepend_earlyinitramfs makes inspecting initramfs unnecessarily hard
reopen 722318
severity 722318 wishlist
thanks
On 10-09-13 11:00, maximilian attems wrote:
> On Tue, Sep 10, 2013 at 09:12:29AM +0200, Wouter Verhelst wrote:
>> Package: initramfs-tools
>> Version: 0.113
>> Severity: normal
>>
>> Hi,
>>
>> The initramfs tools generally build an initramfs that is compressed; if
>> a hook script uses the prepend_initramfs function in the hook-functions
>> library, however (as the intel-microcode package does), then that
>> prepended part of the initramfs is not compressed.
>>
>> When I have a problem, usually my preferred way of debugging is to run
>> "mkdir foo; cd foo; zcat $initramfs | cpio -i", and then using normal
>> file operations. When trying that on a file that starts with
>> uncompressed data, zcat will however refuse to open the file (unless the
>> -f parameter is used, but then compression is switched off and not
>> switched on afterwards when we do encounter compressed data); cpio
>> doesn't have a transparent decompress option AFAICT; and I'm not sure
>> how to figure out what the offset of the compressed data is.
>>
>> As a result, the only way that I can see to inspect my initramfs is to
>> uninstall the intel-microcode package, regenerate the initramfs, and
>> inspect it. This can't be the intention.
>>
>
> please bug reports are not for support.
This is not a support question. I know *exactly* what is going on, and
there is no way for me to fix the issue that does not involve either
counting offsets, constantly uninstalling and reinstalling packages, or
editing scripts that will be overwritten at upgrade time of initramfs-tools.
> The bug concerning lsinitramfs is marked and shall be worked on,
Good.
> above is no bug of the initramfs which boots and decompresses just fine.
True, but it makes debugging initramfs hooks and initramfs scripts
harder than strictly necessary for those of us who maintain them in our
packages (case in point: nbd-client).
If this is not a bug in your world view (an argument that I can buy,
even if I'm not in agreement), at least consider it a wishlist request.
The fix should be fairly straightforward (though I note that I haven't
looked at the relevant part of the code yet): do the compression step
*after* prepending data, not before.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Reply to: