From: owner@bugs.debian.org
This is a multi-part message in MIME format...
Your message dated Mon, 17 Nov 2025 00:21:12 +0100
with message-id <169021777d6c9d9f7a7b53a954eb07bc68d46570.camel@
ecadent.org.uk>
and subject line Re: Comment in the source of unmkinitramfs is ambiguous
has caused the Debian Bug report #894294,
regarding Comment in the source of unmkinitramfs is ambiguous
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
894294: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894294
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
Received: (at submit) by bugs.debian.org; 28 Mar 2018 12:19:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.1-bugs.debian.org_2005_01_02
(2015-04-28) on buxtehude.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-18.4 required=4.0 tests=BAYES_00,DIGITS_LETTERS,
FOURLA,FROMDEVELOPER,FVGT_m_MULTI_ODD,RCVD_IN_DNSWL_MED,TXREP,
T_RP_MATCHES_RCVD,WORD_WITHOUT_VOWELS,X_DEBBUGS_CC autolearn=ham
autolearn_force=no version=3.4.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 44; hammy, 150; neutral, 420; spammy,
0. spammytokens: hammytokens:0.000-+--rw-r, 0.000-+--i915,
0.000-+--snd_hda_intel, 0.000-+--dm_mod, 0.000-+--sk:snd_hda
Return-path:
Received: from mailly.debian.org ([2001:41b8:202:deb:6564:a62:52c3:4b72])
from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,
N=mailly.debian.org,EMAIL=hostmaster@mailly.debian.org (verified)
by buxtehude.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.89)
(envelope-from )
id 1f1A2f-0007e0-0c
for submit@bugs.debian.org; Wed, 28 Mar 2018 12:19:01 +0000
Received: from paradis2.debian.org ([2001:41c8:1000:21::21:31] h
lo=paradis.debian.org)
from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,
N=paradis.debian.org,EMAIL=hostmaster@paradis.debian.org (verified)
by mailly.debian.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.89)
(envelope-from )
id 1f1A2d-0003jF-GT
for submit@bugs.debian.org; Wed, 28 Mar 2018 12:18:59 +0000
Received: from osamu by paradis.debian.org with local (Exim 4.89)
(envelope-from )
id 1f1A2c-0000sm-A5
for submit@bugs.debian.org; Wed, 28 Mar 2018 12:18:58 +0000
Date: Wed, 28 Mar 2018 21:18:54 +0900
From: Osamu Aoki
To: Debian Bug Tracking System
Subject: Comment in the source of unmkinitramfs is ambiguous
Message-ID: <20180328121854.GA3183@goofy.tc4.so-net.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Reportbug-Version: 7.1.10
X-Debbugs-Cc: osamu@debian.org
User-Agent: Mutt/1.9.4 (2018-02-28)
Delivered-To: submit@bugs.debian.org
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-
2e0-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_thermal 16384 0
intel_powerclamp 16384 0
coretemp 16384 0
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
