Description of problem: A clean installation of Fedora 11 or a kernel upgrade thereafter make the system unbootable. Things were ok in 9 and 10 (at least). Version-Release number of selected component (if applicable): Fedora 11 How reproducible: Clean install of Fedora 11 or kernel upgrade. Additional info: Comment #56 on "https://bugzilla.redhat.com/show_bug.cgi?id=162046" contains instructions on how to make the system bootable again.
I have no access to any B&W G3 Power Macintosh. Can you please provide output of this two commands? 1) ybin -v 2) parted -l
Here it is: [jps@bono ~]$ sudo ybin -v [sudo] password for jps: ybin: Finding OpenFirmware device path to `/dev/sda2'... ybin: Installing first stage bootstrap /usr/lib/yaboot/ofboot onto /dev/sda2... ybin: Installing primary bootstrap /usr/lib/yaboot/yaboot onto /dev/sda2... ybin: Installing /etc/yaboot.conf onto /dev/sda2... ybin: Setting attributes on ofboot... ybin: Setting attributes on yaboot... ybin: Setting attributes on yaboot.conf... ybin: Blessing /dev/sda2 with Holy Penguin Pee... ybin: Updating OpenFirmware boot-device variable in nvram... [jps@bono ~]$ sudo parted -l Model: ATA QUANTUM FIREBALL (scsi) Disk /dev/sda: 13.0GB Sector size (logical/physical): 512B/512B Partition Table: mac Number Start End Size File system Name Flags 1 512B 32.8kB 32.3kB Apple 2 32.8kB 1081kB 1049kB hfs untitled boot 3 1081kB 211MB 210MB ext3 untitled 4 211MB 12.9GB 12.7GB ext3 untitled 5 12.9GB 13.0GB 134MB linux-swap swap
It seems to be all ok. System is unbootable? ybin correctly found /dev/sda2. If system is unbootable, what do you see on screen?
Yes, the system is bootable now. It wasn't, immediately after a fresh install of 11. And it isn't, every time I update the kernel via yum. When this happens, the only solution is to boot from CD with anaconda in rescue mode, chroot to my instalation and do a "/sbin/ybin -o hd:2". After this, the system is bootable again. Thanks.
Ooops!! I just rebooted the system and it's not booting anymore. Seems that that "ybin -v" thing damaged the OF settings. Time to apply the rescue CD procedure.
Sorry for forcing you to make your system unbootable again :) Please provide output of: /sbin/ybin -v --debug /sbin/ybin -v --debug -o hd:2 (with -o hd:2 as the last, I don't want to make your system unbootable again)
[jps@bono ~]$ sudo /sbin/ybin -v --debug ybin: Finding OpenFirmware device path to `/dev/sda2'... ybin: DEBUG: ofboot set to `/disk@0:2' ybin: DEBUG: OS=4 ybin: DEBUG: /bin/sh /usr/lib/yaboot/ofboot 4 bootyaboot 5 0 yaboot GNU l /disk@0:2 ,\\yaboot cd CDROM c cd: ,\\:tbxi net Network n enet: 0 of OpenFirmware o quit now ybin: DEBUG: set magicboot to /tmp/ofboot.CvHEkL ybin: Installing first stage bootstrap /usr/lib/yaboot/ofboot onto /dev/sda2... ybin: Installing primary bootstrap /usr/lib/yaboot/yaboot onto /dev/sda2... ybin: Installing /etc/yaboot.conf onto /dev/sda2... ybin: Setting attributes on ofboot... ybin: Setting attributes on yaboot... ybin: Setting attributes on yaboot.conf... ybin: Blessing /dev/sda2 with Holy Penguin Pee... ybin: Updating OpenFirmware boot-device variable in nvram... ybin: DEBUG: boot-device=/disk@0:2,\\:tbxi [jps@bono ~]$ sudo /sbin/ybin -v --debug -o hd:2 ybin: DEBUG: OS=4 ybin: DEBUG: /bin/sh /usr/lib/yaboot/ofboot 4 bootyaboot 5 0 yaboot GNU l hd:2 ,\\yaboot cd CDROM c cd: ,\\:tbxi net Network n enet: 0 of OpenFirmware o quit now ybin: DEBUG: set magicboot to /tmp/ofboot.9V7UTn ybin: Installing first stage bootstrap /usr/lib/yaboot/ofboot onto /dev/sda2... ybin: Installing primary bootstrap /usr/lib/yaboot/yaboot onto /dev/sda2... ybin: Installing /etc/yaboot.conf onto /dev/sda2... ybin: Setting attributes on ofboot... ybin: Setting attributes on yaboot... ybin: Setting attributes on yaboot.conf... ybin: Blessing /dev/sda2 with Holy Penguin Pee... ybin: Updating OpenFirmware boot-device variable in nvram... ybin: DEBUG: boot-device=hd:2,\\:tbxi And yes, after these two operations I rebooted, and the system boots just fine.
Is there any chance that you can create a tarball of /proc/device-tree and attach it to this big?
Created attachment 358981 [details] A copy of /proc/device-tree Upon request by comment #8.
(In reply to comment #9) > Created an attachment (id=358981) [details] > A copy of /proc/device-tree > > Upon request by comment #8. Thanks. Can you supply the output from: ofpath --debug /dev/sda2
[jps@bono ~]$ ofpath --debug /dev/sda2 ofpath: DEBUG: SUBNODE=a SUBDEV=1 ofpath: DEBUG: DEVINFO=Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: QUANTUM FIREBALL Rev: A0A. Type: Direct-Access ANSI SCSI revision: 05 ofpath: DEBUG: DEVTYPE=Direct-Access ofpath: DEBUG: DEVID=0 ofpath: DEBUG: DEVHOST=0 ofpath: DEBUG: DEVCOUNT=1 ofpath: DEBUG: DEVICE_HOST=0 ofpath: DEBUG: DEVICE_HOST=0 ofpath: DEBUG: SCSI_DRIVER= ofpath: DEBUG: SCSI_HOSTNUMBER= /disk@0:2
Can you please also provide output from: bash -x ofpath /dev/sda2
Created attachment 360370 [details] Output of "bash -x ofpath /dev/sda2"
(In reply to comment #13) > Created an attachment (id=360370) [details] > Output of "bash -x ofpath /dev/sda2" Thanks that's very helpful. It looks like we're unable to detect the correct driver for your disk so we (ofpath) wanders off into the weeds and then just plain gets it wrong. Big surprise there. Can you please provide the boot logs (dmesg after a fresh boot). This should show us what driver is in fact responsible for your disk (I'd hope it is pata_cmd64x). Also for the sake of completeness can I get a tarball of /proc/scsi?
Created attachment 363163 [details] A copy of dmesg
Created attachment 363165 [details] A tarball of /proc/scsi
I don't know how relevant this is, but I have a FireWire/USB PCI card on this machine. Here's the output of lspci: [jps@bono tmp]$ lspci 00:00.0 Host bridge: Motorola MPC106 [Grackle] (rev 40) 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 02) 00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG 01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link Layer Controller (rev 02) 01:01.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 05) 01:03.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 01:03.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 01:03.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) 01:03.3 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 46) 01:05.0 Class ff00: Apple Computer Inc. Paddington Mac I/O 01:06.0 USB Controller: OPTi Inc. 82C861 (rev 10) I have an external FireWire disk connected to this card. It shows up as /dev/sdb.
Thanks. Tarball of /proc/scsi is not much usefull. Can you please use something like: for file in /proc/scsi/* /proc/scsi/sg/*; do if [[ ! -d $file ]]; then echo "*$file" >> scsi.txt ; cat "$file" >> scsi.txt; fi; done; tar cfz scsi.tgz scsi.txt and upload scsi.tgz file?
Created attachment 363202 [details] Contents of /proc/scsi and /proc/scsi/sg The attachment is the result of: for file in /proc/scsi/* /proc/scsi/sg/*; do if [[ ! -d $file ]]; then echo "*$file"; cat "$file"; echo; echo; fi; done > scsi.txt
(In reply to comment #16) > Created an attachment (id=363165) [details] > A tarball of /proc/scsi Ahhhh thanks! So the "root cause" of this is that the PATA driver for your disk doesn't create a /proc/scsci/pata_cmd64x directory and as such ofpath fails to correctly detect the correct driver so ofpath basically guesses wrong. So the best solution is to teach ofpath about /sys (in the same way others have done for IDE devices) and use that in preference to /proc. I think a nasty work around would be to create a /usr/sbin/ofpath "script" that simply echo's the correct string. I think that will hide the bug for you until we can fix ofpath.
(In reply to comment #20) "I think that will hide the bug for you until we can fix ofpath." For the moment, and for emergency situations, I can live with the procedure that I described in comment #4. And now every time I upgrade the kernel I just do "/sbin/ybin -o hd:2" before rebooting. But just for the sake of completeness, what would be the correct string to be returned by ofpath in my situation? Is it reasonable to expect to have this fixed by F12? Thanks.
(In reply to comment #21) > (In reply to comment #20) > > "I think that will hide the bug for you until we can fix ofpath." > > For the moment, and for emergency situations, I can live with the procedure > that I described in comment #4. And now every time I upgrade the kernel I just > do "/sbin/ybin -o hd:2" before rebooting. > > But just for the sake of completeness, what would be the correct string to be > returned by ofpath in my situation? #!/bin/sh echo 'hd:2' should be fine for a /usr/sbin/ofpath > Is it reasonable to expect to have this fixed by F12? It's entirely reasonable to expect, but sadly I do not think it will happen. I'll do my best for F-13. In the meantime either workaround is the best I can do.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The bug was reassigned to me and seems to be quite old. The ppc arch is currently secondary architecture and the F16 Alpha was announced. So I'd like to check for the status of this bug. Do you tested or do you plan to use F16 for ppc? Jiri
(In reply to comment #25) > The bug was reassigned to me and seems to be quite old. The ppc arch is > currently secondary architecture and the F16 Alpha was announced. So I'd like > to check for the status of this bug. Do you tested or do you plan to use F16 > for ppc? It's still a problem. It needs a major update to ofpath (which is scheduled for the 1.3.18 release) Feel free to assign it to me, I'll do my best to verify that the 1.3.18 release fixes it Tony.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.