mkinitramfs doesn't include new pata drivers that switched from ide

[Eungkyu Song]

Ubuntu kernel 2.6.19-x stops working and becomes idles during boot after usb related messages. It's not an oops message but a normal boot up message. I waited over six hours but it doesn't progress any more.

But I don't know the real problem or the way to take any dumps or logs. Alt+sysrq+t works but it scrolls over the limit of shift+pageup and I can't read all the message. Alt+sysrq+c seems not to work.

What can I do for helping fix this bug?

[Eungkyu Song (eungkyu)]

Finally, I got a busybox shell.

Here's my lshw result.

[Ben Collins (ben-collins)]

More interested in dmesg output.

Thanks

[Eungkyu Song (eungkyu)]

I'm sorry that I pumped up the problem.

I waited more than 6 hours because I fell a sleep.
I tried to find out the problem again and I got it.

I found that CONFIG_BLK_DEV_VIA82CXXX is not set in the kernel configuration.
I'm using VIA VT6410 and need it.

That's the problem.

[Ben Collins (ben-collins)]

Ah, that's because it was replaced by a PATA driver. I suspect that you did a clean install of edgy?

What you need to do is edit /boot/grub/menu.lst, find the line containing kopt_2_6 and delete that line.

Then run "sudo update-grub". Rebooting to 2.6.19 should work then.

There's already a bug filed on the installer about this, so if this fixes your problem, great. If it doesn't please set the bug status to confirmed.

[Eungkyu Song (eungkyu)]

My system is cleanly installed from edgy (of course, now feisty)
and /boot/grub/menu.lst doesn't have kopt_2_6 line.

Is via82cxxx already replaced by PATA driver in linux 2.6.17-10-generic? My system uses via82cxxx module for my ide controller at linux 2.6.17-10-generic. Is this situation intended?

I'll set this bug confirmed.

[Eungkyu Song (eungkyu)]

It's not caused by replacement of via82cxxx driver.

[Ben Collins (ben-collins)]

It's very likely you have the pata driver blacklisted.

sudo rm -f /etc/modprobe.d/blacklist-pata
sudo update-initramfs -u

That should resolve it.

Also, please let the maintainers handle confirmed or not. You haven't confirmed anything other than assumptions.

[Eungkyu Song (eungkyu)]

I'm sorry.

> If it doesn't please set the bug status to confirmed
I misunderstand that it meant you allowed me.

I'll test further and report soon.

[Ben Collins (ben-collins)]

Sorry about that, I really need to read my previous comments before commenting again :)

Please test the blacklist-pata fix. I'm hoping this takes care of your problem.

[Eungkyu Song (eungkyu)]

I have two computers running ubuntu feisty. The one is suffering this bug and another is suffering dri related bug :(

I found that both have via ide controller and the one is working and another is not working.

The working controller is
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

And the not working controller is
02:04.0 RAID bus controller: VIA Technologies, Inc. VT6410 ATA133 RAID controller (rev 06)

Both controllers need via82cxxx or pata_via module to work perfectly. (at least I guess)

I found the more important thing that /boot/initrd.img-2.6.19-6-generic doesn't have neither of these modules. (I regenerated it after deleting blacklist-pata and confirmed by unpacking)

The working one is not running via libata driver because it's device file is /dev/hda. It's running via "ide_generic" or "generic" module.
The not working one must be not detected by this generic ide module.

Lastly, my opinion is that migrating to pata driver is not flawless and initrd image need to include pata modules.

Is it right?

[Eungkyu Song (eungkyu)]

Finally, I succeed to boot all my computers and perfectly enabled all ide controllers by adding pata_via and pata_mpiix line to /etc/initramfs-tools/modules.

I think some fixes should be applied so that initrd image contains pata related modules by default.

Thanks for helping me.

[Ben Collins (ben-collins)]

Thanks for confirming. I think the issue is that update-initrd usually checks for modules that are already loaded. I'd be willing to bet that if you removed the listing for them from /etc/initramfs/modules, it would continue to work after that since the module is now loaded.

This is sort of a chicken and egg problem that is probably best handled in initramfs-tools.

[Tormod Volden (tormodvolden)]

Ben, regarding that bet, you'd loose :) I had pata_via loaded when I ran update-initramfs -u (this time upgrading from .19-6-7 to .19-6-9) and it didn't put pata_via into the initrd. I had to add it to /etc/initramfs/modules again. My /etc/initramfs-tools/initramfs.conf has the default "most".

/usr/share/initramfs-tools/hook-functions defines what modules go in, and it lists all the sata- modules (for "scsi") but no pata-modules.

[Ben Collins (ben-collins)]

On Tue, 2006-11-21 at 17:57 +0000, Tormod Volden wrote:
> Ben, regarding that bet, you'd loose :) I had pata_via loaded when I ran
> update-initramfs -u (this time upgrading from .19-6-7 to .19-6-9) and it
> didn't put pata_via into the initrd. I had to add it to
> /etc/initramfs/modules again. My /etc/initramfs-tools/initramfs.conf has
> the default "most".
>
> /usr/share/initramfs-tools/hook-functions defines what modules go in,
> and it lists all the sata- modules (for "scsi") but no pata-modules.

Ah, you're right. I'm a little concerned that it doesn't use lsmod to
decide to grab more.

Guess we'll see a lot of this until it's fixed in initramfs-tools.