Just found out, aside for skip_bytes iflag, there is also count_bytes
one. So another fix count be:
113: dd < "$initramfs" skip=$start count=$((end - start))
iflag=skip_bytes,count_bytes 2> /dev/null |
** Description changed:
Speaking about this line in unmkinitramfs:
- 113: dd < "$initramfs" skip=$start count=$((end - start))
+ 113: dd < "$initramfs" skip=$start count=$((end - start))
iflag=skip_bytes 2> /dev/null |
-
- dd's block size is 512 by default. iflag=skip_bytes does not change that.
Both $end and $start are byte-offsets. Hence the count is ($end-$start) blocks
or ($end-$start)*512 bytes which is wrong.
+ dd's block size is 512 by default. iflag=skip_bytes does not change
+ that. Both $end and $start are byte-offsets. Hence the count is
+ ($end-$start) blocks or ($end-$start)*512 bytes which is wrong.
Anyways, the script just works because the count is unneeded: dd's
output is piped into cpio which stops on the first end-of-archive
marker, no matter how much data it is fed with.
I think it is the best to just drop the count option (the patch is
attached).
+ If there is still a need to explicitly limit data fed to cpio, dd is
+ impractical in this case. The only way to count= in bytes is bs=1, which
+ makes dd extremely slow on lengthy data chunks. For example
+ ubuntu-23.10.1-desktop-amd64.iso contains initrd with embedded
+ uncompressed cpio archives of such sizes:
- If there is still a need to explicitly limit data fed to cpio, dd is
impractical in this case. The only way to count= in bytes is bs=1, which makes
dd extremely slow on lengthy data chunks. For example
ubuntu-23.10.1-desktop-amd64.iso contains initrd with embedded uncompressed
cpio archives of such sizes:
-
- 77312
- 7200768
- 78615040
+ 77312
+ 7200768
+ 78615040
A combo of dd+head could be used intead to skip and count respectively:
- 113: dd < "$initramfs" skip=$start iflag=skip_bytes 2> /dev/null |
- head -c$((end - start))
+ 113: dd < "$initramfs" skip=$start iflag=skip_bytes 2> /dev/null |
+ head -c$((end - start)) |
Or even tail+head:
- 113: tail -c+$((start+1)) "$initramfs" | head -c$((end - start))
+ 113: tail -c+$((start+1)) "$initramfs" | head -c$((end - start)) |
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2055055
Title:
unmkinitramfs: wrong and unneeded count= in a dd call
Status in initramfs-tools package in Ubuntu:
New
Bug description:
Speaking about this line in unmkinitramfs:
113: dd < "$initramfs" skip=$start count=$((end - start))
iflag=skip_bytes 2> /dev/null |
dd's block size is 512 by default. iflag=skip_bytes does not change
that. Both $end and $start are byte-offsets. Hence the count is
($end-$start) blocks or ($end-$start)*512 bytes which is wrong.
Anyways, the script just works because the count is unneeded: dd's
output is piped into cpio which stops on the first end-of-archive
marker, no matter how much data it is fed with.
I think it is the best to just drop the count option (the patch is
attached).
If there is still a need to explicitly limit data fed to cpio, dd is
impractical in this case. The only way to count= in bytes is bs=1,
which makes dd extremely slow on lengthy data chunks. For example
ubuntu-23.10.1-desktop-amd64.iso contains initrd with embedded
uncompressed cpio archives of such sizes:
77312
7200768
78615040
A combo of dd+head could be used intead to skip and count
respectively:
113: dd < "$initramfs" skip=$start iflag=skip_bytes 2> /dev/null |
head -c$((end - start)) |
Or even tail+head:
113: tail -c+$((start+1)) "$initramfs" | head -c$((end - start)) |
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2055055/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
