Created attachment 421153 [details]
Description of problem:
Anaconda doesn't detect filesystem type correctly, it reports Type unknown for all partitions.
Version-Release number of selected component (if applicable):
Maybe related to Bug 591970
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.
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 ?
(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
$ blkid -o udev -p /dev/vda1
$ blkid -o udev -p /dev/vda2
$ blkid -o udev -p /dev/vda3
I've looked a bit more in detail whats going on here and i think i've found the
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. ***
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.