Bug 163050

Summary: mount tries to get LABEL of a non-ext3 partition and halts booting
Product: [Fedora] Fedora Reporter: Raghu <raghu1111>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-12 17:06:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Raghu 2005-07-12 15:26:02 UTC
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 15:27:31 UTC
of course, there are no '#'s before LABEL in the fstab that didn't work above.


Comment 2 Karel Zak 2005-08-29 08:03:53 UTC
Please, run:


Comment 3 Karel Zak 2005-08-29 08:12:37 UTC
(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 17:06:04 UTC
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.