Description of problem: I attempted to install 1027 on the i825 in the lab using the boot.img file. The installation get's to point where it asks for the disks to include, and it lists the available disks. None are shown, even though they are present. Version-Release number of selected component (if applicable): the 1020 build worked on this system. The 1027 installation failed on the exact same hardware configuration. The failing boot.img was taken from /vol/engineering/redhat/rel-eng/RHEL5-Server-20061027.0/4.92/ppc/os (/images/iSeries/boot.img). How reproducible: The i825 has a boot.img in the /home/ directory. Partition 2 is set up to boot this image and start the installation. Steps to Reproduce: 1. to access the management box i825 telnet i825 enter USER: QSECOFR Password: SECOFR 2. to see the current kerne that is booted on this box, after step 1 above: At the ===> prompt, enter wrkcfgsts *nws (with the cd in the cdrom). A "Work with Configuration Status menu will appear. Make sure the partition (LINUX02) is "VARIED OFF", if not, enter "2=Vary off" at the __ Opt column before the partition. Enter 8 in the opt field for the partition, Enter 2 in the opt field for change PgDn to the fields for IPL Source, Verify the ipl stream file is set to '/home/boot.img' 3. If you wish to put another boot.img on this host, you can: - ftp into i825, user QSECOFR/SECOFR - cd /home before the put - update the boot file as above if the file has another name. 4. vary on the parition to start the boot process. - I used nfs mount options, for the 1027 images off of bigpapi 5.to access this serial console of i825-lp1: telnet i825 2301 > select 2<cr> LINUX02 as Guest partition Console (i.e. enter 1 <cr>0 > enter os/400 serivce tool login as 'LINUX02' > enter os/400 service tools admin as 'redhat' this will lead you to "console connected" <cr> .. should show you the installation screen. 6. note, there is a redhat DST/sst account on the i825 with the password linux in case you would like to update the hardware configuration via the i825. root 100yard- Actual results: Expected results: Additional info:
What sorts of disks are not being seen - connected via what adapters, using what drivers?
viodasd (virtual disks)
So, the probing code from the 20061027 tree, when run on an installed iSeries partition, correctly finds viodasd disks. Is viodasd being loaded on the box in question? This could be a kernel issue. Has the kernel from this tree been tested outside the installer environment?
I booted the new kernel ok on a non-lvm partition: [root@bmw ~]# cat /proc/version Linux version 2.6.18-1.2739.el5 (brewbuilder.redhat.com) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Thu Oct 26 16:07:54 EDT 2006 [root@bmw ~]# cat /proc/cmdline ro root=LABEL=/ rhgb quiet [root@bmw ~]# The viodasd module is in the ramdisk.image, so that's not the problem. Should have the cds in a little while...
I setup an install source with the 20061027 tree and just the first cd (all that I have downloaded so far). I got this message, too, so I ctl-z to a shell: sh-3.1# lsmod | grep viodasd viodasd 35313 0 sh-3.1# fdisk -l sh-3.1# cat /proc/partitions major minor #blocks name 7 0 84028 loop0 112 0 7173022 iseries/vda 112 1 40131 iseries/vda1 112 2 7132860 iseries/vda2 112 8 5124735 iseries/vdb 112 9 5124703 iseries/vdb1 112 16 5124735 iseries/vdc 112 17 5124703 iseries/vdc1 sh-3.1# fdisk /dev/iseries/vda Unable to open /dev/iseries/vda sh-3.1# ibmvscsic is not loaded (which is correct). I see the following in dmesg: <7>vio_register_driver: driver viodasd registering <4>blk_queue_max_sectors: set to minimum 128 <6>viod: disk 0: 14346045 sectors (7004 MB) CHS=893/255/63 sector size 512 <6> iseries/vda: iseries/vda1 iseries/vda2 <4>blk_queue_max_sectors: set to minimum 128 <6>viod: disk 1: 10249470 sectors (5004 MB) CHS=638/255/63 sector size 512 <6> iseries/vdb: iseries/vdb1 <4>blk_queue_max_sectors: set to minimum 128 <6>viod: disk 2: 10249470 sectors (5004 MB) CHS=638/255/63 sector size 512 <6> iseries/vdc: iseries/vdc1 <6>viocd: vers 1.06, hosting partition 0 I booted my existing partition fine with just viodasd (no ibmvscsic) and fdisk shows the disks.
There were no devices in /dev/iseries. Once I created the nodes fdisk saw the disks in the shell. However, I couldn't get them to show up in anaconda...
Ah, wait, the box I was testing on didn't have viodasd. Janice, any chance we could get some virtual disks added to i825-lp1?
hm.. i825-lp1 is the linux1 system, it only has virtual disks. Are we talking about the same systems? [root@i825-lp1 etc]# cat /proc/partitions major minor #blocks name 112 0 30724312 iseries/vda 112 1 16033 iseries/vda1 112 2 29166007 iseries/vda2 112 3 1534207 iseries/vda3 112 8 10241437 iseries/vdb 112 9 64228 iseries/vdb1 8 0 1048576 sda 8 16 10241437 sdb 8 17 64228 sdb1 [root@i825-lp1 etc]# [root@i825-lp1 etc]# lspci 1c:1c.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44) [root@i825-lp1 etc]# Janice
fyi.. at the time of the failure, on the screen I see: ┌─────────────────────────┤ Partitioning Type ├─────────────────────────┐ │ │ │ Installation requires partitioning of your hard drive. The │ │ default layout is reasonable for most users. You can either │ │ choose to use this or create your own. │ │ │ │ Remove all partitions on selected drives and create default layout. │ │ Remove linux partitions on selected drives and create default layout. │ │ Use free space on selected drives and create default layout. │ │ Create custom layout. │ │ │ │ Which drive(s) do you want to use for this installation? │ │ ↑ │ │ ▮ │ │ │ │ ┌────┐ ┌──────┐ │ │ │ OK │ │ Back │ │ │ └────┘ └──────┘ │ │ │ │ │ └───────────────────────────────────────────────────────── If I think the disks are there, but invisible, and press ok, I receive the msg: Welcome to Red Hat Enterprise Linux Server ┌────────────┤ No Drives Found ├─────────────┐ │ │ │ An error has occurred - no valid devices │ │ were found on which to create new file │ │ systems. Please check your hardware for │ │ the cause of this problem. │ │ │ │ ┌────┐ │ │ │ OK │ │ │ └────┘ │ │ │ │ │ └────────────────────────────────────────────┘ <Tab>/<Alt-Tab> between elements | <Space> selects | <F12> next screen If I then enter ctrl Z< I see: # cat /proc/partitions major minor #blocks name 7 0 84028 loop0 112 0 10241437 iseries/vda 112 1 16033 iseries/vda1 112 2 10225372 iseries/vda2 112 8 10241437 iseries/vdb 112 9 10241406 iseries/vdb1 sh-3.1# ls /dev/iseries/ vcda vcdb
OK, I've poked some more. So, I'm not sure how i825-lp1 actually got installed, if I'm reading this right - the vdX probing doesn't work at all currently. Did something change in the device layer for viodasd recently (/proc layout, /sys layout, etc.)?
What we currently have is: if (!access("/sys/bus/vio/drivers/viodasd", R_OK)) { DIR * dir; struct dirent * ent; int ctlNum; dir = opendir("/sys/bus/vio/drivers/viodasd"); while ((ent = readdir(dir))) { if (strncmp("viodasd", ent->d_name, 7)) continue; ctlNum = atoi(ent->d_name + 7); viodev = vioNewDevice(NULL); viodev->device = malloc(20); if (ctlNum < 26) { snprintf(viodev->device, 19, "iseries/vd%c", 'a' + ctlNum); } else { snprintf(viodev->device, 19, "iseries/vda%c", 'a' + ctlNum - 26); } viodev->desc = strdup("IBM Virtual DASD"); viodev->type = CLASS_HD; viodev->driver = strdup("viodasd"); if (devlist) viodev->next = devlist; devlist = (struct device *) viodev; } However, the sysfs layout for this directory just has links such as: 12 -> ../../../../devices/vio/12 13 -> ../../../../devices/vio/13 So, the code as written will never find disks. This is fixable, of course - working on that. But assuming that the sysfs layout has been the same for all of the RHEL5 alpha/beta kernels, I don't see how we could have ever installed. (The code reading /sys/bus/vio/drivers/viodasd originated on RHEL4; presumably that has the layout the code is expecting.)
OK, I've read the anaconda log. So, what appears to have happened is that anaconda loaded viodasd. It did not find any drives. It then probed for and found ibmvscsic (as noted, we used to show this available on iSeries.). When it loaded ibmvscsic, the iSeries viodasd disks then show up as scsi disks (/dev/sda, etc.). anaconda then installed onto that. It then rebooted with viodasd, and used the installed system that way. For the 1027 tree, we no longer have ibmvscsic on iSeries, as requested. So anaconda now can't see the disks at all, where before it saw them only by accident.
Send this over manually, since mirroring isn't working so hot (again): ------- Additional Comment #4 From Michael Ranweiler 2006-11-02 16:29 EDT [reply] ------- Internal Only Makes sense. If you attach it we'll try it out, too. I'm confused, though, about this kernel. If I extract the modules out of the milestone8 ramdisk.image.gz: mranweil@redsfan8:~/m8/modules> find -name "ipr*" mranweil@redsfan8:~/m8/modules> find -name "ibmvscsi*" ./2.6.18-1.2739.el5/ppc64iseries/ibmvscsic.ko mranweil@redsfan8:~/m8/modules> But you're right, I don't see ibmvscsic loaded. It's in /modules/modules.dep and /modules/modules.alias in the installer, though.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering. This request is not yet committed for inclusion in release.
Created attachment 140194 [details] Patch for this issue Here's a kudzu patch that redoes most of the vio probing into something smaller, simpler, and working (in theory). To test this in the installer, you'd need to rebuild kudzu, and then rebuild the installer against that, and then rebuild the boot images. If you've got an installed iSeries, you can just build a new kudzu and compare the output of 'kudzu -p -b vio' to see if it properly picks up the viocd and viodasd devices.
----- Additional Comments From saleon.com 2006-11-02 18:21 EDT ------- Glen, looks like there is some problem with the mirroring process. The last three comments before this one are not relevant to this bug. This is not a kudzu bug, it is a ibmveth bug.
----- Additional Comments From mranweil.com (prefers email at mjr.com) 2006-11-02 19:06 EDT ------- I did get better results. Here's the old kudzu: [root@metro kudzu-1.2.57.1.1]# kudzu -p -b vio - class: NETWORK bus: VIO detached: 0 device: eth2 driver: iseries_veth desc: "IBM Virtual Ethernet" - class: NETWORK bus: VIO detached: 0 device: eth0 driver: iseries_veth desc: "IBM Virtual Ethernet" - class: SCSI bus: VIO detached: 0 driver: ibmvscsic desc: "IBM Virtual SCSI" And the new one: [root@metro kudzu-1.2.57.1.1]# ./kudzu -p -b vio - class: NETWORK bus: VIO detached: 0 device: eth2 driver: iseries_veth desc: "IBM Virtual Ethernet" network.hwaddr: 02:01:ff:00:ff:06 - class: NETWORK bus: VIO detached: 0 device: eth1 driver: iseries_veth desc: "IBM Virtual Ethernet" network.hwaddr: 02:01:ff:03:ff:06 - class: SCSI bus: VIO detached: 0 driver: viodasd desc: "IBM Virtual DASD" - class: HD bus: VIO detached: 0 device: iseries/vda desc: "IBM Virtual DASD" - class: HD bus: VIO detached: 0 device: iseries/vdb desc: "IBM Virtual DASD" - class: HD bus: VIO detached: 0 device: iseries/vdc desc: "IBM Virtual DASD" [root@metro kudzu-1.2.57.1.1]#
this bug is not fixed in 20061102.2/4.92/, even for the iSeries in Westford case. I assume the above was never checked in? Janice
That version is not in that tree.
----- Additional Comments From rayda.com 2006-11-08 10:49 EDT ------- OK, so the milestone 9 does not have this fix (verified using partition bmw). But it also didn't show me any ipr disks yet. Was this fix necessary to correctly detect those also? This version was supposed to have the ipr fix in the config file... Will this fix be in the special build for iSeries we are waiting for?
this is in the modified state. can you tell me what package/version will contain this fix?
kudzu-1.2.57.1.7-1
----- Additional Comments From rayda.com 2006-11-08 13:28 EDT ------- Oops, my mistake. What I downloaded was NOT milestone 9, so the jury is still out. Sorry to raise the flag.
I tried both the 1107 and 1108 nightly builds and the disks were found on the i825 system. So this problem appears to be partially fixed. I'll continue testing the nightly builds. I did see the following error with both the 1107 and 1108 nightly builds: Welcome to Red Hat Enterprise Linux Server ┌────────────────────────────┤ Error ├────────────────────────────┐ │ │ │ Unable to read package metadata. This may be due to a missing │ │ repodata directory. Please ensure that your install tree has │ │ been correctly generated. Cannot open/read repomd.xml file │ │ for repository: anaconda-base-200611070133.ppc │ │ │ │ ┌───────┐ │ │ │ Abort │ │ │ └───────┘ │ │ │ │ │ └─────────────────────────────────────────────────────────────────┘ <Tab>/<Alt-Tab> between elements | <Space> selects | <F12> next s
That would be a different error - please open that as a different issue/bug.
Agreed. I just opened 214836 to track the above error. Since this is in the modified state, is it easier if we close this defect and reopen a new one if a similar problem occurs, but requires more cards than we have here? I think Mike saw a problem but hasn't had a chance to reproduce the error and retest with this code.
Sure.
Ray, This is fixed in the 20061107/08 builds. Have you actually seen this problem in one of the partner builds? If not, I'd like to close this as fixed, as I have confirmed it's working in the nightly builds.
----- Additional Comments From rayda.com 2006-11-09 17:13 EDT ------- This is fixed in the m9 + the new kudzu. Will close when we see it in m10/Beta2 that we don't have to patch for the install source.
changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|block |high Impact|------ |Installability ------- Additional Comments From rayda.com 2006-11-09 17:14 EDT ------- Lowering from block to high based on fix we have seen.
----- Additional Comments From yongwenw.com 2006-11-10 10:33 EDT ------- As Ray said in comment #21, the build we use is milestone 9 + a new kudzu. We would like to see the fix in an official drop before we close this bug. Or if it is more convenient to you, we can close this now and reopen it if we meet the problem again in the official drop.
changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ACCEPTED |CLOSED ------- Additional Comments From rayda.com 2006-11-14 16:03 EDT ------- Yes, this is definitely in this build. Closing.