I have a system updated from F9 -> F10 -> F11 that no longer can get access to the /boot partition (the F11 update was the trigger for this). After the update, on the reboot, grub saw the /boot partition just fine and booted the kernel successfully, then when the kernel went to check and mount the filesystem, it couldn't find it. I commented out the filesystem in /etc/fstab and things came up OK, but of course I will have difficulty applying any new kernel images in the future.. The system has two mirrored 320GB SATA drives. They are partitioned identically, with a ~200MB partition 1 for /boot and the rest of the disk allocated for LVM: Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000007b4 Device Boot Start End Blocks Id System /dev/sda1 * 1 25 200781 83 Linux /dev/sda2 26 38913 312367860 8e Linux LVM fdisk is happy with the partition table on both disks. During boot, the kernel seems to recognize both partitions: scsi 0:0:0:0: Direct-Access ATA WDC WD3200YS-01P 21.0 PQ: 0 ANSI: 5 sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 0:0:0:0: [sda] 625142448 512-byte hardware sectors: (320 GB/298 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata2.00: ATA-7: WDC WD3200YS-01PGB0, 21.00M21, max UDMA/133 ata2.00: 625142448 sectors, multi 0: LBA48 NCQ (depth 1) ata2.00: configured for UDMA/133 scsi 1:0:0:0: Direct-Access ATA WDC WD3200YS-01P 21.0 PQ: 0 ANSI: 5 sd 1:0:0:0: [sdb] 625142448 512-byte hardware sectors: (320 GB/298 GiB) sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdb: sdb1 sdb2 By the time user space gets started, however, the kernel and/or udev have created only /dev/sda, /dev/sdb, and /dev/sdb2. If I manually create a /dev/sda1 or /dev/sdb1, they cannot access the partitions on the disk and return an immediate error ENODEV. I have other systems running just fine that have followed the same update path (or even longer), but this is the only system I have that has mirrored disks or LVM. Has there been any change that might have caused this? I am a little suspicous that something is aware of the disk mirroring, since there is a sdb2 device file but no sda2 file. The LVM table is based on /dev/sdb2, not on /dev/sdb itself. Is this the normal way, or is there some way that this could be causing the trouble? Any suggestions of what to look at, or ideas what might be the culprit here? Thanks in advance! Marcus Hall marcus@xxxxxxxxxx -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
