Re: 2.6.8 stock kernel bug
From: Craig Bergren (cbergren_at_tvbox.bergren.us)
Date: 12/27/04
- Next message: Sergio Millich: "System doesn't mount 2nd cdrom drive"
- Previous message: Tim McCoy: "Re: CNet network card issue: DM9102AF (dmfe)"
- In reply to: Haines Brown: "Re: 2.6.8 stock kernel bug"
- Next in thread: Haines Brown: "Re: 2.6.8 stock kernel bug"
- Reply: Haines Brown: "Re: 2.6.8 stock kernel bug"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 27 Dec 2004 05:48:11 GMT
On Sun, 26 Dec 2004 20:02:53 +0000, Haines Brown wrote:
>
> I did find a great on-line resource, "Linux Kernel Configuration Archive"
> (http://kernel.xc.net), which characterizes each module that can be
> compiled into the kernel. Among the kernel modules in kernel 2.6.8, I have
> these characterizations listed:
>
> CD-ROM file system support (CONFIG_ISO9660_FS)
> ATA/ATAPI... support (CONFIG_IDE) Enhanced IDE
> (CONFIG_BLK_DEV_IDE) Include IDE/ATAPI CDROM
> support (CONFIG_BLK_DEV_IDECD) generic/default IDE chipset
> support (CONFIG_IDE_GENERIC)
>
> These are all tagged for compilation in a stock 2.6.8 kernel by default
> ("(m)"). The help files attached to these modules are very helpful in
> deciding whether they are required for mounting an IDE CDROM device. The
> resource is limited to 2.6.N modules.
>
>> As you stated, there was a bug with the release. The shipped initrd
>> didn't load the modules in the correct order. In most cases you can
>> unload a number of modules and then reload them. In this case, however,
>> we're talking about the ide driver that controls the disk where the
>> files are stored. It's probably possible, but probably beyond your
>> skill level right now.
>
> Not so sure, for you apparently assume I'm also using a IDE hard disk, but
> I'm not. The CDROM is the only IDE device I'm using, so the modules at
> found a SCSI disk, and so I gather I can possibly unload and reload the
> IDE modules in a better order. The question is, do I do that with a
> boot-time script. The modules.conf seems like it is suited to an initial
> ordering of loadable modules.
>
It was the quoted bit in your OP that fooled me. I assumed you were using
SATA because of the quotation. You need to remove all the modules from
ata_piix on up. Then you can load ide-generic first.
rmmod - removes
modprobe or insmod - adds
I would do it by hand until I got it working, then make the modules.conf
file reflect what I did by hand. Then use "above", "below" and/or
"probeall" options in modules.conf to ensure the modules load in the
correct order.
>
>
> My IDE cdrom drive is seen, but no entry for hdc: at all.
>
>> grub creates a RAM disk containing the file system image contained in
>> initrd.img. The initrd.img file is a compressed ext2 files system. You
>> can unzip it to a file and mount it with a loopback device in order to
>> see what's in it.
>
> Naturally, I ventured down this road, but I ran into a problem:
>
>> $ gzcat initrd-2.6.8-1-386.img > initrd.img $ mount -o loop -t ext2
>> initrd.img /mnt/initrd
>
> # zcat initrd-2.6.8* > initrd.img
> bash: initrd.img: Permission denied
>
> This is root trying to run a command on a file owned by user/root, and I
> don't know what it is about the file that denies permission. Oh well
> :-(.
After you revealed that you are using SCSI, I don't think this is your
problem. Hmmm? I just tried this on a FC3 system and it looks like the
initrd image isn't a gzipped ext2 file system anymore, but a gzipped cpio
file.
So try this instead:
$ mkdir initrd
$ cd initrd
$ gunzip -c /boot/initrd-2.6.8-1-386.img | cpio -ic
>
> Interesting. If mkinitrd finds that I'm not using an IDE hard disk, then
> it apparently will have no IDE drivers. I'll struggle to pry into
> initrd.img to see if that is so. My primary disk controller is a scsi
> adapter, and so I gather should see only a scsi module and a reiserfs
> module, but not much else.
Yes. Mine has ext3 and jbd, the ide drivers are compiled into my kernel.
>
> But if initrd can access my hard disk, and
> that's all it needs to do, then evidently the order in which modules are
> loaded does not concern it, and it is the init later during the boot
> that gets things wrong.
Remember, initrd is just a file system that is loaded into RAM when the
system boots. Here's what gets executed on my system, "nash" is a shell
that has built-in commands for "mount", "insmod", "mkrootdev", ...
#!/bin/nash
mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs none /sys
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
umount /sys
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc
- Next message: Sergio Millich: "System doesn't mount 2nd cdrom drive"
- Previous message: Tim McCoy: "Re: CNet network card issue: DM9102AF (dmfe)"
- In reply to: Haines Brown: "Re: 2.6.8 stock kernel bug"
- Next in thread: Haines Brown: "Re: 2.6.8 stock kernel bug"
- Reply: Haines Brown: "Re: 2.6.8 stock kernel bug"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
