[Bug 2055055] Re: unmkinitramfs: wrong and unneeded count= in a dd call

[Adam Vodopjan]

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
Foundations Bugs, 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