Hi. On Mon, Nov 11, 2019 at 01:24:50PM -0500, Gene Heskett wrote: > On Monday 11 November 2019 12:34:08 Greg Wooledge wrote: > > > On Mon, Nov 11, 2019 at 12:08:15PM -0500, Gene Heskett wrote: > > > And its man page says its a 2010 version. And it won't touch a just > > > over 4G built kernel tarball. > > > > > > Suggestions? > > > > 0) Give all the background details of your setup, like what version of > > Debian you're running, what hardware, what version of bzip2 is > > installed, where you got this input file.... > Not debian since your arm is now arm64 from buster on.
Your inability to locate armhf in Debian's main archive is well-known to debian-arm denizens, but please refrain from spreading your hopefully honest errors here. > The problem is that a built kernel is 4038000640 byte when converted to a > tarball, but the best compressor is a 2010 version of bzip2 and it has > an instant tummy ache with that big a file: > > pi@rpi4:/media/pi/slash $ bzip2 -z 4.19.71-rt24-v7l+.tar > bzip2: Can't open input file 4.19.71-rt24-v7l+.tar: Value too large for > defined data type. Confirming, real debian armhf is affected. The problematic place is: $ strace -eopenat bzip2 -z 4038000640 ... openat(AT_FDCWD, "4038000640", O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type) And EOVERFLOW in openat(2) is: pathname refers to a regular file that is too large to be opened. The usual scenario here is that an application compiled on a 32-bit platform without -D_FILE_OFFSET_BITS=64 tried to open a file whose size exceeds (1<<31)-1 bytes; see also O_LARGEFILE above. This is the error specified by POSIX.1; in kernels before 2.6.24, Linux gave the error EFBIG for this case. So, yep, you've found a bug in Debian packaging, consider filling it via proper channels. EOVERFLOW is a known beast, working workarounds are: 1) "busybox bzip2" instead of "bzip2 -z" (-z is kind of redundant anyway). 2) cat foo | bzip2 -c > foo.bz2 > The realtime is totally moot IMO, True, one has to build a binary a certain way. > the size of slightly over 4Gigs is the real problem First, it's *under* 4Gb (assuming right and proper 1024=1Kb): $ echo 4038000640/1024/1024/1024 | bc -l 3.76068115234375 Second, it's actually 2Gb-1 that's problematic. Reco
