Re: armhf version of bzip2 is broken
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>
Reply to: