| Summary: | install-amd64-minimal-20121107 /lib/firmware.tar.bz2 is 0 bytes, init.d/firmware fails, /lib/firmware/ is empty | ||
|---|---|---|---|
| Product: | Gentoo Release Media | Reporter: | Ben Kohler <bkohler> |
| Component: | InstallCD | Assignee: | Gentoo Release Team <releng> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bkohler, djc, fturco, zerochaos |
| Priority: | Normal | ||
| Version: | autobuild | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 455924 | ||
I'm seeing this, too. I've checked, and the CD image I downloaded is not corrupt (i.e. has the same SHA512 hash as the ones in the DIGESTS file). Catalyst's livecdfs-update.sh script uses the following to create the tarball:
cd /lib/firmware
/bin/tar -I lbzip2 -cpf /lib/firmware.tar.bz2 .
rm -rf /lib/firmware/*
This script is run within chroot during stage2 of the livecd build, but lbzip2 is not available within the chroot. Here's what's reported in catalyst's build output:
...
Running livecdfs-update.sh in chroot /var/tmp/catalyst/tmp/default/livecd-stage2-amd64-latest/
tar (child): lbzip2: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
/bin/tar: /lib/firmware.tar.bz2: Cannot write: Broken pipe
/bin/tar: Error is not recoverable: exiting now
removing /var/tmp/catalyst/tmp/default/livecd-stage2-amd64-latest/./tmp/livecdfs-update.sh from the chroot
...
Seems to me that it would be easiest to just use plain bzip2, the firmware tarball isn't big enough that lbzip2 would save much time anyway.
(In reply to comment #2) > Catalyst's livecdfs-update.sh script uses the following to create the > tarball: > > cd /lib/firmware > /bin/tar -I lbzip2 -cpf /lib/firmware.tar.bz2 . > rm -rf /lib/firmware/* > > This script is run within chroot during stage2 of the livecd build, but > lbzip2 is not available within the chroot. Here's what's reported in > catalyst's build output: > > ... > Running livecdfs-update.sh in chroot > /var/tmp/catalyst/tmp/default/livecd-stage2-amd64-latest/ > tar (child): lbzip2: Cannot exec: No such file or directory > tar (child): Error is not recoverable: exiting now > /bin/tar: /lib/firmware.tar.bz2: Cannot write: Broken pipe > /bin/tar: Error is not recoverable: exiting now > removing > /var/tmp/catalyst/tmp/default/livecd-stage2-amd64-latest/./tmp/livecdfs- > update.sh from the chroot > ... > > > Seems to me that it would be easiest to just use plain bzip2, the firmware > tarball isn't big enough that lbzip2 would save much time anyway. You sir, are correct. This was an oversight since on my system lbzip2 *is* available. I'm guessing it is the same for mattst88 who originally proposed this patch. Fixed in git, thanks for pointing out the cause. Per https://bugs.gentoo.org/show_bug.cgi?id=455924#c3 looks like problem is still present, maybe it was generated with old version? |
On this latest install cd iso, the file at /lib/firmware.tar.bz2 is 0 bytes in size. It should be >5MB. As a result, the firmware service throws the following errors at boot: ------------------ * Checking for firmware to unpack ... [ ok ] * Unpacking firmware ... bzip2: Compressed file ends unexpectedly; perhaps it is corrupted? *Possible* reason follows. bzip2: Inappropriate ioctl for device Input file = (stdin), output file = (stdout) It is posssible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the 'bzip2recover' program to attempt to recover data from undamaged sections of corrupted files. ------------------ And, a bit of examination after the boot process, yields: # ls -l /lib/firmware.tar.bz2 -rw-r--r-- 1 root 0 Nov 7 08:45 /lib/fimrware.bz2 # ls -l /lib/firmware total 0 #