[Touch-packages] [Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call
This bug was fixed in the package initramfs-tools - 0.142ubuntu20 --- initramfs-tools (0.142ubuntu20) noble; urgency=medium [ Benjamin Drung ] * Fix determing multiarch dir when using libc6-prof's libc.so.6 (LP: #2054171) * autopkgtest: Use qemu-system-$(dpkg --print-architecture) [ Adam Vodopjan ] * unmkinitramfs: add count_bytes iflag in a dd call (LP: #2055055) [ Florent 'Skia' Jacquet ] * d/t/test-common: fix finding klibc.so -- Benjamin Drung Sat, 02 Mar 2024 17:08:38 +0100 ** Changed in: initramfs-tools (Ubuntu) Status: Fix Committed => Fix Released -- 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: Fix Released 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
[Touch-packages] [Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call
** Changed in: initramfs-tools (Ubuntu) Status: Triaged => Fix Committed -- 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: Fix Committed 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
[Touch-packages] [Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call
https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/92 -- 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: Triaged 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
[Touch-packages] [Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call
> The count_bytes solution looks better to me The updated patch is attached. I've just checked: all the *_bytes flags were introduced to dd in the same commit https://github.com/coreutils/coreutils/commit/140eca15c4a3d3213629a048cc307fde0d094738, so it is safe to throw in count_bytes in the mix. > I see four dd calls in unmkinitramfs. Can you check those as well? The other dd calls are good: - 2x of bs=1 kind - the last one is "dump from X till the end" utilizing skip_bytes for X, which is correct > Debian is affected as well. If you can spare the time, please submit your patch Will do when they activate my just created account on salsa ** Patch added: "Add count_bytes iflag" https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2055055/+attachment/5749755/+files/dd-count-2.patch -- 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: Triaged 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
[Touch-packages] [Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call
Thank you for taking the time to report this bug and contributing to Ubuntu. The count_bytes solution looks better to me. I see four dd calls in unmkinitramfs. Can you check those as well? Debian is affected as well. If you can spare the time, please submit your patch to https://salsa.debian.org/kernel-team/initramfs- tools/-/merge_requests as well. ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Low ** Changed in: initramfs-tools (Ubuntu) Status: New => Triaged -- 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: Triaged 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
[Touch-packages] [Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call
The attachment "dd-count.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] ** Tags added: patch -- 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
[Touch-packages] [Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call
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
