FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-20-2010, 03:25 PM
"Thomas H. George"
 
Default dosfslabel finds problem, e2fsck does not

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: (offsetriginal/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?

Tom


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100720152542.GA5246@tomgeorge.info">http://lists.debian.org/20100720152542.GA5246@tomgeorge.info
 
Old 07-20-2010, 05:23 PM
Florian Kulzer
 
Default dosfslabel finds problem, e2fsck does not

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: (offsetriginal/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 |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100720172331.GA3956@isar.localhost">http://lists.debian.org/20100720172331.GA3956@isar.localhost
 
Old 07-20-2010, 07:58 PM
"Thomas H. George"
 
Default 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: (offsetriginal/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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100720195859.GA6386@tomgeorge.info">http://lists.debian.org/20100720195859.GA6386@tomgeorge.info
 
Old 07-20-2010, 08:43 PM
Florian Kulzer
 
Default dosfslabel finds problem, e2fsck does not

On Tue, Jul 20, 2010 at 15:58:59 -0400, Thomas H. George wrote:
> 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: (offsetriginal/backup)

[...]

> > > 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.

[...]

> > The first thing I would do is to check for signatures of other
> > filesystems that were left behind on /dev/hda1:
> >
> > wipefs /dev/hda1

[...]

> No luck. wipefs removed two bits

That is better in any case; such stale additional signatures cause
problems for blkid.

> but the output of dosfstab was
> unchanged. I tried aptitude -f install and the installation of
> linux-base still failed as shown below:

[...]

> 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

[...]

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

OK, the normal way to fix the "differences between boot sector and its
backup" problem on a vfat filesystem is:

fsck.vfat -ar /dev/hda1

(The filesystem should be unmounted for this procedure.)

However, I have never had to use it on an ext3 partition and I have no
idea if is safe, therefore I am hesitant to recommend it to you.
(Fsck.vfat will overwrite the backup of the boot sector with its current
content, making the two identical again.)

I would like to see your output of

wipefs /dev/hda1

(to verify that the ext3 signature has the normal offset) and also the
output of

fdisk -l /dev/hda

to check if the partition type is correct.

--
Regards, |
Florian |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100720204346.GA10489@isar.localhost">http://lists.debian.org/20100720204346.GA10489@isar.localhost
 
Old 07-21-2010, 12:09 AM
"Thomas H. George"
 
Default dosfslabel finds problem, e2fsck does not

On Tue, Jul 20, 2010 at 10:43:46PM +0200, Florian Kulzer wrote:
> On Tue, Jul 20, 2010 at 15:58:59 -0400, Thomas H. George wrote:
> > 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: (offsetriginal/backup)
>
> [...]
>
> > > > 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.
>
> [...]
>
> > > The first thing I would do is to check for signatures of other
> > > filesystems that were left behind on /dev/hda1:
> > >
> > > wipefs /dev/hda1
>
> [...]
>
> > No luck. wipefs removed two bits
>
> That is better in any case; such stale additional signatures cause
> problems for blkid.
>
> > but the output of dosfstab was
> > unchanged. I tried aptitude -f install and the installation of
> > linux-base still failed as shown below:
>
> [...]
>
> > 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
>
> [...]
>
> > I assume the problem is with /dev/hda1 as the output of dosfslabel run
> > on any other partition is: Logical sector size is zero.
>
> OK, the normal way to fix the "differences between boot sector and its
> backup" problem on a vfat filesystem is:
>
> fsck.vfat -ar /dev/hda1
>
> (The filesystem should be unmounted for this procedure.)
>
> However, I have never had to use it on an ext3 partition and I have no
> idea if is safe, therefore I am hesitant to recommend it to you.
> (Fsck.vfat will overwrite the backup of the boot sector with its current
> content, making the two identical again.)
>
> I would like to see your output of
>
> wipefs /dev/hda1

No output. There was output before I ran wipe /dev/hda1 the first time.
It said it was removing two bits.

>
> (to verify that the ext3 signature has the normal offset) and also the
> output of
>
> fdisk -l /dev/hda


GNU Fdisk 1.2.4
Copyright (C) 1998 - 2006 Free Software Foundation, Inc.
This program is free software, covered by the GNU General Public License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.


Disk /dev/hda: 30 GB, 30754321920 bytes
255 heads, 63 sectors/track, 3739 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 243 1951866 83 Linux
/dev/hda2 244 3739 28073587 5 Extended
/dev/hda5 244 3739 28073587 83 Linux



Warning: Partition 5 does not end on cylinder boundary.
>
> to check if the partition type is correct.
>
> --
> Regards, |
> Florian |
>
>
Note: e2fsck /dev/hda5 still says

/dev/hda5: 467/3415689 files, 33740347/7023967 blocks

Tom
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20100720204346.GA10489@isar.localhost
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100721000927.GA6848@tomgeorge.info">http://lists.debian.org/20100721000927.GA6848@tomgeorge.info
 
Old 07-21-2010, 06:28 AM
Florian Kulzer
 
Default dosfslabel finds problem, e2fsck does not

On Tue, Jul 20, 2010 at 20:09:27 -0400, Thomas H. George wrote:
> On Tue, Jul 20, 2010 at 10:43:46PM +0200, Florian Kulzer wrote:
> > On Tue, Jul 20, 2010 at 15:58:59 -0400, Thomas H. George wrote:
> > > 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: (offsetriginal/backup)
> >
> > [...]
> >
> > > > > 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.
> >
> > [...]
> >
> > > > The first thing I would do is to check for signatures of other
> > > > filesystems that were left behind on /dev/hda1:
> > > >
> > > > wipefs /dev/hda1
> >
> > [...]
> >
> > > No luck. wipefs removed two bits
> >
> > That is better in any case; such stale additional signatures cause
> > problems for blkid.

Note: I misunderstood you here, assuming that you had actively removed
the signatures yourself after checking that it made sense to do so.

[...]

> > I would like to see your output of
> >
> > wipefs /dev/hda1
>
> No output.

That is not good; it should show at least the signature of the ext3
filesystem.

# wipefs /dev/hda1
offset type
----------------------------------------------------------------
0x438 ext3 [filesystem]
LABEL: root
UUID: 51e39ea1-999d-4567-8e50-11ad53029e9c

> There was output

I need to know exactly what this output was.

> before I ran wipe /dev/hda1 the first time.
> It said it was removing two bits.

It should have done anything when run without options, unless you have a
different version of until-linux than the current one for Squeeze. There
was a reason for my explicitly asking you to read the manpage to make
sure you understand what you are doing. I thought you understood the
inherent risk of operations on the filesystem structure and that you
would make an informed decision if that risk is worthwhile. I cannot
make any more suggestions to you if you unquestioningly use the tools
that I propose without regarding the caveats that I point out.

Does "blkid /dev/hda1" still return the correct label, UUID and type?

> > (to verify that the ext3 signature has the normal offset) and also the
> > output of
> >
> > fdisk -l /dev/hda

[...]

> Disk /dev/hda: 30 GB, 30754321920 bytes
> 255 heads, 63 sectors/track, 3739 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
> Device Boot Start End Blocks Id System
> /dev/hda1 1 243 1951866 83 Linux
> /dev/hda2 244 3739 28073587 5 Extended
> /dev/hda5 244 3739 28073587 83 Linux

That looks OK to me.

--
Regards, |
Florian |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100721062859.GA4305@isar.localhost">http://lists.debian.org/20100721062859.GA4305@isar.localhost
 
Old 07-21-2010, 02:25 PM
"Thomas H. George"
 
Default dosfslabel finds problem, e2fsck does not

On Wed, Jul 21, 2010 at 08:28:59AM +0200, Florian Kulzer wrote:
> On Tue, Jul 20, 2010 at 20:09:27 -0400, Thomas H. George wrote:
> > On Tue, Jul 20, 2010 at 10:43:46PM +0200, Florian Kulzer wrote:
> > > On Tue, Jul 20, 2010 at 15:58:59 -0400, Thomas H. George wrote:
> > > > 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: (offsetriginal/backup)
> > >
> > > [...]
> > >
> > > > > > 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.
> > >
> > > [...]
> > >
> > > > > The first thing I would do is to check for signatures of other
> > > > > filesystems that were left behind on /dev/hda1:
> > > > >
> > > > > wipefs /dev/hda1
> > >
> > > [...]
> > >
> > > > No luck. wipefs removed two bits
> > >
> > > That is better in any case; such stale additional signatures cause
> > > problems for blkid.
>
> Note: I misunderstood you here, assuming that you had actively removed
> the signatures yourself after checking that it made sense to do so.
>
> [...]
>
> > > I would like to see your output of
> > >
> > > wipefs /dev/hda1
> >
> > No output.
>
> That is not good; it should show at least the signature of the ext3
> filesystem.
>
> # wipefs /dev/hda1
> offset type
> ----------------------------------------------------------------
> 0x438 ext3 [filesystem]
> LABEL: root
> UUID: 51e39ea1-999d-4567-8e50-11ad53029e9c
>
> > There was output
>
> I need to know exactly what this output was.
>
> > before I ran wipe /dev/hda1 the first time.
> > It said it was removing two bits.
>
> It should have done anything when run without options, unless you have a
> different version of until-linux than the current one for Squeeze. There
> was a reason for my explicitly asking you to read the manpage to make
> sure you understand what you are doing. I thought you understood the
> inherent risk of operations on the filesystem structure and that you
> would make an informed decision if that risk is worthwhile. I cannot
> make any more suggestions to you if you unquestioningly use the tools
> that I propose without regarding the caveats that I point out.

I did read the man page first. It said wipefs -n /dev/hda1 would do
everything except the write call. I ran it that way and the output was
much like the example you gave above with a message that two bits would
be removed. I assumed the two bits were the leftover signature and ran
wipefs again without the -n option.

Since then the computer was shutdown overnight. Reboot this morning
stopped in maintenance mode reporting a bad superblock in /dev/hda1. I
ran e2fsck -b xxxx /dev/hda1 where xxxx was the given alternate
superblock. The systen then rebooted normally.

Now the output of wipefs -n /dev/hda1 is:


offset type
----------------------------------------------------------------
0x438 ext2 [filesystem]
UUID: 2428f3c0-3098-448c-9484-587eb9f86e37

>
> Does "blkid /dev/hda1" still return the correct label, UUID and type?
Yes

/dev/hda1: UUID="2428f3c0-3098-448c-9484-587eb9f86e37" TYPE="ext2"

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.

Tom
>
> > > (to verify that the ext3 signature has the normal offset) and also the
> > > output of
> > >
> > > fdisk -l /dev/hda
>
> [...]
>
> > Disk /dev/hda: 30 GB, 30754321920 bytes
> > 255 heads, 63 sectors/track, 3739 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> >
> > Device Boot Start End Blocks Id System
> > /dev/hda1 1 243 1951866 83 Linux
> > /dev/hda2 244 3739 28073587 5 Extended
> > /dev/hda5 244 3739 28073587 83 Linux
>
> That looks OK to me.
>
> --
> Regards, |
> Florian |
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20100721062859.GA4305@isar.localhost
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100721142530.GA4772@tomgeorge.info">http://lists.debian.org/20100721142530.GA4772@tomgeorge.info
 
Old 07-21-2010, 07:13 PM
Florian Kulzer
 
Default dosfslabel finds problem, e2fsck does not

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: (offsetriginal/backup)

[...]

> I did read the man page first. It said wipefs -n /dev/hda1 would do
> everything except the write call. I ran it that way and the output was
> much like the example you gave above with a message that two bits would
> be removed. I assumed the two bits were the leftover signature and ran
> wipefs again without the -n option.
>
> Since then the computer was shutdown overnight. Reboot this morning
> stopped in maintenance mode reporting a bad superblock in /dev/hda1. I
> ran e2fsck -b xxxx /dev/hda1 where xxxx was the given alternate
> superblock. The systen then rebooted normally.
>
> Now the output of wipefs -n /dev/hda1 is:
>
>
> offset type
> ----------------------------------------------------------------
> 0x438 ext2 [filesystem]
> UUID: 2428f3c0-3098-448c-9484-587eb9f86e37
>
> >
> > Does "blkid /dev/hda1" still return the correct label, UUID and type?
> Yes
>
> /dev/hda1: UUID="2428f3c0-3098-448c-9484-587eb9f86e37" TYPE="ext2"

OK, that is all fine. You did not give the details about how you used
wipefs in your previous message, so I was getting worried that I might
have inadvertently caused you to wipe out the ext3 signature.

> 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

--
Regards, |
Florian |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100721191359.GA4618@isar.localhost">http://lists.debian.org/20100721191359.GA4618@isar.localhost
 
Old 07-21-2010, 07:53 PM
"Thomas H. George"
 
Default dosfslabel finds problem, e2fsck does not

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: (offsetriginal/backup)
>
> [...]
>
> > I did read the man page first. It said wipefs -n /dev/hda1 would do
> > everything except the write call. I ran it that way and the output was
> > much like the example you gave above with a message that two bits would
> > be removed. I assumed the two bits were the leftover signature and ran
> > wipefs again without the -n option.
> >
> > Since then the computer was shutdown overnight. Reboot this morning
> > stopped in maintenance mode reporting a bad superblock in /dev/hda1. I
> > ran e2fsck -b xxxx /dev/hda1 where xxxx was the given alternate
> > superblock. The systen then rebooted normally.
> >
> > Now the output of wipefs -n /dev/hda1 is:
> >
> >
> > offset type
> > ----------------------------------------------------------------
> > 0x438 ext2 [filesystem]
> > UUID: 2428f3c0-3098-448c-9484-587eb9f86e37
> >
> > >
> > > Does "blkid /dev/hda1" still return the correct label, UUID and type?
> > Yes
> >
> > /dev/hda1: UUID="2428f3c0-3098-448c-9484-587eb9f86e37" TYPE="ext2"
>
> OK, that is all fine. You did not give the details about how you used
> wipefs in your previous message, so I was getting worried that I might
> have inadvertently caused you to wipe out the ext3 signature.
>
> > 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

I have copied everything on /dev/hda1 and /dev/hda5 on to a backup drive
and am considering a complete reformat of /dev/hda.

Tom
> --
> Regards, |
> Florian |
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20100721191359.GA4618@isar.localhost
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100721195336.GA7153@tomgeorge.info">http://lists.debian.org/20100721195336.GA7153@tomgeorge.info
 
Old 07-21-2010, 09:42 PM
Florian Kulzer
 
Default 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: (offsetriginal/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 |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100721214239.GA5177@isar.localhost">http://lists.debian.org/20100721214239.GA5177@isar.localhost
 

Thread Tools




All times are GMT. The time now is 01:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org