https://bugzilla.novell.com/show_bug.cgi?id=457037
User rob.opensuse.linux@googlemail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=457037#c37
--- Comment #37 from Robert Davies 2008-12-12 05:17:34 MST ---
Created an attachment (id=259661)
--> (https://bugzilla.novell.com/attachment.cgi?id=259661)
Attempt 2 - hope this time it has the right info
Tejun :
Redone the lspci, this time it is -nnvvvxxx not -nnvvxxx, again from Live CD.
Before arranging to send, I think it makes sense to see if I can expose the
bug, with the controller on different hardware. Basically see if the bug with
pata_pdc202xx_old driver is purely controller related, or Mobo chipset and/or
disk and controller combo matters. Otherwise you could plug it in, find like
Alan Cox that "works for me" and then get another report from a production
customer system, where they aren't able to cooperate with tests (like intitial
bug reporters).
On kernel pata_pdc202xx_old fix, I did not actually expect one, as Alan Cox has
had it pending for a year. However we have got him looking at the DMA issues
on these cards, and he's got some test patches in the kernel bugzilla.
The main objective, which was to find a work round for problematic Promise
Controllers has been achieved, though currently this requires, re-installing
with the Net (DVD may be installation CD) release avoiding Live CD; and
bototing the install with "brokenmodules=pata_pdc202xx_old".
So though you may not have had satisfaction of making kernel patches, this has
been useful. Now it appears this issue has exposed a large problem for Sys
Admins in future trying to recover systems.
Alexander :
Having made initrd changes, I still cannot recover the Logical Volume, it
appears to try to access, then load md devices, when it decides to shutdown, so
apparently some driver load ordering problem may have been introduced.
The issue is, to recover a system, you boot from different media. But I cannot
rebuild the initrd's, to create them correctly thanks to the automatic stuff.
In past, I would even be able to boot with a different Linux OS, disk or
CD/DVD; then using chroot into the SuSE system area, I'd have a running system
that was fixable with it's own tools.
As I understand it, and have experimented, running mkinitrd on Live CD in
chroot of system partition, generates a lot of Live CD specific modules.
With the purely INITRD_MODULES dependant method, the Sys Admin could break
booting by a careless change to that, but I appear to have had booting broken
merely by adding a desired module, to remove an undersirable one from the same
system running with the correct modules.
If the Sys Admin had been using the old method of specific inclusion via
INITRD_MODULES, this would not have happened. My approach would be to leave
the old alone, cautiously build the new, test and only remove the old working
boot initrd once the new had proven itself.
Presumably the default 'minitrd' gets run by the kernel update procedures, so
any specially built initrd's for other kernels will be overwritten and possibly
cause similar boot issues?
This Bug actually seems far more serious, than the original pata_pdc202xx_old
driver problem, as with that, there was no way anyone would run the updated OS
on a production system.
Perhaps I have misunderstood and there is a way to manually over-ride and
control the building of initrd's on a machine.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.