Bug 163050 - mount tries to get LABEL of a non-ext3 partition and halts booting
mount tries to get LABEL of a non-ext3 partition and halts booting
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-12 11:26 EDT by Raghu
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-12 12:06:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Raghu 2005-07-12 11:26:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:

I used LABELs for fstab mounts and when I moved to a new disk, mounts started complaining about 'bad superblock ... on /dev/hda2'. On the new disk /dev/hda2 is reserved for Win XP (not installed) and marked as HPFS/NTFS type in fdisk.

It is surprising mount is trying to find label for this volume. It worked fine when changed fstab to actual patitions instead of LABELs. I would expect mount to skip partitions that it doesnot get a LABEL for.

fdisk:
======

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *        2156        3615    11727450   83  Linux
/dev/hda2               6        2155    17269875    7  HPFS/NTFS
/dev/hda4            3616       24792   170104252+   5  Extended
/dev/hda5            3616        9696    48845601   83  Linux
/dev/hda6            9697       18937    74228301   83  Linux

/etc/fstab that didn't work:
============================

# This file is edited by fstab-sync - see 'man fstab-sync' for details
/dev/hda1               /                       ext3    defaults        1 1
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
#LABEL=home              /home                   ext3    defaults        1 2
#LABEL=misc             /mnt/misc               ext3    defaults        1 2

fstab that worked:
=================

# This file is edited by fstab-sync - see 'man fstab-sync' for details
/dev/hda1               /                       ext3    defaults        1 1
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
#LABEL=home              /home                   ext3    defaults        1 2
#LABEL=misc             /mnt/misc               ext3    defaults        1 2
/dev/hda5               /home                   ext3    defaults        1 2
/dev/hda6               /mnt/misc               ext3    defaults        1 2


LABELs on ext3 partitions are set properly.

$ uname -a
Linux pulpfiction 2.6.11-1.1369_FC4 #1 Thu Jun 2 22:55:56 EDT 2005 i686 athlon i386 GNU/Linux


Version-Release number of selected component (if applicable):
util-linux-2.12p-9.3

How reproducible:
Always

Steps to Reproduce:
1. Have an NTFS partions on the disk (say hda2)

2. Have a ext3 patition with a label (say "test") after the ntfs partition 
   /dev/hda3.

3. Mounting /dev/hda3 with label does not work in fstab.
  

Actual Results:  
Boot fails with mount complaining about bad superblock on /dev/hda2.

Expected Results:  
Mount should have just ignored /dev/hda2.



Additional info:
Comment 1 Raghu 2005-07-12 11:27:31 EDT
of course, there are no '#'s before LABEL in the fstab that didn't work above.
Comment 2 Karel Zak 2005-08-29 04:03:53 EDT
Please, run:
Comment 3 Karel Zak 2005-08-29 04:12:37 EDT
(sorry that I break previous comment...)

Please, run:
   rm /etc/blkid.tab
   blkid
   e2label /dev/hda2
   
By the way, mount doesn't check for partition type, but it checks filesystem on
partition only. 
Comment 4 Karel Zak 2006-03-12 12:06:04 EST
Since there are insufficient details provided in this report for
us to investigate the issue further, and we have not received the
feedback we requested, we will assume the problem was not
reproduceable or has been fixed in a later update for this product.

Users who have experienced this problem are encouraged to upgrade
to the latest update release, and if this issue is still
reproduceable, please REOPEN this big report.

Note You need to log in before you can comment on or make changes to this bug.