Bug#589597: linux-base: The package fails to setup properly on "aptitude upgrade" due to tune2fs error.
Package: linux-base
Version: 2.6.32-15
Severity: important
Doing an upgrade of linux-base recently I noticed this error:
Setting up linux-base (2.6.32-15) ...
tune2fs 1.41.12 (17-May-2010)
tune2fs: Bad magic number in super-block while trying to open /dev/hda8
Couldn't find valid filesystem superblock.
tune2fs failed: 256 at /var/lib/dpkg/info/linux-base.postinst line 1045,
<STDIN> line 10.
dpkg: error processing linux-base (--configure):
subprocess installed post-installation script returned error exit status 9
dpkg: dependency problems prevent configuration of linux-image-2.6.32-5-686:
linux-image-2.6.32-5-686 depends on linux-base (>= 2.6.32-15); however:
Package linux-base is not configured yet.
....
The reason why this happens is rather simple. /dev/hda8 is my /tmp partition
which is formated on every boot using a loop-device with a new random key so
temporary data in /tmp is guaranteed to be inaccessible after reboot or
shutdown. I am not sure if linux-base or tune2fs by itself tries to determine
the device for /tmp. Whichever of the both it is, it fails to see the loop-
device and therefore tune2fs tries to access the partition directly. Of course
it will see only encrypted data there and no valid filesystem structures to do
what it is supposed to do. As a consequence configuration of linux-base fails
leaving two other packages dependent on linux-base unconfigured, too.
A simple invocation of "mount" and "losetup -a" says this:
celebrant:/home/josai# mount
....
/dev/hda8 on /tmp type ext3
(rw,loop=/dev/loop2,phash=random/1777,encryption=AES256)
....
celebrant:/home/josai# losetup -a
/dev/loop2: [0005]:1666 (/dev/hda8) encryption=AES256 multi-key-v3
So the loop-device is indeed there and should be recognized. However, I am not
sure, if it is really important to try to tune the filesystems on setup of
linux-base. Especially in my case as anything tune2fs does on /tmp will be lost
on next reboot. Maybe a small change in the postinst script of linux-base will
solve this bug.
How to reproduce this bug?
I am using the two packages loop-aes-modules and loop-aes-utils to encrypt /tmp
on boot.
This entry in /etc/fstab for the /tmp partition should produce the bug:
/dev/hda8 /tmp ext3
defaults,loop=/dev/loop2,encryption=AES256,phash=random/1777 0 0
Of course /dev/hda8 will have to be replaced by an unused partition. Be
extremely careful here! If you boot this with a wrong partition (one that
contains precious data or even root), then all that data will be gone for good.
If you think that everything is right with the postinst script of linux-base
and that for the above mentioned error tune2fs itself is to blame, then please
feel free to close this bug and I will report a bug for tune2fs.
Sincerely,
AW
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-trunk-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-base depends on:
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii libapt-pkg-perl 0.1.24 Perl interface to libapt-pkg
ii libuuid-perl 0.02-3+b1 Perl extension for using UUID inte
ii udev 158-1 /dev/ and hotplug management daemo
ii util-linux 2.17.2-3.1 Miscellaneous system utilities
linux-base recommends no packages.
linux-base suggests no packages.
-- debconf information:
linux-base/disk-id-manual-boot-loader:
linux-base/disk-id-manual:
linux-base/disk-id-convert-plan-no-relabel: true
* linux-base/disk-id-convert-auto: true
* linux-base/disk-id-convert-plan: true
Reply to: