Description of problem: After upgrading from 11 to 12, on first boot, it got stuck. after removing quite, i discovered it was stuck on mounting filesystems. so removes the xfs partition from the fstab and it boots ok. tried to mount manualy wont mount. N.B. it is a hardware raid5 on a promise supertrack 8350 uses stex driver. it is an lvm2 volume the root file system is ext3 and is also on the same raid card but not LVM. when i reboot to the old f11 kernel i can still mount it fine and access it. Additional info: attached is the relevant info from the /var/log/messages with my hose name removed.
Created attachment 438399 [details] excerpt from /var/log/messages
This does not look like an xfs bug; it looks like you have storage errors: Aug 15 05:26:12 kernel: stex(0000:03:0e.0): aborting command Aug 15 05:26:12 kernel: sd 4:0:2:0: [sdb] CDB: Write(10): 2a 00 91 87 a4 fa 00 02 e0 00 Aug 15 05:26:12 kernel: stex(0000:03:0e.0): aborting command Aug 15 05:26:12 kernel: sd 4:0:6:0: [sdc] CDB: Write(10): 2a 00 11 9a 5c 49 00 00 08 00 Aug 15 05:26:12 kernel: stex(0000:03:0e.0): aborting command Aug 15 05:26:12 kernel: sd 4:0:6:0: [sdc] CDB: Write(10): 2a 00 11 99 e0 d9 00 00 08 00 Aug 15 05:26:12 kernel: stex(0000:03:0e.0): aborting command Aug 15 05:26:12 kernel: sd 4:0:6:0: [sdc] CDB: Write(10): 2a 00 11 9d e1 a1 00 00 08 00 however it is kjournald that eventually gets stuck: Aug 15 05:28:09 kernel: INFO: task kjournald:381 blocked for more than 120 seconds. If this is also on the raid card, then you have 2 filesystems which seem to be unhappy on this same block device. I'm inclined to blame the stex driver if it works in 11 and not 12. Perhaps you can try the very latest fedora-12 kernel, or rawhide kernels...? Thanks, -Eric
sorry what i meant was that the card has 2 differnt LVs, LV1 = 2.5 tb lvm with a 2.5tb xfs partition LV2 = 180 gb with 1 windows partition and one linux (fedora 12 with some f11 kernels still) i can mount and boot from LV2 but not LV1 which makes me think it is not the stex driver. as if it was stex wouldnt that mean i cant mount the lv2?
Nb im using the latest kernel for 12 already,(not raw hide though, will try it if all else fails)
It'd be nice to try a rawhide kernel just as a test. So LV1 and LV2 are both on stex; you see a failure of xfs mount but then kjournald gets hung up too, makes me wonder if it's unhappy storage. Just for fun can you try adding, temporarily, "nobarrier" to the xfs mount options? It's just a guess... -Eric
tried no barrier but same problem. how do i install the rawhide kernel?
replaced the 13 with a new install of 11 and i can mount the partition from there.
Confused. What does "replaced the 13" mean? Bleeding-edge fedora kernels can be found at http://kojipkgs.fedoraproject.org/packages/kernel/2.6.36/0.0.rc0.git1.fc15/ but bear in mind that it's a heavy development kernel, etc. http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35/3.fc14/ is at least a released upstream kernel. I'm not sure if you'll run into any dependency problems or not... -Eric
i mean i formated the disk to try a new install of 11. i can re install it and try it the new kernel.
ok. tried both . in a fresh install of 13. still no luck. i tried both with and without nobarriers.
Can you attach a full dmesg after the failed mount? Thanks, -Eric
attached. I let it run a through a couple of times. i did notice the raid card beeps every so often, the same beep it makes when i start up the system.
Created attachment 438958 [details] dmesg
(In reply to comment #12) > attached. > > I let it run a through a couple of times. i did notice the raid card beeps > every so often, the same beep it makes when i start up the system. i mean i followed the dmesg output and let it continue till it had filled out a few times. but that log is from a single attempts at mounting
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 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.