[Bug 1968636] Re: cryptroot-unlock doesn't work at all when terminal width is below 51
After looking deeper into the repo history, I see the questionable implementation of pgrep_exe() was introduced by this patch https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1651818/comments/11 in attempt to adopt the debian code to the ubuntu environment. Aside for other things, it ignores the fact the first line in "ps" output is the header. It was enough to replace .. ps -eo pid= | while read pid; do with .. ps | sed 1d | while read pid _; do and pgrep_exe() would just work. This way terminal width does not affect the ps output in any way. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968636 Title: cryptroot-unlock doesn't work at all when terminal width is below 51 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1968636/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1968636] Re: cryptroot-unlock doesn't work at all when terminal width is below 51
Commenting on #2: When building busybox, there is a number of config switches. For your binary to support "ps -w" you need this in the config: - CONFIG_DESKTOP is not set - CONFIG_FEATURE_PS_WIDE=y On my 22.04 systems I've got 2 busybox binaries: /usr/bin/busybox (2.1M) from busybox-static package and /usr/lib/initramfs-tools/bin/busybox (311K) from busybox-initramfs package. The former was built using debian/config/pkg/static from the source package (CONFIG_DESKTOP=y), it does not support "ps -w". The latter was built with debian/config/pkg/initramfs from the source package (no CONFIG_DESKTOP, CONFIG_FEATURE_PS_WIDE=y), it supports "ps -w" and, evidently, it is the one that gets packaged into initramfs. If your non-desktop busybox was built without CONFIG_FEATURE_PS_WIDE=y, there should be no problem described in this bug report. In the case, terminal width would be assumed 79 [1] To make it work no matter if "ps -w" is supported or not, there are two options, both based on [2] 1. "ps https://git.launchpad.net/ubuntu/+source/busybox/tree/procps/ps.c?h=applied/ubuntu/jammy#n650 [2] https://git.launchpad.net/ubuntu/+source/busybox/tree/libbb/xfuncs.c?h=applied/ubuntu/jammy#n292 [3] https://git.launchpad.net/ubuntu/+source/busybox/tree/libbb/xfuncs.c?h=applied/ubuntu/jammy#n235 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1968636 Title: cryptroot-unlock doesn't work at all when terminal width is below 51 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1968636/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059976] Re: unmkinitramfs is very slow on initrd from ubuntu 23.10+, solution proposed
> I have implemented the listing of uncompressed cpio archives (roughly 120 lines of code). Now I have to add the decompression support Finding offsets of the embedded archives is the only time consuming part of the whole script. Mby it is better to create a separate tool, say "scaninitramfs", to only list offsets and size of embedded archives, just like my tools' "-s" option does, and use it in the original script? Scan output can be of interest beyond unmkinitramfs. For example, if you need to know the compression used in some initrd. With a scan tool you can quickly get the offset of the compressed cpio and "dd .. | file .." -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2059976 Title: unmkinitramfs is very slow on initrd from ubuntu 23.10+, solution proposed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2059976/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060168] Re: Prebuilt signed grub images should include f2fs and exfat modules
> isn't really an intended use-case But there is /boot/grub/loopback.cfg since at least 14.04! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060168 Title: Prebuilt signed grub images should include f2fs and exfat modules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/2060168/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060168] Re: Prebuilt signed grub images should include f2fs and exfat modules
> any practical utility Recent ubuntu desktop iso images are way over 4Gb in size, which is the max file size for fat32. Fat32 for long time was the obvious choice to keep iso images on. Exfat is of interest for those who still need compatibility with w/ndows, like it was with fat32. F2fs is of interest for those who want to use their flash storage with the flash tailored fs. BTW Debian's signed grub image includes f2fs module for 4 years already[1] [1] https://salsa.debian.org/grub- team/grub/-/commit/146d21cc9db01cca6f945e466e4adc31d165782b -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060168 Title: Prebuilt signed grub images should include f2fs and exfat modules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/2060168/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2060168] [NEW] Prebuilt signed grub images should include f2fs and exfat modules
Public bug reported: I guess this is the correct source package to send a feature request for debian/build-efi-images script. Here is what I ask for: --- build-efi-images +++ build-efi-images.new @@ -101,7 +101,9 @@ echo efifwsetup efinet + exfat ext2 + f2fs fat font gettext Motivation: it is pretty easy to make recent ubuntu iso images loopback-boot from f2fs and exfat partitions, but it would not work with secureboot because the signed grub images from grub-efi-amd64-signed do not contain the modules. There are already bug reports for casper to make it boot from f2fs[1] and exfat[2] [1] https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2058826 [2] https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2038694 ** Affects: grub2-unsigned (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2060168 Title: Prebuilt signed grub images should include f2fs and exfat modules To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2-unsigned/+bug/2060168/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2058826] Re: f2fs should be recognized by casper as a supported fs
The script from the post is deprecated now, I converted it into a generic "make casper aware of fs X, add kernel modules Y to the initrd" one. You can get it here https://github.com/slowpeek/ubuntu-remaster-bbb and make 14.04+ images bootable from f2fs like this: ubuntu-remaster-f2fs input.iso output.iso or, without the f2fs shortcut: ubuntu-remaster-bbb --fs f2fs --module f2fs,~crc32_generic,~crc32-pclmul input.iso output.iso If using the docker image: ubuntu-remaster-bbb.docker --fs f2fs --module f2fs,~crc32_generic,~crc32-pclmul -- input.iso output.iso -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2058826 Title: f2fs should be recognized by casper as a supported fs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2058826/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2038694] Re: Now that exfat filesystem is in the kernel, allow using it for storing isos loopback booting and storing the persistence file
Previously I created a script to make ubuntu iso images bootable from f2fs partitions. After discovering this bug, I converted it into a generic "make casper aware of fs X, add kernel modules Y to the initrd" one. You can get it here https://github.com/slowpeek/ubuntu-remaster-bbb and make 20.04+ images bootable from exfat like this: ubuntu-remaster-exfat input.iso output.iso or, without the exfat shortcut: ubuntu-remaster-bbb --fs exfat --module exfat input.iso output.iso If using the docker image: ubuntu-remaster-bbb.docker --fs exfat --module exfat -- input.iso output.iso This way 18.04.5+ can boot from exfat as well, but only with the hwe kernel. Hence in case of live-server 18.04.5+, extra '--hwe-only' option is required. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2038694 Title: Now that exfat filesystem is in the kernel, allow using it for storing isos loopback booting and storing the persistence file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2038694/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2059976] [NEW] unmkinitramfs is very slow on initrd from ubuntu 23.10+, solution proposed
Public bug reported:
Since 23.10 the initrd consists of 4 embedded cpio:
- amd microcode
- intel microcode
- firmware + kernel modules
- rest (compressed)
Previously it was:
- amd microcode
- intel microcode
- rest (compressed)
There is no archive size header for cpio, so unmkinitramfs has to parse
headers of each entry in uncompressed archives.
> time unmkinitramfs 23.04/{initrd,unpack}
real0m3.625s
user0m1.595s
sys 0m3.467s
> time unmkinitramfs 23.10/{initrd,unpack}
real0m15.982s
user0m20.174s
sys 0m6.995s
> for dir in 23.04/unpack/early*; do printf '%-20s %s\n' "$dir" "$(find "$dir"
> | wc -l)"; done
23.04/unpack/early 5
23.04/unpack/early2 6
> for dir in 23.10/unpack/early*; do printf '%-20s %s\n' "$dir" "$(find "$dir"
> | wc -l)"; done
23.10/unpack/early 5
23.10/unpack/early2 6
23.10/unpack/early3 2874
Here https://github.com/slowpeek/unmkinitramfs-turbo I've made it a lot faster
with two changes:
- bash instead of sh for bash's "read -N"
- xxd dump of initrd instead of raw binary data
I wonder, if the developers are interested in accepting my improvements into
the code base?
> time unmkinitramfs-classic-turbo 23.10/{initrd,unpack}
real0m2.209s
user0m2.161s
sys 0m1.341s
> time unmkinitramfs-turbo 23.10/{initrd,unpack}
early .. +
early2 .. +
early3 .. +
main .. +
real0m1.973s
user0m2.094s
sys 0m1.244s
All tools in the repo, even the classic one, feature -s/--scan option. With it,
the tools only dump offset + size for embedded archives, nothing is unpacked.
It can be used to measure parsing speed.
In the repo there are three tools:
- unmkinitramfs-classic: the original tool
- unmkinitramfs-classic-turbo: the improved tool with minimal changes
- unmkinitramfs-turbo: the improved tool with many changes to my tastes, extra
dependency on "file" and some additional features (-ss option, decompression
with 7za)
** Affects: initramfs-tools (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2059976
Title:
unmkinitramfs is very slow on initrd from ubuntu 23.10+, solution
proposed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2059976/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2038694] Re: Now that exfat filesystem is in the kernel, allow using it for storing isos loopback booting and storing the persistence file
@Adrian Feliks (mexit) I've just filed a similar bug about f2fs. The module is in initrd since 20.04 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2038694 Title: Now that exfat filesystem is in the kernel, allow using it for storing isos loopback booting and storing the persistence file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2038694/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2058826] Re: f2fs should be recognized by casper as a supported fs
** Description changed:
Ubuntu iso images bundle the f2fs driver in initrd since 20.04, but
casper does not recognize f2fs as a supported fs even in 24.04. Hence,
the images cant loop-boot from f2fs partitions.
A 2-lines change is all that's required since 20.04 (casper-helpers
since 22.04, previously this code was in lupin-helpers)
- --- casper-helpers
- +++ casper-helpers.new
- @@ -350,7 +350,7 @@
- is_supported_fs(){
- [ -z "${1}" ] && return 1
- case ${1} in
- -ext2|ext3|ext4|xfs|jfs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
- +ext2|ext3|ext4|xfs|jfs|f2fs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
- return 0
- ;;
- esac
- @@ -370,6 +370,7 @@
- modprobe reiserfs
- modprobe xfs
- modprobe jfs
- +modprobe f2fs
- modprobe vfat
- modprobe fuse
- [ "$quiet" != "y" ] && log_end_msg "...devs loaded..."
+ --- casper-helpers
+ +++ casper-helpers.new
+ @@ -350,7 +350,7 @@
+ is_supported_fs(){
+ [ -z "${1}" ] && return 1
+ case ${1} in
+ -ext2|ext3|ext4|xfs|jfs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
+ +ext2|ext3|ext4|xfs|jfs|f2fs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
+ return 0
+ ;;
+ esac
+ @@ -370,6 +370,7 @@
+ modprobe reiserfs
+ modprobe xfs
+ modprobe jfs
+ +modprobe f2fs
+ modprobe vfat
+ modprobe fuse
+ [ "$quiet" != "y" ] && log_end_msg "...devs loaded..."
-
- With some efforts (copy f2fs and crc32 modules from the squashed filesystem
into the initrd) it works down to 18.04 live server and 15.10 desktop.
+ With some efforts (copy f2fs and crc32 modules from the squashed
+ filesystem into the initrd) it works down to 18.04 live server and 15.10
+ desktop.
With such patch it works in 14.04.3 .. 14.04.6 desktop as well
- --- casper-helpers
- +++ casper-helpers.new
- @@ -46,7 +46,15 @@
- echo $FSTYPE
- return 0
- fi
- -/sbin/blkid -s TYPE -o value $1 2>/dev/null
- +/sbin/blkid -s TYPE -o value $1 2>/dev/null || {
- +# Check for f2fs
- +case "$(dd if="$1" skip=2 count=1 2>/dev/null)" in
- +"$(printf '\x10\x20\xf5\xf2')"*)
- +echo f2fs
- +return 0 ;;
- +esac
- +return 1
- +}
- }
-
- where_is_mounted() {
+ --- casper-helpers
+ +++ casper-helpers.new
+ @@ -46,7 +46,15 @@
+ echo $FSTYPE
+ return 0
+ fi
+ -/sbin/blkid -s TYPE -o value $1 2>/dev/null
+ +/sbin/blkid -s TYPE -o value $1 2>/dev/null || {
+ +# Check for f2fs
+ +case "$(dd if="$1" skip=2 count=1 2>/dev/null)" in
+ +"$(printf '\x10\x20\xf5\xf2')"*)
+ +echo f2fs
+ +return 0 ;;
+ +esac
+ +return 1
+ +}
+ }
+ where_is_mounted() {
- My script to apply the changes:
https://github.com/slowpeek/ubuntu-remaster-f2fs
+ My script to apply the changes: https://github.com/slowpeek/ubuntu-
+ remaster-f2fs
** Description changed:
Ubuntu iso images bundle the f2fs driver in initrd since 20.04, but
casper does not recognize f2fs as a supported fs even in 24.04. Hence,
the images cant loop-boot from f2fs partitions.
A 2-lines change is all that's required since 20.04 (casper-helpers
since 22.04, previously this code was in lupin-helpers)
- --- casper-helpers
- +++ casper-helpers.new
- @@ -350,7 +350,7 @@
- is_supported_fs(){
- [ -z "${1}" ] && return 1
- case ${1} in
- -ext2|ext3|ext4|xfs|jfs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
- +ext2|ext3|ext4|xfs|jfs|f2fs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
- return 0
- ;;
- esac
- @@ -370,6 +370,7 @@
- modprobe reiserfs
- modprobe xfs
- modprobe jfs
- +modprobe f2fs
- modprobe vfat
- modprobe fuse
- [ "$quiet" != "y" ] && log_end_msg "...devs loaded..."
+ --- casper-helpers
+ +++ casper-helpers.new
+ @@ -350,7 +350,7 @@
+ is_supported_fs(){
+ [ -z "${1}" ] && return 1
+ case ${1} in
+ -ext2|ext3|ext4|xfs|jfs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
+ +ext2|ext3|ext4|xfs|jfs|f2fs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
+ return 0
+ ;;
+ esac
+ @@ -370,6 +370,7 @@
+ modprobe reiserfs
+ modprobe xfs
+ modprobe jfs
+ +modprobe f2fs
+ modprobe vfat
+ modprobe fuse
+ [ "$quiet" != "y" ] && log_end_msg "...devs loaded..."
With some efforts (copy f2fs and crc32 modules from the squashed
filesystem into the initrd) it works down to 18.04 live server and 15.10
desktop.
With such patch it works in 14.04.3 ..
[Bug 2038694] Re: Now that exfat filesystem is in the kernel, allow using it for storing isos loopback booting and storing the persistence file
@Adrian Feliks (mexit) How is it supposed to work with just that? Looking into initrd of 24.04 daily unpacked with unmkinitramfs. According to main/lib/modules/6.8.0-11-generic/modules.builtin, exfat is not a builtin module. And there is no exfat in early3/usr/lib/modules/6.8.0-11-generic/kernel/fs -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2038694 Title: Now that exfat filesystem is in the kernel, allow using it for storing isos loopback booting and storing the persistence file To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2038694/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2058826] [NEW] f2fs should be recognized by casper as a supported fs
Public bug reported:
Ubuntu iso images bundle the f2fs driver in initrd since 20.04, but
casper does not recognize f2fs as a supported fs even in 24.04. Hence,
the images cant loop-boot from f2fs partitions.
A 2-lines change is all that's required since 20.04 (casper-helpers
since 22.04, previously this code was in lupin-helpers)
--- casper-helpers
+++ casper-helpers.new
@@ -350,7 +350,7 @@
is_supported_fs(){
[ -z "${1}" ] && return 1
case ${1} in
-ext2|ext3|ext4|xfs|jfs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
+ext2|ext3|ext4|xfs|jfs|f2fs|reiserfs|vfat|ntfs|iso9660|btrfs|udf)
return 0
;;
esac
@@ -370,6 +370,7 @@
modprobe reiserfs
modprobe xfs
modprobe jfs
+modprobe f2fs
modprobe vfat
modprobe fuse
[ "$quiet" != "y" ] && log_end_msg "...devs loaded..."
With some efforts (copy f2fs and crc32 modules from the squashed filesystem
into the initrd) it works down to 18.04 live server and 15.10 desktop.
With such patch it works in 14.04.3 .. 14.04.6 desktop as well
--- casper-helpers
+++ casper-helpers.new
@@ -46,7 +46,15 @@
echo $FSTYPE
return 0
fi
-/sbin/blkid -s TYPE -o value $1 2>/dev/null
+/sbin/blkid -s TYPE -o value $1 2>/dev/null || {
+# Check for f2fs
+case "$(dd if="$1" skip=2 count=1 2>/dev/null)" in
+"$(printf '\x10\x20\xf5\xf2')"*)
+echo f2fs
+return 0 ;;
+esac
+return 1
+}
}
where_is_mounted() {
My script to apply the changes: https://github.com/slowpeek/ubuntu-remaster-f2fs
** Affects: casper (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2058826
Title:
f2fs should be recognized by casper as a supported fs
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/2058826/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2055055 Title: unmkinitramfs: wrong and unneeded count= in a dd call To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2055055/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2055055 Title: unmkinitramfs: wrong and unneeded count= in a dd call To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2055055/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2055055 Title: unmkinitramfs: wrong and unneeded count= in a dd call To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2055055/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 2055055] [NEW] unmkinitramfs: wrong and unneeded count= in a dd call
Public bug reported: 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)) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Patch added: "dd-count.patch" https://bugs.launchpad.net/bugs/2055055/+attachment/5749511/+files/dd-count.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2055055 Title: unmkinitramfs: wrong and unneeded count= in a dd call To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2055055/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
