On Monday 11 November 2019 14:22:59 Reco wrote: > 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.
I've made 2 passes at a netinstall of buster on that rpi4, once with 10.0 and once with 10.1. both installs worked, both installs yielded an arm64 install. Installing the amanda clients so I could make backups, crashed them without a clue in the logs nominally 4 seconds after the server touched them at backup time. > > 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. > I've not succeeded in wadeing thru that to file a bug yet Reco. Probably my fault but somebody has always had to clean up the mess. > > 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 > or "bzip2 -c <srcfile.tar >outputfile.tar.bz2" redirections > > 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 That level of detail will probably escape from my ancient wet ram by tommorrow, Reco. But I have rx'd a recipe that works, so all is not lost. I should have it done and moved to the download space in an hour or a bit more. Thank you. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
