Bug#894294: Comment in the source of unmkinitramfs is ambiguous

2019-02-03 Thread Ben Hutchings
On Wed, 28 Mar 2018 21:18:54 +0900 Osamu Aoki  wrote:
> Source: initramfs-tools
> Version: 0.130
> Severity: wishlist
> 
> The line 56-59 of unmkinitramfs goes:
> 
>  # There may be a prepended uncompressed archive.  cpio
>  # won't tell us the true size of this so we have to
>  # parse the headers and padding ourselves.  This is
>  # very roughly based on linux/lib/earlycpio.c
> 
> The claim "cpio won't tell us the true size of this ..." doesn't have
> any explicit reference to substantiate its claim while my uneducated
> simple use of cpio telling me the true file size without the tailing
> garbage ;-)
>
> For example:
> 
> $ cpio -i -t /dev/null
> 48 blocks
> 
> So the uncompressed cpio file size is 512*48 BYTES.  With some simple
> experimentation with cpio, I realize cpio always create file size in
> multiple of 512 bytes and it treat 512 bytes as a block.  I can extract
> tailing basic initrd image file as subinitrd.img with:
> 
> $ dd if=/initrd.img of=subinitrd.img bs=512 skip=48
> 
> At least on my recent Debian system, this subinitrd.img is a nicely
> extracted gzipped cpio archive.
[...]

This code started life in bug #717805 and you can see there that
various people found different behaviour.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.



signature.asc
Description: This is a digitally signed message part


Bug#894294: Comment in the source of unmkinitramfs is ambiguous

2018-03-28 Thread Osamu Aoki
Source: initramfs-tools
Version: 0.130
Severity: wishlist

The line 56-59 of unmkinitramfs goes:

 # There may be a prepended uncompressed archive.  cpio
 # won't tell us the true size of this so we have to
 # parse the headers and padding ourselves.  This is
 # very roughly based on linux/lib/earlycpio.c

The claim "cpio won't tell us the true size of this ..." doesn't have
any explicit reference to substantiate its claim while my uneducated
simple use of cpio telling me the true file size without the tailing
garbage ;-)

For example:

$ cpio -i -t /dev/null
48 blocks

So the uncompressed cpio file size is 512*48 BYTES.  With some simple
experimentation with cpio, I realize cpio always create file size in
multiple of 512 bytes and it treat 512 bytes as a block.  I can extract
tailing basic initrd image file as subinitrd.img with:

$ dd if=/initrd.img of=subinitrd.img bs=512 skip=48

At least on my recent Debian system, this subinitrd.img is a nicely
extracted gzipped cpio archive.

I am sure you had a reason why you made extensive binary file tracing
code.  If it was previous bug in cpio, it's nice to reference it.  If
there are some non-GNU/Linux cpio implementations having such problems,
it's nice to be specific.

It seems GNU version of cpio reports its true file size in blocks
whenever with -i option.

If this block based file size identification is OK, please consider
using it to simplify the code.

== Background ==

I was thinking to update initramfs related Debian wiki pages and
realized simple method I was using seems to be problematic if your
comment has some history behind.

  https://wiki.debian.org/initramfs

Osamu

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 27M Mar 28 01:22 /boot/initrd.img-4.14.0-3-amd64
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.14.0-3-amd64 
root=UUID=fde2800b-8afc-42e0-87b2-d7c8909dcea0 ro

-- resume
RESUME=UUID=4e3bd2a9-a62f-4d3f-9945-0719726af7c5
-- /proc/filesystems
btrfs
ext3
ext2
ext4
fuseblk

-- lsmod
Module  Size  Used by
fuse  118784  3
snd_hda_codec_hdmi 57344  1
intel_rapl 24576  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
coretemp   16384  0
kvm_intel 225280  0
kvm   700416  1 kvm_intel
irqbypass  16384  1 kvm
crct10dif_pclmul   16384  0
crc32_pclmul   16384  0
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
snd_hda_codec_realtek   106496  1
i915 1613824  25
snd_hda_codec_generic86016  1 snd_hda_codec_realtek
ghash_clmulni_intel16384  0
intel_cstate   16384  0
intel_uncore  131072  0
snd_soc_rt5640118784  0
intel_rapl_perf16384  0
drm_kms_helper192512  1 i915
snd_hda_intel  45056  10
joydev 24576  0
snd_soc_rl6231 16384  1 snd_soc_rt5640
pcspkr 16384  0
serio_raw  16384  0
evdev  28672  12
mei_me 45056  0
snd_hda_codec 151552  4 
snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
drm   438272  16 i915,drm_kms_helper
snd_hda_core   90112  5 
snd_hda_intel,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
lpc_ich28672  0
i2c_algo_bit   16384  1 i915
mei   114688  1 mei_me
sg 36864  0
mfd_core   16384  1 lpc_ich
snd_hwdep  16384  1 snd_hda_codec
shpchp 40960  0
snd_soc_core  258048  1 snd_soc_rt5640
snd_compress   24576  1 snd_soc_core
snd_pcm   118784  6 
snd_hda_intel,snd_hda_codec,snd_hda_core,snd_soc_rt5640,snd_hda_codec_hdmi,snd_soc_core
video  45056  1 i915
snd_timer  36864  1 snd_pcm
snd94208  30 
snd_compress,snd_hda_intel,snd_hwdep,snd_hda_codec,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek,snd_soc_core,snd_pcm
soundcore  16384  1 snd
intel_smartconnect 16384  0
acpi_pad   24576  0
button 16384  1 i915
parport_pc 32768  0
ppdev  20480  0
lp 20480  0
parport57344  3 lp,parport_pc,ppdev
loop   32768  0
dm_crypt   40960  0
ip_tables  28672  0
x_tables   40960  1 ip_tables
autofs449152  3
ext4  720896  1
crc16  16384  1 ext4
mbcache16384  1 ext4
jbd2  118784  1 ext4
fscrypto   32768  1 ext4
ecb16384  0
btrfs1339392  0
zstd_decompress94208  1 btrfs
zstd_compress 188416  1 btrfs
xxhash 16384  2 zstd_compress,zstd_decompress
raid10 57344  0
raid456   163840  0