Bug 179100
Summary: | LTC21035-network install of Fedora Test 2 fails on some partitions | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | IBM Bug Proxy <bugproxy> |
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | islifefun1975, mattdm |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | powerpc | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-03-11 00:04:26 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
IBM Bug Proxy
2006-01-27 14:11:21 UTC
How much memory do the partitions have? Is the setup exactly the same as that of another partition on the system? ---- Additional Comments From dvelarde.com 2006-01-30 11:13 EDT ------- system that fails settings: nachos: memory: min=2GB max=2GB current=2GB processing units: min=0.4 max=3 current=0.4 virtual processors: min=4 max=4 current=4 system that we were able to install: twix: (processors the same, more max memory) memory: min=2GB max=4GB current=2GB processing units: min=0.4 max=3 current=0.4 virtual processors: min=4 max=4 current=4 joy-hv4: (processors the same, more memory) memory: min=2GB 128MB max=4GB 128MB current=2GB 128 MB processing units: min=0.4 max=3 current=0.4 virtual processors: min=4 max=4 current=4 kitkat: (processors the same, more max memory) memory: min=2GB max=4GB current=2GB processing units: min=0.4 max=3 current=0.4 virtual processors: min=4 max=4 current=4 hvracer1: (same memory, min virtual processors is lower) memory: min=2GB max=2GB current=2GB processing units: min=0.4 max=3 current=1 virtual processors: min=1 max=4 current=4 I\'ll try to increase the max memory for the partition and see if we can install. ---- Additional Comments From dvelarde.com 2006-01-30 11:32 EDT ------- More partition info: The other failing partition: hvracer3: memory: min=2GB max=2GB current=2GB processing units: min=0.4 max=3 current=1 virtual processors: min=1 max=4 current=4 But this partition passed: hvracer2: memory: min=2GB max=2GB current=2GB processing units: min=0.4 max=3 current=1 virtual processors: min=1 max=4 current=4 So these 2 are exactly the same with different results. But I\'ll still try increasing the max memory on nachos to see if that helps. ---- Additional Comments From dvelarde.com 2006-01-31 10:08 EDT ------- I increased the max memory to 4GB but the installation fails as it did before. ---- Additional Comments From dvelarde.com 2006-02-03 11:52 EDT ------- Looking at /var/log/messages on both vioservers we see repeated messages like: Feb 2 11:54:48 engine1 kernel: Read (10) 00 11 7f d1 0a 00 00 08 00 Feb 2 11:54:48 engine1 kernel: attempt to access beyond end of device Feb 2 11:54:48 engine1 kernel: sdb1: rw=0, want=293589266, limit=35545056 Feb 2 11:54:48 engine1 kernel: ibmvscsis: Block operation failed Where sdb1 is not the partitions we\'re having trouble installing, but the partition sharing the same hard drive as the one we cannot install FC5T2 on. Both of the partitions causing the \"attempt to access beyond end of device\" messages have Fedora 5 Test 2 installed. What is the exact configuration you are using with ibmvscsis (partitions, what are you sharing to the partitions, etc.) Manoj, Can you replicate on a setup here using linux ibmvscsis. ---- Additional Comments From dvelarde.com 2006-02-09 16:26 EDT ------- We are using ibmvscsi. I don\'t see a /etc/ibmvscsis.conf on the vioserver. The system that we can\'t install FC5T2 on is 08=sdd2 # fdisk -l Disk /dev/sda: 73.4 GB, 73407488000 bytes 128 heads, 32 sectors/track, 35003 cylinders Units = cylinders of 4096 * 512 = 2097152 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 1 2032 41 PPC PReP Boot /dev/sda2 514 1026 1050624 82 Linux swap /dev/sda3 1027 13315 25167872 83 Linux Disk /dev/sdb: 73.4 GB, 73407488000 bytes 128 heads, 32 sectors/track, 35003 cylinders Units = cylinders of 4096 * 512 = 2097152 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 17501 35842032 83 Linux /dev/sdb2 17502 35003 35844096 83 Linux Disk /dev/sdc: 73.4 GB, 73407488000 bytes 128 heads, 32 sectors/track, 35003 cylinders Units = cylinders of 4096 * 512 = 2097152 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 17501 35842032 83 Linux /dev/sdc2 17502 35003 35844096 83 Linux Disk /dev/sdd: 73.4 GB, 73407488000 bytes 128 heads, 32 sectors/track, 35003 cylinders Units = cylinders of 4096 * 512 = 2097152 bytes Device Boot Start End Blocks Id System /dev/sdd1 1 17501 35842032 83 Linux /dev/sdd2 17502 35003 35844096 83 Linux Disk /dev/sde: 73.4 GB, 73407488000 bytes 128 heads, 32 sectors/track, 35003 cylinders Units = cylinders of 4096 * 512 = 2097152 bytes Disk /dev/sde doesn\'t contain a valid partition table Disk /dev/sdf: 73.4 GB, 73407488000 bytes 128 heads, 32 sectors/track, 35003 cylinders Units = cylinders of 4096 * 512 = 2097152 bytes Device Boot Start End Blocks Id System /dev/sdf1 1 17501 35842032 83 Linux /dev/sdf2 17502 35003 35844096 83 Linux How is the vio configured then (using AIX?), are you allocating the whole disk or using a loopback file? Which disk is the file for the failing lpar on, how are you allocating resources. I'd expect to see each partition having a PReP partition on it. The read past end seems suspect, and I need as much info as possible so we can try and replicate. ---- Additional Comments From dvelarde.com 2006-02-09 17:13 EDT ------- The vioserver has SLES 9 installed. /dev/sdd is split between 2 partitions. /dev/sdd1 has FC5T2 installed on it /dev/sdd2 is the partition we can\'t install FC5T2 on. ---- Additional Comments From gcwilson.com 2006-02-09 17:32 EDT ------- The vioserver is running SLES9 with some mandatory security updates. Disk mapping for the LPARs is as follows: coffee Vioserver SLES9 snickers User1 03=sdb1 FC5T2 twix User2 04=sdb2 FC5T2 jawbreaker Unassigned 06=sdc2, 05=sdc1 Unknown kitkat User3 07=sdd1 FC5T2 nachos Install victim 08=sdd2 Some rawhide popcorn User4 09=sdf1 FC5T2 The nachos LPAR is the one that fails to install. We noticed that upon restart, the kitkat LPAR physical disk, /dev/sdd1, had produced some log entries saying attempt to read past end of device. It may have little or nothing to do with the install problem. We have been trying to determine why FC5T2 installs fine on some LPARs and not on others. The one common denominator is all the failing LPARs have been allocated the second slice of the physical disk. I was thinking maybe physical disk partition size is not some magic multiple of blocks the installer wants. But please note, FC5T1 and several Rawhide builds installed fine on the now offending LPARs. We saw a strange firmware problem on one of our managed systems that a hard power off fixed. So I shutdown all the LAPRs and power cycled the entire managed system. But that had no effect on the installation problem--the FC5T2 installer still fails on nachos. ---- Additional Comments From dvelarde.com 2006-02-09 17:39 EDT ------- As a side note, we put SLES on our vioserver because we were told RHEL as the vioserver was broken. Does anyone know the status or if there is a bug open on that? ---- Additional Comments From gcwilson.com 2006-02-17 09:47 EDT ------- I just tried installing the nachos LPAR with Feb. 16 rawhide. It still fails in the same manner--before I even get a chance to attach to the vnc server. There is no detailed error message or log file I can find. This is displayed on the console: Running anaconda, the Fedora Core system installer - please wait... Framebuffer ioctl failed. Exiting. Probing for video card: Unable to probe Probing for monitor type: Unknown monitor No video hardware found, assuming headless Starting VNC... The VNC server is now running. Please connect to nachos.ltc.austin.ibm.com:1 to begin the install... Press <enter> for a shell Starting graphical installation... install exited abnormally sending termination signals...done sending kill signals...done disabling swap... unmounting filesystems... /mnt/runtime done disabling /dev/loop0 /proc done /dev/pts done /sys done /tmp/ramfs done /selinux done you may safely reboot your system This issue is an impediment to our LSPP testing. Does a text install work on the lpars in question? By any chance did the lpars in question have AIX on previously, if so what version? Can you boot into OF and printenv and attache the output. ---- Additional Comments From gcwilson.com 2006-02-17 10:32 EDT ------- So far as I know, we received these machines new and AIX has never been installed on them. This is happening on LPARs on 2 separate managed systems, BTW. I just installed the popcorn LPAR on the same managed system no problem. I tried installing nachos in text mode and w/o kickstart. Still no go. Here are OF contents before I got rid of vnc and kickstart: 0 > printenv -------------- Partition: of-config -------- Signature: 0x50 --------------- ibm,fw-dc-select 100 0 ibm,fw-mouse-device nomouse nomouse ibm,fw-default-mac-address? false false ibm,fw-forced-boot ibm,fw-n-bc 255.255.255.255 255.255.255.255 ibm,fw-n-bretry 00 00 ibm,fw-n-tretry 00 00 ibm,fw-n-dbfp 00000000 00000000 ibm,fw-n-dafp 00000000 00000000 ibm,fw-n-rc A A ibm,fw-n-ru Y Y ibm,fw-clientipaddr 000.000.000.000 000.000.000.000 ibm,fw-serveripaddr 000.000.000.000 000.000.000.000 ibm,fw-gatewayipaddr 000.000.000.000 000.000.000.000 ibm,fw-netmask 255.255.255.000 255.255.255.000 -------------- Partition: common -------- Signature: 0x70 --------------- little-endian? false false real-mode? true true auto-boot? true true diag-switch? false false fcode-debug? false false oem-banner? false false oem-logo? false false use-nvramrc? false false ibm,fw-tty-language 1 1 ibm,fw-new-mem-def false false real-base c00000 c00000 virt-base ffffffff ffffffff real-size 1000000 1000000 virt-size ffffffff ffffffff load-base 4000 4000 screen-#columns 64 64 screen-#rows 28 28 selftest-#megs 0 0 boot-device /vdevice/v-scsi@30000003/disk@8000000000000000 /vdevice/l-lan@30000002:speed=auto,duplex=auto,9.3.80.16,,9.3.191.170,9.3.191.1 boot-file diag-device /vdevice/v-scsi@30000003/disk@8000000000000000 /vdevice/l-lan@30000002:speed=auto,duplex=auto,9.3.80.16,,9.3.191.170,9.3.191.1 diag-file vnc vncpassword=install ks=http://9.3.192.190/cgi-bin/ks diag output-device /vdevice/vty@30000000 com1 input-device /vdevice/vty@30000000 com1 oem-banner oem-logo nvramrc boot-command boot boot reboot-command security-#badlogins 0 0 security-mode none none security-password pw-status menu? false false ibm,fw-find-tape-alias false true ibm,fw-find-cdrom-alias false true ibm,dasd-spin-interval 5 5 ibm,fw-menu-de96d0006002 auto,auto,9.3.191.170,9.3.80.16,9.3.191.1,255.255.255.000,Standard,No, ok And here is the entire console log from the text mode boot: BOOTP: chosen-network-type = ethernet,auto,none,auto BOOTP: server IP = 9.3.80.16 BOOTP: requested filename = BOOTP: client IP = 9.3.191.170 BOOTP: client HW addr = de 96 d0 0 60 2 BOOTP: gateway IP = 9.3.191.1 BOOTP: device /vdevice/l-lan@30000002 BOOTP: loc-code U9124.720.1008D8F-V6-C2-T1 BOOTP R = 1 BOOTP S = 2 FILE: /tftpboot/install_RHEL_Fedora_0216 FINAL Packet Count = 15931 FINAL File Size = 8156232 bytes. load-base=0x4000 real-base=0xc00000 Elapsed time since release of system processors: 22483 mins 23 secs zImage starting: loaded at 0x00300000 (sp: 0x0195ffe0) Allocating 0x61a258 bytes for kernel ... trying: 0x01400000 OF version = \'IBM,SF230_120\' trying: 0x01500000 trying: 0x01600000 trying: 0x01700000 trying: 0x01800000 trying: 0x01900000 trying: 0x01a00000 trying: 0x01b00000 trying: 0x01c00000 Allocating 0x5bdf35 bytes for initrd ... trying: 0x0221b000 initial ramdisk moving 0x221b000 <- 0x4f864c (0x5bdf35 bytes) initrd head: 0x1f8b0800 gunzipping (0x1c00000 <- 0x30ad80:0x4f864c)...done 0x59d948 bytes ... skipping 0x10000 bytes of ELF header kernel: entry addr = 0x1c10000 a1 = 0x221b000, a2 = 0x5bdf35, prom = 0xc39a48, bi_recs = 0x0, OF stdout device is: /vdevice/vty@30000000 Hypertas detected, assuming LPAR ! command line: memory layout at init: memory_limit : 0000000000000000 (16 MB aligned) alloc_bottom : 00000000027d9000 alloc_top : 0000000008000000 alloc_top_hi : 0000000080000000 rmo_top : 0000000008000000 ram_top : 0000000080000000 Looking for displays instantiating rtas at 0x00000000077c0000 ... done 0000000000000000 : boot cpu 0000000000000000 0000000000000002 : starting cpu hw idx 0000000000000002... done 0000000000000004 : starting cpu hw idx 0000000000000004... done 0000000000000006 : starting cpu hw idx 0000000000000006... done copying OF device tree ... Building dt strings... Building dt structure... Device tree strings 0x00000000027da000 -> 0x00000000027db03b Device tree struct 0x00000000027dc000 -> 0x00000000027e3000 Calling quiesce ... returning from prom_init Page orders: linear mapping = 24, others = 12 Found initrd at 0xc00000000221b000:0xc0000000027d8f35 Partition configured for 8 cpus. Starting Linux PPC64 #1 SMP Wed Feb 15 15:53:32 EST 2006 ----------------------------------------------------- ppc64_pft_size = 0x1a ppc64_interrupt_controller = 0x2 platform = 0x101 physicalMemorySize = 0x80000000 ppc64_caches.dcache_line_size = 0x80 ppc64_caches.icache_line_size = 0x80 htab_address = 0x0000000000000000 htab_hash_mask = 0x7ffff ----------------------------------------------------- [boot]0100 MM Init [boot]0100 MM Init Done Linux version 2.6.15-1.1955_FC5 (bhcompile.redhat.com) (gcc version 4.1.0 20060214 (Red Hat 4.1.0-0.27)) #1 SMP Wed Feb 15 15:53:32 EST 2006 [boot]0012 Setup Arch Node 0 Memory: 0x8000000-0x44000000 Node 1 Memory: 0x0-0x8000000 0x44000000-0x80000000 EEH: No capable adapters found PPC64 nvram contains 7168 bytes Using shared processor idle loop [boot]0015 Setup Done Built 2 zonelists Kernel command line: [boot]0020 XICS Init xics: no ISA interrupt controller [boot]0021 XICS Done PID hash table entries: 4096 (order: 12, 131072 bytes) time_init: decrementer frequency = 188.049000 MHz time_init: processor frequency = 1504.392000 MHz Page orders: linear mapping = 24, others = 12 Found initrd at 0xc00000000221b000:0xc0000000027d8f35 Partition configured for 8 cpus. Starting Linux PPC64 #1 SMP Wed Feb 15 15:53:32 EST 2006 ----------------------------------------------------- ppc64_pft_size = 0x1a ppc64_interrupt_controller = 0x2 platform = 0x101 physicalMemorySize = 0x80000000 ppc64_caches.dcache_line_size = 0x80 ppc64_caches.icache_line_size = 0x80 htab_address = 0x0000000000000000 htab_hash_mask = 0x7ffff ----------------------------------------------------- [boot]0100 MM Init [boot]0100 MM Init Done Linux version 2.6.15-1.1955_FC5 (bhcompile.redhat.com) (gcc version 4.1.0 20060214 (Red Hat 4.1.0-0.27)) #1 SMP Wed Feb 15 15:53:32 EST 2006 [boot]0012 Setup Arch Node 0 Memory: 0x8000000-0x44000000 Node 1 Memory: 0x0-0x8000000 0x44000000-0x80000000 EEH: No capable adapters found PPC64 nvram contains 7168 bytes Using shared processor idle loop [boot]0015 Setup Done Built 2 zonelists Kernel command line: [boot]0020 XICS Init xics: no ISA interrupt controller [boot]0021 XICS Done PID hash table entries: 4096 (order: 12, 131072 bytes) time_init: decrementer frequency = 188.049000 MHz time_init: processor frequency = 1504.392000 MHz Console: colour dummy device 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) freeing bootmem node 0 freeing bootmem node 1 Memory: 2036756k/2097152k available (4336k kernel code, 76324k reserved, 1348k data, 500k bss, 256k init) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 Processor 1 found. Processor 2 found. Processor 3 found. Processor 4 found. Processor 5 found. Processor 6 found. Processor 7 found. Brought up 8 CPUs Node 0 CPUs: 0-7 Node 1 CPUs: migration_cost=0,214 checking if image is initramfs... it is Freeing initrd memory: 5879k freed NET: Registered protocol family 16 Installing base platform functions... All base functions installed PCI: Probing PCI hardware PCI: Probing PCI hardware done usbcore: registered new driver usbfs usbcore: registered new driver hub IBM eBus Device Driver RTAS daemon started IOMMU table initialized, virtual merging enabled scan-log-dump not implemented on this system audit: initializing netlink socket (disabled) audit(1140167940.735:1): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key 716A3ACFB2DC072C - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 HVSI: registered 0 devices Generic RTC Driver v1.07 Welcome to Fedora Core install exited abnormally sending termination signals...done sending kill signals...done disabling swap... unmounting filesystems... /mnt/runtime done disabling /dev/loop0 /proc done /dev/pts done /sys done /tmp/ramfs done /selinux done you may safely reboot your system The only difference in printenv I see in the machine here is use-nvramrc? true false and in yours it is set to 'false false' Dont know if that makes a difference. ---- Additional Comments From gcwilson.com 2006-02-17 16:20 EDT ------- It\'s set false false on both popcorn and nachos. I\'ll try setting nachos\' to true. ---- Additional Comments From gcwilson.com 2006-02-17 16:50 EDT ------- Unfortunately setting use-nvramrc? to true didn\'t make a difference. ---- Additional Comments From gcwilson.com 2006-02-18 16:08 EDT ------- I tried installing on a couple of LPARs on a another slower managed system that has the same problem. And I was able to get enough time in the shell to tail /tmp/anaconda.log. I compared the one that succeeded with the one that failed. They are both identical until they check sda. Looks like the installer blows up at or just before \"self.driveList(): [\'sda\']\": hvracer3--failed: . . . 19:35:29 INFO : Running anaconda script /usr/bin/anaconda 19:35:29 DEBUG : adding extraArg --vnc 19:35:32 INFO : Display mode = g 19:35:32 INFO : Method = http://george-hv4.ltc.austin.ibm.com/rawhide/pub/fedora/core/development/ppc 19:35:33 INFO : No video hardware found, assuming headless 19:35:37 INFO : Starting VNC... 19:35:38 INFO : The VNC server is now running. 19:35:38 INFO : Please connect to ltc-9-3-190-241.ltc.austin.ibm.com:1 to begin the install... 19:35:39 INFO : Started mini-wm 19:35:39 INFO : Starting graphical installation... 19:35:41 INFO : anaconda floppy device sda install exited abnormally Terminated . . . hvracer2--succeeded: . . . 19:40:11 INFO : Running anaconda script /usr/bin/anaconda 19:40:11 DEBUG : adding extraArg --vnc 19:40:14 INFO : Display mode = g 19:40:14 INFO : Method = http://george-hv4.ltc.austin.ibm.com/rawhide/pub/fedora/core/development/ppc 19:40:16 INFO : No video hardware found, assuming headless 19:40:20 INFO : Starting VNC... 19:40:20 INFO : The VNC server is now running. 19:40:20 INFO : Please connect to ltc-9-3-190-237.ltc.austin.ibm.com:1 to begin the install... 19:40:22 INFO : Started mini-wm 19:40:22 INFO : Starting graphical installation... 19:40:24 INFO : anaconda floppy device sda 19:40:27 DEBUG : self.driveList(): [\'sda\'] 19:40:27 DEBUG : DiskSet.skippedDisks: [] 19:40:27 DEBUG : DiskSet.skippedDisks: [] 19:40:27 DEBUG : starting all dmraids on drives [\'sda\'] 19:40:27 DEBUG : scanning for dmraid on drives [\'sda\'] . . . I can do an fdisk -l and see the partitions on sda in the time window just after the driver is loaded and before the installer dies. So the driver appears to be working. There is nothing strange for the partition in the vioserver\'s /var/log/messages. However, once again this LPAR is using the second partition of the physical disk. And the LPAR on the first physical partition has some attempts to seek past end of device in the vioserver\'s log. That may not mean much as the requests are way past the end of the device, and presumably the driver doesn\'t honor them. Here\'s the fdisk -l output for the failing LPAR, BTW: sh-3.1# fdisk -l Disk /dev/sda: 18.2 GB, 18201182208 bytes 255 heads, 63 sectors/track, 2212 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 1 8001 41 PPC PReP Boot /dev/sda2 2 26 200812+ 83 Linux /dev/sda3 27 1951 15462562+ 83 Linux /dev/sda4 1952 2212 2096482+ 5 Extended /dev/sda5 1952 2212 2096451 82 Linux swap / Solaris ---- Additional Comments From gcwilson.com 2006-02-22 15:25 EDT ------- Still happens on FC5T3. *** Bug 182450 has been marked as a duplicate of this bug. *** Can you test with the nodmraid argument to the bootloader: eg linux64 vnc nodmraid ---- Additional Comments From gcwilson.com 2006-02-23 19:30 EDT ------- Thanks, Paul! That worked. Can you give us a quick explanation just for our edification? And will this be a documented workaround, or are you going to patch it? I can\'t tell you how much we appreciate your persistence in tracking this one down. It\'s been vexing us for some time. Can we see what it says if you run "dmraid -ay -t" ? (btw, if you're having trouble with having enough time in the shell, add "nokill" to the command line -- then when it dies, it won't kill the shell) ---- Additional Comments From gcwilson.com 2006-03-22 12:07 EDT ------- Prior to the install? Because the installer worked with nodmraid, I successfully re-installed all the failing LPARs. So I no longer have any in the failing state. A dmraid -ay -t now yields: No RAID disks. I may have had LVM installed prior to the reinstall, which I eventually stopped using as our automated test system can\'t use initrds right now. I take it that\'s what you\'re looking for? I wish I\'d known about nokill last month :-) ---- Additional Comments From gcwilson.com 2006-03-22 20:29 EDT ------- I got some new disks for our HV4s and don\'t have all available slices installed at the moment. One of the free slices contains one of the failing installations. I booted an LPAR from it no problem. So I want through the install scenario w/FC5. This time I used nokill but did not use nodmraid. When I ran dmraid -ay -t I got a segmentation fault. Bumped up my core file size. I got a truncated core file but no useful stack trace. This LPAR was NOT using LVM. When I ran dmraid -ay -t from the fully booted LPAR (containing some unknown rawhide from 2mo. + ago) it also segfaulted. The dmraid code has come a long way in the past couple releases. Can you please test with Fedora 7 test 2 and let us know if this is still a problem? Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer test releases. We're cleaning up the bug database and making sure important bug reports filed against these test releases don't get lost. It would be helpful if you could test this issue with a released version of Fedora or with the latest development / test release. Thanks for your help and for your patience. [This is a bulk message for all open FC5/FC6 test release bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] requested by Jams Antill The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there have not been any updates to the report since thirty (30) days or more since we requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance. Closing on our side. This bug is no longer a problem with current Fedora or RHEL versions. |