Bug 600225 - Unknown type for any partition
Unknown type for any partition
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.0
All Linux
high Severity high
: beta
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
: 600145 600267 601219 602369 602497 604490 (view as bug list)
Depends On:
Blocks: 582286 593637 601041
  Show dependency treegraph
 
Reported: 2010-06-04 03:56 EDT by Marian Ganisin
Modified: 2010-07-02 14:50 EDT (History)
11 users (show)

See Also:
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 14:50:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log files (190.00 KB, application/x-tar)
2010-06-04 03:56 EDT, Marian Ganisin
no flags Details
Re-add blkid call to 70-anaconda.rules file (592 bytes, text/plain)
2010-06-07 08:20 EDT, Phil Knirsch
no flags Details

  None (edit)
Description Marian Ganisin 2010-06-04 03:56:41 EDT
Created attachment 421153 [details]
log files

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):
13.21.50

How reproducible:
Always

Maybe related to Bug 591970
Comment 1 Chris Lumens 2010-06-04 09:51:48 EDT
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.
Comment 5 Hans de Goede 2010-06-07 04:34:42 EDT
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
Comment 6 Marian Ganisin 2010-06-07 06:17:58 EDT
(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
Comment 7 Phil Knirsch 2010-06-07 08:18:22 EDT
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
Comment 8 Phil Knirsch 2010-06-07 08:20:09 EDT
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
Comment 9 Phil Knirsch 2010-06-07 08:47:11 EDT
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.
Comment 10 Marian Ganisin 2010-06-07 09:24:47 EDT
(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).
Comment 11 Chris Lumens 2010-06-07 11:22:50 EDT
*** Bug 600267 has been marked as a duplicate of this bug. ***
Comment 12 Chris Lumens 2010-06-07 11:23:29 EDT
*** Bug 601219 has been marked as a duplicate of this bug. ***
Comment 13 Chris Lumens 2010-06-07 11:25:20 EDT
Phil - yeah, that looks like it.  Thanks a lot for the debugging.
Comment 14 Alexander Todorov 2010-06-07 11:44:37 EDT
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.
Comment 15 Chris Lumens 2010-06-08 14:21:02 EDT
*** Bug 600145 has been marked as a duplicate of this bug. ***
Comment 16 David Lehman 2010-06-09 17:20:22 EDT
*** Bug 602369 has been marked as a duplicate of this bug. ***
Comment 17 Harald Hoyer 2010-06-10 07:33:04 EDT
(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?
Comment 18 Chris Lumens 2010-06-11 08:43:01 EDT
*** Bug 602497 has been marked as a duplicate of this bug. ***
Comment 20 Alexander Todorov 2010-06-16 12:45:05 EDT
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".
Comment 21 Alexander Todorov 2010-06-16 12:50:42 EDT
(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.
Comment 22 Chris Lumens 2010-06-17 08:59:10 EDT
*** Bug 604490 has been marked as a duplicate of this bug. ***
Comment 23 releng-rhel@redhat.com 2010-07-02 14:50:29 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.