Bug 600225
Summary: | Unknown type for any partition | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Marian Ganisin <mganisin> | ||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Release Test Team <release-test-team-automation> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 6.0 | CC: | atodorov, benl, borgan, harald, hdegoede, jbastian, john.cooper, jstodola, pknirsch, syeghiay, zamsden | ||||||
Target Milestone: | beta | ||||||||
Target Release: | --- | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | anaconda-13.21.50-4.el6 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2010-07-02 18:50:29 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 582286, 593637, 601041 | ||||||||
Attachments: |
|
Description
Marian Ganisin
2010-06-04 07:56:41 UTC
No ID_FS_TYPE attribute is being exposed by udev (which you can verify in the storage.log), so anaconda can't detect the filesystem type present. Hi, As we cannot reproduce this on other systems I think blkid might be getting confused by something specific on the disks in the system in question. Can you start the RHEL-6 installer, and then when at the graphical welcome screen switch to tty2 (ctrl + alt + f2), and run: blkid -o udev -p /dev/sda blkid -o udev -p /dev/sda1 blkid -o udev -p /dev/sda2 blkid -o udev -p /dev/sda3 blkid -o udev -p /dev/sda4 <etc for other disks / partitions> There, and paste the output in a comment here ? Thanks, Hans (In reply to comment #5) > As we cannot reproduce this on other systems Quite surprising, it happens on any architecture. > Can you start the RHEL-6 installer, and then when at the graphical welcome > screen switch to tty2 (ctrl + alt + f2), and run: $ blkid -o udev -p /dev/vda ID_PART_TABLE_TYPE=dos $ blkid -o udev -p /dev/vda1 ID_FS_UUID=1cdfa791-08f1-4438-a19a-000836380d6e ID_FS_UUID_ENC=1cdfa791-08f1-4438-a19a-000836380d6e ID_FS_VERSION=1.0 ID_FS_TYPE=ext4 ID_FS_USAGE=filesystem $ blkid -o udev -p /dev/vda2 ID_FS_UUID=a614e046-4350-42bc-b0dd-d13eefdd9474 ID_FS_UUID_ENC=a614e046-4350-42bc-b0dd-d13eefdd9474 ID_FS_VERSION=1.0 ID_FS_TYPE=ext4 ID_FS_USAGE=filesystem $ blkid -o udev -p /dev/vda3 ID_FS_UUID=STz1xg-3sSi-k0HK-iI01-NHzz-NzJK-twLchE ID_FS_UUID_ENC=STz1xg-3sSi-k0HK-iI01-NHzz-NzJK-twLchE ID_FS_VERSION=LVM2\x20001 ID_FS_TYPE=LVM2_member ID_FS_USAGE=raid I've looked a bit more in detail whats going on here and i think i've found the cause: With bug #591970 and bug #599197 we cleaned up with 70-anaconda and 64-md-raid rules quite a bit, mainly dropping unnecessary duplicate code in 70-anaconda. Now what happens though is that blkid is only being run from the proper location in 64-md-raid.rules when MD devices are detected. The only other places where blkid is called are 13-dm-disks.rules (which is part of device-mapper) and 60-persistent-storage.rules. Only 13-dm-disks.rules call blkid from the right spot in the anaconda enviroment, 60-persistent-storage.rules still uses hardcoded /sbin/blkid. Now if neither md nor dm devices are present obviously neither the 13-dm-disks.rules nor the 64-md-raid.rules are being executed. This leads to blkid never being called and ergo no ID_FS_TYPE or any other IF_FS_FOO variable being present and/or available for identification which in turn then leads to anaconda not knowing about them at all. For anaconda during the cleanup the blkid call was removed as well as it appeared to be a duplication, but this probably needs to go back in. I've attached a patch to the 70-anaconda.rules file for anaconda which should deal with this properly. I'm not sure though if we shouldn't fix this properly by adding a blkid call into the 60-persistent-storage.rules file of udev right at the start after detection that we're dealing with block devices in order to have this working outside of an anaconda install environment as well. Especially if applications in the future rely on that information to be present on a live system, too. Thanks & regards, Phil Created attachment 421803 [details]
Re-add blkid call to 70-anaconda.rules file
Need to add the blkid call again to the 70-anaconda.rules file again as blkid isn't properly called for all block devices without it.
Probably needs to go to 60-persistent-storage.rules, but need to verify.
Thanks & regards, Phil
PS: And yes, doing a fresh install with the latest tree and then at the partitioning going into Manual partitioning i was able to reproduce the problem now. (In reply to comment #7) > Now if neither md nor dm devices are present obviously neither the > 13-dm-disks.rules nor the 64-md-raid.rules are being executed. There's no doubt your evaluation is absolutely correct. I just wanted to highlight, also lvm pvs are marked as unknown by anaconda. I suppose these are valid dm devices. However anaconda is able to remove them (physical volumes of lvm) and reuse the space. That's it, I suppose this could be valuable information (at least for anaconda guys). *** Bug 600267 has been marked as a duplicate of this bug. *** *** Bug 601219 has been marked as a duplicate of this bug. *** Phil - yeah, that looks like it. Thanks a lot for the debugging. Another side effect (probably because) of this is that grub.conf and /etc/fstab now specify raw partitions by device name instead of UUID which is working properly with the 0531.1 snapshot. *** Bug 600145 has been marked as a duplicate of this bug. *** *** Bug 602369 has been marked as a duplicate of this bug. *** (In reply to comment #8) > Created an attachment (id=421803) [details] > Re-add blkid call to 70-anaconda.rules file > > Need to add the blkid call again to the 70-anaconda.rules file again as blkid > isn't properly called for all block devices without it. > > Probably needs to go to 60-persistent-storage.rules, but need to verify. > > Thanks & regards, Phil Please don't do this. Isn't the correct fix to put blkid to /sbin or provide a symlink in the anaconda image? *** Bug 602497 has been marked as a duplicate of this bug. *** Test results: 1) DVD installation tested and works on Server, WebServer, Workstation x86_64 variants with 0615.0 tree. Those bugs were marked as duplicate of this one. 2) Encrypted partitions work (see comment #12) 3) Bug from comment #11 - 4) Comment #14 - devices not mounted by UUID - /etc/fstab and boot command line now specifies the root partition by UUID, not device name. 5) While doing manual partitioning after a previous install all the partitions I had were correctly identified with their file systems. None was identified as "Unknown". (In reply to comment #20) > 3) Bug from comment #11 - > This is also fixed. anaconda-ks.cfg now contains pv.XXXX not pv.None In stage 2 we now have /sbin/blkid and /usr/sbin/blkid This and comment #20 are with 0615.0 tree. Moving to VERIFIED. *** Bug 604490 has been marked as a duplicate of this bug. *** Red Hat Enterprise Linux Beta 2 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |