busybox cpio generate invalid archive. Reproduction script, with dataset in archive.
Archive with "test suite" just run shell script. Good and bad files will be generated (busybox cpio and cpio): https://ufile.io/inz57nv9
$ ./TEST_case.sh Running correct unpack 27049 blocks Running damaged unpack cpio: warning: skipped 9408 bytes of junk cpio: warning: skipped 152 bytes of junk cpio: warning: skipped 152 bytes of junk cpio: warning: skipped 91828 bytes of junk cpio: warning: skipped 75008 bytes of junk cpio: warning: skipped 152 bytes of junk cpio: warning: skipped 5268 bytes of junk cpio: warning: skipped 620000 bytes of junk cpio: warning: skipped 152 bytes of junk cpio: warning: skipped 1084136 bytes of junk cpio: warning: skipped 144 bytes of junk cpio: warning: skipped 160 bytes of junk cpio: warning: skipped 164 bytes of junk cpio: warning: skipped 969948 bytes of junk cpio: warning: skipped 17708 bytes of junk cpio: warning: skipped 148 bytes of junk cpio: warning: skipped 152 bytes of junk cpio: warning: skipped 152 bytes of junk cpio: warning: skipped 152 bytes of junk cpio: warning: skipped 301076 bytes of junk cpio: warning: skipped 148 bytes of junk cpio: warning: skipped 38236 bytes of junk cpio: warning: skipped 165224 bytes of junk cpio: warning: skipped 140 bytes of junk cpio: warning: skipped 144 bytes of junk cpio: warning: skipped 350556 bytes of junk cpio: warning: skipped 140 bytes of junk cpio: warning: skipped 280428 bytes of junk 27049 blocks
Can't reproduce: my busybox created a cpio which unpacks to exactly the same files as dataset/* Please post your .config file
Created attachment 8296 [details] busybox-1.31.1
My machine is amd64, kernel 5.3. Reproducible on - my main system with Gentoo - with alpine (postmarketOS) in chroot running inside.
So, I tested on different EXT4 partition and it also worked just fine. Since my parition is encrypted with CONFIG_FS_ENCRYPTION=y (e4crypt, but also fscrypt utility can be used), they're - incorrectly packed with busybox cpio - correctly packed with standalone cpio So, can be reproduced only on encrypted EXT4 filesystem. Also I'd like to say, that I didn't encounter any issue and using this setup for long time, so I presume, that filesystem with encryption probably working correctly. My guess is busybox cpio incorrectly grab encrypted data?
Reproducing: # dd if=/dev/zero bs=4K count=100000 of=/tmp/filesystem # losetup /dev/loop1 /tmp/filesystem # mkfs.ext4 -O encrypt -b 4096 /dev/loop1 # mkdir -p /mnt/test # mount /dev/loop1 /mnt/test # mkdir /mnt/test/a # cd /mnt/test # e4crypt add_key a # choose random password # cd a unpack archive into /mnt/test/a # ./TEST_case.sh 100% reproducible. Tested on animals.
There should be no way for cpio to know that it's on an encrypted fs. I suggest running the same cpio invocation under strace, on the same set of files, once on unencrypted fs, second time on the encrypted fs. A-la: strace -o CPIO_GOOD.log -f -s99 cpio .... and then compare the resulting logs line-by-line, to see where things start to diverge. If you don't find the problem this way, attach strace logs to this bug.
Created attachment 8321 [details] cpio_strace.log no difference between strace on encrypted and unencrypted fs.
Created attachment 8386 [details] strace_log_damanaged-busybox_cpio.txt reupload testcase: https://ufile.io/59z7axpw I tried to do strace between busybox and cpio. It seems like cpio works with encrypted data differently. Due to filesize limit, good cpio log is here: https://ufile.io/7o8g032i
Can debug this issue from different angle? Or if you're sure it's kernel bug, I'll fill bug at bugzilla.kernel.org . Thank you
Kindly reminder, can you give me a hand on this issue please? Thank you
Hello, is there anything more I can do about this issue?
Can I supply any more useful debug informations? Thank you
Issue is still valid, is there anyone interested in fixing it?