Bug 698158 - autoinstall to usb stick failed if the usb stick have filesystem
Summary: autoinstall to usb stick failed if the usb stick have filesystem
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Mike Burns
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-20 10:34 UTC by Guohua Ouyang
Modified: 2011-12-06 19:07 UTC (History)
7 users (show)

Fixed In Version: ovirt-node-2.0.2-0.1.git5dce5f9.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 19:07:03 UTC
Target Upstream Version:


Attachments (Terms of Use)
auto install to usb fail when usb have filesystem (22.74 KB, text/plain)
2011-04-20 10:34 UTC, Guohua Ouyang
no flags Details
Patch (1.40 KB, patch)
2011-08-03 15:13 UTC, Mike Burns
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1783 0 normal SHIPPED_LIVE rhev-hypervisor6 bug fix and enhancement update 2011-12-06 15:10:54 UTC

Description Guohua Ouyang 2011-04-20 10:34:49 UTC
Created attachment 493427 [details]
auto install to usb fail when usb have filesystem

According to comment #15 in bug 694215, file a separate bug for auto install to usb (with filesystem) failed issue to 6.1.z.

Description of problem:
auto install to an usb disk which have a filesystem(vfat, ext234) is failed and drop to shell because "Device specified in storage_init does not exist".


Version-Release number of selected component (if applicable):
rhev-hypervisor-6.1-14.1 and rhev-hypervisor-6.0-15.10.1

How reproducible:
Always.


Steps to Reproduce:
1. Make sure have a filesystem on usb stick, it doesn't matter if have
partitions or not.
2. Do auto install to the usb disk,  the kernel command line parameter: 
storage_init=usb storage_vol=:5::5:5:256 BOOTIF=eth0 local_boot firstboot
3. Monitor the screen.

Actual results:
Install failed and drop to shell.

Expected results:
Succeed to install rhev-h.

Additional info:
1. auto install on completely clean usb stick (no partitions, no filesystems):  OK
2. auto install on usb stick with RHEV-H installed (6.1-14.1):  OK

Comment 2 Mike Burns 2011-04-20 12:30:43 UTC
My understanding was that this affects only usb sticks where there are no paritions, e.g. on /dev/sdb directly, rather than on /dev/sdb1 based on the comment.

Comment 3 Guohua Ouyang 2011-04-21 03:29:00 UTC
(In reply to comment #2)
> My understanding was that this affects only usb sticks where there are no
> paritions, e.g. on /dev/sdb directly, rather than on /dev/sdb1 based on the
> comment.

yes, it was using the entire usb stick device. 
I was using mkdosfs -I /dev/sdb to create the filesystem, which makes auto install fail with storage_init=usb.

Comment 4 Alan Pevec 2011-07-22 21:55:07 UTC
Let's at least relnote this, in case it can't be fixed for 6.2.

Comment 5 Mike Burns 2011-08-01 19:26:56 UTC
I tried reproducing this with the latest autobuild without success.  Please test with next build handed off to QE.

Steps:
insert usb stick (/dev/sdh)
fdisk /dev/sdh
delete all partitions
w to write changes
mkdosfs -I /dev/sdh
go to different machine and autoinstall to that stick
Successfully installed and booted

Comment 7 Guohua Ouyang 2011-08-02 02:47:10 UTC
(In reply to comment #5)
> I tried reproducing this with the latest autobuild without success.  Please
> test with next build handed off to QE.
> 
> Steps:
> insert usb stick (/dev/sdh)
> fdisk /dev/sdh
> delete all partitions
> w to write changes
> mkdosfs -I /dev/sdh
> go to different machine and autoinstall to that stick
> Successfully installed and booted

Mike, are you using storage_init=usb or storage_init=/dev/sdb? my test is failed with storage_init=usb, but successful with storage_init=/dev/sdb.

When fail with storage_init=usb, it said "Device specified in storage_init does not exist" on screen.

I think the failure is in file /usr/libexec/ovirt-boot-functions:
[ -z "$ID_FS_USAGE" -a "$ID_BUS" = "$bus" ] return 1 because "$ID_FS_USAGE" isn't zero when the usb stick with filesystem.

1. If the usb stick have filesystem, it failed to find usb device.
#. /usr/libexec/ovirt-boot-functions
#find_disk usb
#parse_disk_id usb

2. If it have no filesystem, it's ok to find the usb device.
#. /usr/libexec/ovirt-boot-functions
#find_disk usb
/dev/sdb
#parse_disk_id usb
/dev/sdb

3. /dev/sdb always returns /dev/sdb:
#. /usr/libexec/ovirt-boot-functions
#parse_disk_id /dev/sdb
/dev/sdb

Comment 8 Mike Burns 2011-08-03 15:13:44 UTC
Created attachment 516533 [details]
Patch

Comment 9 Mike Burns 2011-08-03 15:18:47 UTC
Note:  This ONLY happens with storage_init=<bus type>, not with specifying a specific device.

Looking at the code, we were using the ID_FS_USAGE variable from udevadm info to determine if the device was valid for installation.  This variable refers to whether there is a filesystem on the device or not.  

This lead to 2 problems:

1.  A USB device with a filesystem on the root device rather than a partition would be incorrectly determined invalid
2.  A partition without a filesystem would be determined valid 

#2 might be impossible since we would check the base device first and find that the base device is valid.  I'm pretty sure we would fail later on if we did happen to get this device though.

The solution is to use DEVTYPE.  This is also found using udevadm info.  It returns "disk" for the root disk and "partition" for a partition.

Comment 11 Guohua Ouyang 2011-08-26 09:34:36 UTC
Verified on 6.2-0.14, autoinstall to usb stick which have filesystem successful. 

install params: storage_init=usb storage_vol=:50::50:50:500 BOOTIF=eth0 local_boot firstboot

Comment 12 errata-xmlrpc 2011-12-06 19:07:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1783.html


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