[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dosfslabel finds problem, e2fsck does not



On Tue, Jul 20, 2010 at 07:23:31PM +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)
> >   0:eb/01, 1:58/00, 2:90/04, 4:53/02, 5:57/00, 6:49/04, 7:4e/00, 8:34/0c
> >   , 9:2e/00, 10:31/04, 12:02/ff, 13:08/1d, 14:20/f8, 15:00/0f, 16:02/00
> >   .
> >   .
> >   .
> >   , 493:00/1d, 494:00/f8, 495:00/0f
> >   Not automatically fixing this.
> > NO NAME    
> > 
> > This hard drive used to have windoze installed and could be booted.  The
> > windoze partition was reformated to be an ext2 partition.
> > 
> > Could it be that there is still a windoze mbr before the /dev/hda1
> > partition and fsdoslabel sees this but e2fsck does not?
> > 
> > If so, what can I do about it?
> 
> The first thing I would do is to check for signatures of other
> filesystems that were left behind on /dev/hda1:
> 
>   wipefs /dev/hda1
> 
> This command has to be run as root or as a user who is member of the
> "disk" group. Without options it will just list all the filesystem
> signatures that it can find; as its name indicates, it can then be used
> to remove the spurious signatures. (As always, see the manpage and be
> careful what you type; wipefs is part of util-linux.)
> 
> I recently had the automatic conversion to UUIDs fail on a system
> because the root partition had residual signatures of dos filesystems,
> which causes blkid to fail for that partition, meaning it cannot be
> found by UUID or LABEL during boot.
> 
> In your case I would guess that a residual dos signature causes the
> postinst to run dosfslabel, which fails because there is now an ext3 on
> the partition.
> 
> -- 
> Regards,            |
>           Florian   |
> 
No luck.  wipefs removed two bits but the output of dosfstab was
unchanged.  I tried aptitude -f install and the installation of
linux-base still failed as shown below:


Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Reading task descriptions...
The following partially installed packages will be configured:
  linux-base linux-image-2.6-amd64 linux-image-2.6.32-5-amd64 
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 50 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Setting up linux-base (2.6.32-15) ...
Logical sector size (15624 bytes) is not a multiple of the physical sector size.
dosfslabel failed: 256 at /var/lib/dpkg/info/linux-base.postinst line 1059, <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-amd64:
 linux-image-2.6.32-5-amd64 depends on linux-base (>= 2.6.32-15); however:
  Package linux-base is not configured yet.
dpkg: error processing linux-image-2.6.32-5-amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-image-2.6-amd64:
 linux-image-2.6-amd64 depends on linux-image-2.6.32-5-amd64; however:
  Package linux-image-2.6.32-5-amd64 is not configured yet.
dpkg: error processing linux-image-2.6-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-base
 linux-image-2.6.32-5-amd64
 linux-image-2.6-amd64
Setting up linux-base (2.6.32-15) ...
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Reading task descriptions...


I assume the problem is with /dev/hda1 as the output of dosfslabel run
on any other partition is: Logical sector size is zero.

Tom


Reply to: