dosfslabel finds problem, e2fsck does not
in [Debian]
|
Prev: Grub, MBR's on several hard drives?
Next: STORAGE USB
From: Florian Kulzer on 20 Jul 2010 13:50 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 | -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100720172331.GA3956(a)isar.localhost
From: Florian Kulzer on 20 Jul 2010 17:10 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: (offset:original/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(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100720204346.GA10489(a)isar.localhost
From: Florian Kulzer on 21 Jul 2010 02:50 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: (offset:original/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(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100721062859.GA4305(a)isar.localhost
From: Florian Kulzer on 21 Jul 2010 15:40 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) [...] > 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(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100721191359.GA4618(a)isar.localhost
From: Florian Kulzer on 21 Jul 2010 18:10
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 | -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100721214239.GA5177(a)isar.localhost |