We have to come up with filtering of some sort, because without the check for removables, we will show the user about twenty devices on a system with no DD. Most of them are ram0..ram16 and similar. Just take a look at /sys/block and all devices there will be shown in that dialog.

Reassigning this to Martin. CAI is going to test the kickstart case, which should work here, but I would like to see a checkbox during install to say "show all devices". If the kickstart case works anyay, this /might/ be ok to wait until 6.1 because most "hard disk" installs of driver disks tend to be scripted.

We can improve the filtering for RHEL 6.0, but we cannot modify the UI elements at this point to introduce a checkbox that allows users to change the device filtering.

Martin, can you see if this one is doable for RHEL 6.0, else let's close it or move it to 6.1.

As long as kickstart works, and provided it doesn't treat e.g. BIOS provided flash devices as non-removable, then I think this is ok. Let's dig some more to confirm it's just hard disks that are treated differently for example.

I can for now create a filter just to get rid of /dev/ram* devices. But more complicated changes have to go to 6.1. What do you think?

I did as I said and the fix will be included in anaconda-13.21.55-1.

When I trying to verify this bug on the latest version 20100707.4, facing a issue: "Failed to read directory /tmp/drivers/rpms/x86_64: No such file or directory". I guess there is some problem with my test driver.

Will you please attach log files from the install? And maybe a link to the driverdisc too.

Created attachment 431091 [details]
anaconda.log

Created attachment 431092 [details]
syslog

Created attachment 431093 [details]
guest xml

Created attachment 431095 [details]
dd.iso

But your driverdisc is in wrong format, it contains /rpms/rpms/x86_64. You just have one directory level too many...

Created attachment 431352 [details]
load error snapshot

Created attachment 431353 [details]
insmod error snapshot

Created attachment 431363 [details]
anaconda.log-new

Created attachment 431364 [details]
syslog-new

Attached syslog & anaconda.log

That is strange, can you get me `ls -Ra` of /lib/modules/ and /tmp/DD/ during the installation after you load the driverdisc? And attach the /lib/modules/<kernel version>/modules.dep too please. Thanks

Created attachment 431379 [details]
output of ls -Ra /lib/modules

Created attachment 431380 [details]
output of ls -Ra /tmp/DD

Created attachment 431381 [details]
modules.dep file

Couple more file to include, can you get me depmod configuration from the installation? (/etc/depmod.conf and /etc/depmod.d).

The driver is in the proper place, but modules.dep gives higher priority to the old one which it shouldn't.

Hi Martin,

I can't find the /etc/depmod.conf during the system installation. Attached the /etc/depmod.d/ folder. Thanks.

Created attachment 431391 [details]
depmod.d

Ok. So if I use the files attached here, I have enough to reproduce on yesterday's nightly? I'm at a conference - but I have a second laptop with me for the purposes of RHEL6 stuff - I will try to find some time to get this resolved within the next couple of days. Just let me know if I have everything.

So, I need to know the following:

1). Your XML in test.xml says that you did not create a SCSI device. Can you confirm that you are not actually testing with the SCSI disk device? It appears you are using a regular virtio disk device. But you have two devices in any case and I would like to know the difference between /var/lib/libvirt/images/default/test.img and /var/lib/libvirt/images/default/insSrv-1.img? There is certainly a bug, but the testing should also be using the SCSI device too.

2). How did you run the shell during the install - looks like you didn't use a SCSI device, so proceeded beyond driver disk selection because a driver existed for the virtio device, and then you used the shell once the early anaconda bits had completed (known as the anaconda loader).

3). Is the "test.img" disk in your test.xml machine instance the driver disk?

4). How did you make the driver disk? My example one doesn't have two rpms/rpms directories. I have rebuilt my example against the -44 kernel anyway. Please supply the source you are using if it is not what I provided originally.

Anyway. I am sure there is a bug, and it looks like depmod is not parsing the dd.conf files as Martin says. I'm just wanting to confirm you didn't actually test having the virtual hardware present, but I don't think this is Martin's problem. I think this is something I can have fixed up real soon now. That said, if Martin is going on vacation, I'd like to know when, etc.

Jon.

Also, at what stage are you running busybox? And are you using a custom image to get a busybox shell during the loader stage?

*** Bug 616830 has been marked as a duplicate of this bug. ***

(In reply to comment #37)
> So, I need to know the following:
> 
> 1). Your XML in test.xml says that you did not create a SCSI device. Can you
> confirm that you are not actually testing with the SCSI disk device? It appears
> you are using a regular virtio disk device. But you have two devices in any
> case and I would like to know the difference between
> /var/lib/libvirt/images/default/test.img and
> /var/lib/libvirt/images/default/insSrv-1.img? There is certainly a bug, but the
> testing should also be using the SCSI device too.
> 
Yes, I don't have any SCSI disk device in my env. The difference between /var/lib/libvirt/images/default/test.img is the test VM hard disk with type of virtio, and /var/lib/libvirt/images/default/insSrv-1.img is a disk to store the dd.iso file with type of ide. Yes, I agree the testing should be using the SCSI device. I will be careful on this.
> 2). How did you run the shell during the install - looks like you didn't use a
> SCSI device, so proceeded beyond driver disk selection because a driver existed
> for the virtio device, and then you used the shell once the early anaconda bits
> had completed (known as the anaconda loader).
> 
> 3). Is the "test.img" disk in your test.xml machine instance the driver disk?
> 
No, it's the test VM's hd.
> 4). How did you make the driver disk? My example one doesn't have two rpms/rpms
> directories. I have rebuilt my example against the -44 kernel anyway. Please
> supply the source you are using if it is not what I provided originally.
> 
Yes I'm using your driver disk. About the rpms/rpms problem, if there already has a rpms dir, the make process will also create rpms dir under it, that made rpms/rpms. Need to delete the exist one, then it works fine.
> Anyway. I am sure there is a bug, and it looks like depmod is not parsing the
> dd.conf files as Martin says. I'm just wanting to confirm you didn't actually
> test having the virtual hardware present, but I don't think this is Martin's
> problem. I think this is something I can have fixed up real soon now. That
> said, if Martin is going on vacation, I'd like to know when, etc.
> 
> Jon.

(In reply to comment #39)
> Also, at what stage are you running busybox? And are you using a custom image
> to get a busybox shell during the loader stage?    

Just added the busybox in the initrd.img, nothing more than that.

*** Bug 616830 has been marked as a duplicate of this bug. ***

So after way too much time thinking everything was broken...I realize it all works just fine, it's just that depmod doesn't equate compressed and non-compressed versions of module files. This is because anaconda's initrd contains compressed versions of modules, not there post-install.

To see what I mean, on a fuly installed system:

/lib/modules/2.6.32-44.1.el6.x86_64/updates/DD -> /test/DD/lib/modules

and have the sym53c8xx.ko in place:

/lib/modules/2.6.32-44.1.el6.x86_64/updates/DD/2.6.32-44.el6.x86_64/extra/sym53c8xx/sym53c8xx.ko

But in the install root, the .ko shipped in anaconda is compressed, and the driver update is compressed. The fix is to have anaconda treat them both the same. I'm working on that now, should be done soon.

Jon.

To make this simpler, there's a "bug" in depmod in that sym53c8xx.ko.gz and sym53c8xx.ko are treated as different by depmod. I am going to fix it so that it will view them as the same file, and replace one with the other. Then it should work, but we will need to test. Especially with the correct SCSI device :)

This is still an urgent issue. Driver Update Disks are not working correctly. I have sent email to David and Denise - would anyone else like to receive a copy of our reference driver disk to reproduce the problem with anaconda?

I am re-assigning this bug to module-init-tools to cover the depmod issue that I fixed already in the module-init-tools-3.9-16 release. There is a new bug that covers the larger issue with Driver Update Disks in RHEL6, that I have described at the following location: https://bugzilla.redhat.com/show_bug.cgi?id=618862

(In reply to comment #49)
> I am re-assigning this bug to module-init-tools to cover the depmod issue that
> I fixed already in the module-init-tools-3.9-16 release. 

Moving to POST.

Provided module-init-tools-3.9-16 location to Dell via email. Dell will report back on their testing.

Dell -- Any feedback on this one?

module-init-tools-3.9-16 is already present in RHEL6.0-20100730.5-Server-x86_64-DVD1.iso. (Snapshot 9)

Hence we are using this build instead of  module-init-tools that was sent via e-mail.

We are in process of validating this feature in snapshot9 and will update the result soon.

Thanks
Pani

Please bear in mind that there are still some Driver Update Disk issues in RHEL6 that the installer team are working hard to resolve. In the meantime, you might like to take a look at some updated example driver disks:

http://people.redhat.com/jcm/el6/dup/examples/

Jon.

Verify the bug on i386 and x86_64, working as expected. So close this bug as verified. Thanks.

Best,
Chao

Chao: please also verify it works if you symlink i686 to i386 per my email.

Thanks. Per my email, the next release of ddiskit will have symlinks for i386.

(In reply to comment #62)
> Thanks. Per my email, the next release of ddiskit will have symlinks for i386.

Should we add this to technical notes? 

Best,
Chao

Nope. We don't ship ddiskit with the RHEL6 media.

If you've verified this, please set the verified flag.  Thanks!

My understanding is that Dell has verified this item. Setting 'Verified' field.

Red Hat Enterprise Linux 6.0 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.