Re: dosfslabel finds problem, e2fsck does not
On Wed, Jul 21, 2010 at 15:53:36 -0400, Thomas H. George wrote:
> On Wed, Jul 21, 2010 at 09:13:59PM +0200, Florian Kulzer wrote:
> > On Wed, Jul 21, 2010 at 10:25:30 -0400, Thomas H. George wrote:
> > > On Wed, Jul 21, 2010 at 08:28:59AM +0200, Florian Kulzer wrote:
> > > > > > > > On Tue, Jul 20, 2010 at 11:25:42 -0400, Thomas H. George wrote:
> > > > > > > > > My system, Squeeze, cannot install the latest kernel image because
> > > > > > > > > dosfslabel finds a problem that prevents the installation of linux-base.
> > > > > > > > >
> > > > > > > > > Trying to resolve this I used e2fsck to check each of the disk
> > > > > > > > > partitions and e2fsck reported all the partitions clean. However, the
> > > > > > > > > result of running dosfslabel /dev/hda1 results in the following output:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > There are differences between boot sector and its backup.
> > > > > > > > > Differences: (offset:original/backup)
[...]
> > > Installation of linux-base still fails as described previously and
> > > dosfslabel /dev/hda1 still gives the error message posted prevously but
> > > e2fsck /dev/hda1 says it is clean.
> >
> > So we still have to find out why the postinst script runs dosfslabel on
> > an ext3 partition. Looking at the script, it seems to assemble a list of
> > filesystems and their types by analyzing /etc/fstab. I would therefore
> > like to see your output for:
> >
> > grep -E 'hda1|2428f3c0|vfat|msdos|ntfs' /etc/fstab
> >
> The output is:
>
> /dev/hda1 /temp ext2 rw,user,auto 0 2
> /dev/sdc /media/fuze vfat rw,user,noauto 0 0
> /dev/sg1 /usbdrive vfat rw,user,noauto 0 0
> /dev/sda /media/usb1 vfat rw,user,noauto 0 0
Nothing here to make the postinst script identify /dev/hda1 as a vfat
partition. (By the way, why do you have "etx2" instead of "ext3" as the
type?)
> I have copied everything on /dev/hda1 and /dev/hda5 on to a backup drive
> and am considering a complete reformat of /dev/hda.
I would think that it should be enough to wipe out and reconstruct the
one problematic partition.
You can try one more thing before that. Here is a list of all the
configuration files that the postinst script seems to take into account
when searching for known block devices (you can run the awk-cut
combination yourself to make sure that your version of linux-base uses
the same files):
$ awk '/my @config_files/,/^$/{if(/path =>.*\//) print $3}' /var/lib/dpkg/info/linux-base.postinst | cut -d\' -f2
/etc/fstab
/boot/grub/menu.lst
/etc/default/grub
/etc/lilo.conf
/etc/silo.conf
/etc/quik.conf
/etc/yaboot.conf
/etc/elilo.conf
/etc/default/extlinux
/etc/udev/rules.d/70-persistent-cd.rules
/etc/initramfs-tools/conf.d/resume
/etc/uswsusp.conf
/etc/crypttab
/etc/mdadm/mdadm.conf
/etc/hdparm.conf
You can check if one of these files is present on your system and
mentions /dev/hda1 as type vfat. If that should turn out to be the case
then it might be enough to remove that reference to solve your problem.
--
Regards, |
Florian |
Reply to: