From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20080208 CentOS/1.5.0.12-0.10.el4.centos Firefox/1.5.0.12 pango-text Description of problem: fsck cannot find disks. I added, fdisk'd, formatted and label'd four new disks, added mount points and edited /etc/fstab. I mounted them OK. Upon reboot I got this error on each disk: fsck.ext3: Unable to resolve 'LABEL= (etc) for each disk. I found a work-around be setting the "fsck order" to 0 (zero) in /etc/fstab I had also tried the /dev/sda1 ..etc. method to no avail. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.install and label disks 2.edit /etc/fstab 3.reboot Actual Results: fsck.ext3: Unable to resolve 'LABEL= Expected Results: disks should mount without error. If I comment out the disks in /etc/fstab, boot normally, un-comment-out the disks and do a "mount -a" everything works fine. The problem lies with fsck during boot. Additional info: search google for: fsck.ext3: Unable to resolve 'LABEL= and you'll get many hits so it may be an up-stream problem.
Would you mind attaching or pasting in your fstab, just so there's no ambiguity about your setup? (if mount points or device names are sensitive, /dev/XXX & /mnt/XXXX is fine of course) I did a very quick test with FSTAB_FILE=/tmp/fstab which looked like: [root@host tmp]# cat fstab LABEL=FSFILE1 /mnt/fsfile1 ext3 defaults 1 1 LABEL=FSFILE2 /mnt/fsfile2 ext3 defaults 1 2 where FSFILE1 and FSFILE2 were on loopback devices, labeled as shown, and: [root@host tmp]# fsck -V -T -A -a Checking all file systems. [/sbin/fsck.ext3 (1) -- /mnt/fsfile1] fsck.ext3 -a /dev/loop1 FSFILE1: clean, 11/8192 files, 5548/32768 blocks [/sbin/fsck.ext3 (1) -- /mnt/fsfile2] fsck.ext3 -a /dev/loop2 FSFILE2: clean, 11/8192 files, 5548/32768 blocks worked... I'll try setting the host up so it actually looks for more labels at boot to try to more closely recreate your setup.
Could you please provide your fstab details? Thanks, -Eric
LABEL=/ / ext3 defaults 1 1 LABEL=/usr /usr ext3 defaults 1 2 LABEL=/tmp /tmp ext3 defaults 1 2 LABEL=/var /var ext3 defaults 1 2 LABEL=/home /home ext3 defaults 1 2 LABEL=/boot /boot ext3 defaults 1 2 LABEL=/VMware /VMware ext3 defaults 1 2 LABEL=/downloads /downloads ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 LABEL=SWAP-sdbs swap swap defaults 0 0 The two partitions /VMware and /downloads were created after system generation, duely formated and labeled. However, they were not found at boot time and the boot process did tI can confirm this bug after the description. I am on Fedora 8, kernel 2.6.23.1-42.fc8. My fstab looks like: LABerminated. This did not happen with Fedora 7. If I change the two line to specify UUID= as only change then the partitions are found, but partitions surface on the desktop as were they mounted by hand which also did not happen with Fedora 7.
That last comment seems a bit garbled, can you re-post? "My fstab looks like: LABerminated." etc.
Strange, this is what I thought I sent (and I've also added a few words): I can confirm this bug after the description. I am on Fedora 8, kernel 2.6.23.1-42.fc8. My fstab looks like: LABEL=/ / ext3 defaults 1 1 LABEL=/usr /usr ext3 defaults 1 2 LABEL=/tmp /tmp ext3 defaults 1 2 LABEL=/var /var ext3 defaults 1 2 LABEL=/home /home ext3 defaults 1 2 LABEL=/boot /boot ext3 defaults 1 2 LABEL=/VMware /VMware ext3 defaults 1 2 LABEL=/downloads /downloads ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 LABEL=SWAP-sdbs swap swap defaults 0 0 The two partitions /VMware and /downloads were created after system generation, duely formated and labeled. However, they were not found at boot time and the boot process terminated as described by Larry. This did not happen with Fedora 7. If I change the two line to specify UUID= as only change then the partitions are found, but the two partitions surface on the desktop as were they mounted by hand which also did not happen with Fedora 7.
are /VMware and /downloads on different storage (different controller, perhaps) than the other items? After the system is booted, does blkid find the labels? [root@host ~]# blkid -t LABEL="/boot" /dev/sda1: LABEL="/boot" UUID="f377b339-xxxx-xxxx-xxxx-b0284dd3af8b" TYPE="ext3" SEC_TYPE="ext2"
They are indeed on a different disk which is slave to the other disk where the other partitions are located. [root@epohost ~]# blkid -t LABEL=/VMware [root@epohost ~]# blkid -t LABEL=/boot /dev/sda1: LABEL="/boot" UUID="6a2df546-7223-4efb-b3d5-c2410bf67b17" SEC_TYPE="ext2" TYPE="ext3"
Interesting... does e2label /dev/<device> on the device you expect to be labeled as "/VMware" give you the right thing? Just to be sure the label is there. And/or, does blkid /dev/<device> behave as expected?
oh, and what is the device that holds the /VMware label? (as shown in /proc/partitions?)
Something seems strange here. I'll check the whole matter once again and maybe I'll have to change some of my comments. It may take a couple of days because I won't be home for the week-end.
Created attachment 320062 [details] /var/log/messages Eric, I get something which looks pretty similar when upgrading to kernel-2.6.27-1.fc10.i686 (the one with the ext4dev/ext4 confusion, but I don't it should be related) and e2fsprogs-1.41.2-2.fc10.i386, fsck -A crashed with the same error message and whole startup broke in that moment. The only solution for me was to edit /etc/fstab and replace LABEL=boot with /dev/sda1. Then everything works pretty well. However, a strange thing is that other partition (actually LVM logical volume) with LABEL= is perfectly recognized. Neither blkid nor blkid /dev/sda1 knows anything about this partition and neither of these commands shows anything about it. tune2fs -l and e2label are happy and show the label without any problems. This is my /etc/fstab (the only difference against the state when the boot broke is the result of sed -e 's/LABEL=boot/\/dev\/sda1/'): # # /etc/fstab # Created by anaconda on Thu Oct 2 11:33:49 2008 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info # LABEL=root / ext4 defaults 1 1 /dev/sda1 /boot ext3 defaults 1 2 /dev/mapper/home /home ext3 defaults 1 1 tmpfs /tmp tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/vg00/lvSwap swap swap defaults 0 0
Created attachment 320063 [details] /var/log/dmesg
Created attachment 320064 [details] output of tune2fs -l /dev/sda1
Matej, does "blkid /dev/sda1" show the right thing? How about just "blkid" by itself, is sda1 in the list? Thanks, -Eric
quoting comment 11: > Neither blkid nor blkid /dev/sda1 knows anything about this partition and > neither of these commands shows anything about it.
Ok, Matej's problem seems to be that he had the test_fs flag set on an ext3 fs and blkid is not coping. I'll fix that, but it's unlikely that it's the original reporter's problem.
(In reply to comment #10) > Something seems strange here. I'll check the whole matter once again and maybe > I'll have to change some of my comments. It may take a couple of days because I > won't be home for the week-end. Did you decide whether anything was "strange?" I don't want to keep this open if there was just some problem on your end. Thanks, -Eric
I had the same problem in RHEL 5.3 when updating from 2.6.18-128.el5 to 2.6.18-128.1.x.el5 when having a CIFS-mountpoint (in fact a samba-share) in my /etc/fstab. Purging this mountpoint out of the /etc/fstab did the trick for me. The mountpoint when in the /etc/fstab also surfaced out of nowhere onto my user-desktop and now naturally is gone.
Needinfo was never answered; if you can provide more info please open.