INITRD - share your woes

phydeaux · 2005-12-07 21:05:57

apeiro wrote:

Hi Andy,
Strange. You'd think that it would pick the same order each time, even if it was the wrong order. It sounds like you've already done the correct thing here, which is to manually add the necessary IDE modules (in your desired order) to the HOSTCONTROLLER_IDE variable in mkinitrd.conf.
Is that what you did, or did you find a solution elsewhere?

Yes, I'm assuming thats what fixed it. Once I added this line, HOSTCONTROLLER_IDE="via82cxxx cmd64x", to mkinitrd.conf it started working the way I feel it should. I guess it was just the order the modules were loaded by default in linuxrc. Previous to that I had been editing linuxrc to make the proper device nodes so it could mount hdg3 as root.

andy

apeiro · 2005-12-07 21:28:07

lessthanjake wrote:

Now I have run with initrd for a week, and it is aperantly working fine, but I get this eror during boot up.
Dec  7 18:31:19 arch RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Dec  7 18:31:19 arch RAMDISK: Compressed image found at block 0
Dec  7 18:31:19 arch RAMDISK: incomplete write (-28 != 32768) 4194304

Ah yes. We use a rather large default initrd size (16MB) to accomodate all the modules as well as statically-linked utilities (mdadm, cryptsetup). The memory isn't "wasted" after boot-up though, since we free it as soon as we pivot to the real system.

As of mkinitrd-1.01-19, I have added a sanity check to make sure the kernel's ramdisk size is big enough to hold our initrd. If you are using a custom kernel and want to use an initrd, make sure you configure the ramdisk size to be 16384 (16MB) or larger.

Please note that if you ARE using a custom kernel, there's no reason that you must also use the initrd. We use the initrd in the stock kernel because it makes it easier to accomodate the many different requirements Arch users have. But if you're tailoring a kernel specific to you, why not just build in the drivers you require and leave the initrd business out of it?

My 2.5 cents CDN.

kth5 · 2005-12-08 05:08:36

lessthanjake wrote:

-rw-r--r--  1 root root 516K 2005-12-07 18:17 initrd26.img
but the same message? I am no kernel expert, so maybe its just a silly mistake, but I find i wierd?

this doesn't mean anything. this file is gzip-compressed and its contents are always 16384K large which is the value the kernel cares about. it actually decompresses the gzipped-image into an preallocated space in memory and if that's too small... well, ya know what happens.

anyway, that's why initramfs (cpio) probably perfoms better here. it apparently has proper meta data in its headers the kernel can read. gzip is only a stream, isn't it?

lessthanjake · 2005-12-08 07:50:09

Thanks, no I got it Did not know it was gziped!

mouse256 · 2005-12-09 13:32:08

I'm using it now too, but it took my a while

I switched from booting from a single PATA disk to software RAID0 on SATA, so it wasn't that easy...

The biggest problem I had was the following:
/boot/grub/menu.lst

# (0) Arch Linux
title  Arch Linux
root   (hd0,2)
kernel /vmlinuz26 root=/dev/md0 ro vga=795
initrd /initrd26_2.img

whatever you select as root= on the kernel line seems to be ignored, the systems uses the root in the initrd image. It took me very long to find that out

Also my usbstick and external firewire hdd are not automounted anymore, I think this is because hotplug isn't available anymore. Any possibility to make this work again?

tpowa · 2005-12-09 18:51:07

this should be fixed in new mkintrd that is launched soon

apeiro · 2005-12-09 20:27:09

mouse256 wrote:

whatever you select as root= on the kernel line seems to be ignored, the systems uses the root in the initrd image. It took me very long to find that out

The latest mkinitrd package uses the root= passed on the kernel boot line. You are correct, though -- earlier versions had it hardcoded at generation-time.

Also my usbstick and external firewire hdd are not automounted anymore, I think this is because hotplug isn't available anymore. Any possibility to make this work again?

Hmmm, seems to work fine here. Do you see the block devices in /dev for your firewire drive when you boot up? Are the correct firewire modules loaded? If you're using hwdetect or hwd, they should find the FW modules for you.

Gullible Jones · 2005-12-10 04:58:26

Okay guys, minor new problem here: the AUTODETECT option in mkinitrd.conf no longer does anything at all when set to "1". With the last version of mkinitrd, it worked perfectly, putting only the modules for my filesystem type, etc. in the initrd. Now it puts in exactly the same modules as if it AUTODETECT were turned off.

mouse256 · 2005-12-10 10:31:48

apeiro wrote:

Also my usbstick and external firewire hdd are not automounted anymore, I think this is because hotplug isn't available anymore. Any possibility to make this work again?
Hmmm, seems to work fine here. Do you see the block devices in /dev for your firewire drive when you boot up? Are the correct firewire modules loaded? If you're using hwdetect or hwd, they should find the FW modules for you.

I can use my devices (when I type "mount /dev/hdc /mnt/somewhere")
But when I was using hotplug gnome did this for my. It also gave it an icon to see what kind of device it was (so an usb icon when the disk was connected through usb, a firefire icon when connnected through firewire), This does not work anymore.
Gnome needs hald for this, and hald is still running.

kozaki · 2005-12-10 11:05:37

initrd workin fine since I updaded the machines to kernel-2.6.14 (There are 3 different kinds : Toshiba laptop Portégé 7200 Series with PIII Coppermine, a few Dell Desktops sith PIII Coppermine & a Desktop PC with Asrock Dual Sata mobo, Sata HDD & AMD 64 3200 E3)

Something I found a bit weird is that if i disable cdrom (with REMOVE_CDROM=1) in mkinitrd.conf , then no optical devices will show up in /dev. But wiki says one can enable only what's needed to boot the kernel up ?

Also, it works fine with :

# hwdetect :
#MOD_AUTOLOAD="yes"
#MOD_BLACKLIST=()
# is now only needed for modules that are not detected by hwdetect.
#
MODULES=(!usbserial !ide-scsi sata_uli uli526x)

But boot process hang up systematically with :

MOD_AUTOLOAD="yes"
MOD_BLACKLIST=()
# is now only needed for modules that are not detected by hwdetect.
#
MODULES=(!usbserial !ide-scsi !sata_uli !uli526x)

Despite those 2 modules are detected by hwdetect :?:

# hwdetect --show-modules :

AGP : agpgart ali-agp amd64-agp
IDE : ide-cd ide-core alim15x3 generic
SCSI : sd_mod
SATA : libata sata_uli
USB : usb-storage usblp usbhid usbcore ehci-hcd ohci-hcd
NET : ppp_generic slhc uli526x
SOUND : snd-mixer-oss snd-pcm-oss snd-page-alloc snd-timer snd snd-ac97-bus snd-ac97-codec snd-intel8x0 soundcore
VIDEO : btcx-risc bttv tveeprom v4l2-common video-buf videodev nvidia
OTHER : cdrom rtc i2c-algo-bit i2c-ali1535 i2c-ali1563 i2c-ali15x3 i2c-core evdev pcspkr serio_raw bt878 pci_hotplug shpchp

tpowa · 2005-12-10 11:45:20

kozaki please try to use latest hwdetct from cvs it's in initscripts, it has a fix for ppl with sata devices that might stop you from using hwdetect.

Gullible Jones · 2005-12-10 19:25:16

Ahh... Update to my problem: AUTODETECT=1 detects the motherboard stuff fine. It just can't seem to figure out that I'm using ReiserFS on all my partitions.

(Yeah, I had to switch back from ext3. I still feel that a lot more effort should be dumped into that FS, but pacman really, really does not like it - I was having to do pacman-optimize every few days. :shock: But I digress...)

Moo-Crumpus · 2005-12-11 18:26:29

phrakture wrote:

Just a quick check - those of you with unbootable systems due to the initrd, what is your root fs type?

xfs, jfs

tpowa · 2005-12-11 20:25:04

new mkinitrd checks the filesystem on the fly so VFS errors should be history

Theoden · 2005-12-12 20:07:38

apeiro, tpowa, et. al.:

Just some feedback to let you all know that with the help of phrakture, I finally have this issue resolved.

Apparently, my ide driver ... piix - was not being built as a module - and thus hwdetect --ide returned nothing, and modalias was not seeing the controller at all. Thus the new kernel with mkinitrd in use failed to boot.

However, the latest kernel and mkinitrd in testing solved the problem after a bit of detective work with phrakture. Thanks phrakture!

Anyway, just wanted to say thanks to all, and apologize if I've been a PITA on this one. Hope this report helps others to try the latest.

--Theoden 8)

apeiro · 2005-12-12 20:25:44

Theoden wrote:

However, the latest kernel and mkinitrd in testing solved the problem after a bit of detective work with phrakture. Thanks phrakture!

Ah, wonderful. Another bug bites the dust.

aCoder · 2005-12-13 18:51:09

I'd just like to let everyone know that I've just upgraded to the latest pkgs from testing, coming from a very old installation, and after just adding the appropriate line to my menu.lst, everything's gone just fine.

My only 'issue' is that it seems that the kernel takes a bit longer to boot, but ditching hotplug for hwdetect certainly makes up for it.

apeiro · 2005-12-13 19:06:35

Good to hear. It's nice to balance out the bug stories with the success stories.

phrakture · 2005-12-13 20:55:57

aCoder wrote:

My only 'issue' is that it seems that the kernel takes a bit longer to boot, but ditching hotplug for hwdetect certainly makes up for it.

Did you try making a custom initrd? That should fix some of the speed issues.

aCoder · 2005-12-14 02:09:43

Did you try making a custom initrd? That should fix some of the speed issues.

I figured as much, but haven't got around to it.

kozaki · 2005-12-14 11:28:41

tpowa wrote:

kozaki please try to use latest hwdetct from cvs it's in initscripts, it has a fix for ppl with sata devices that might stop you from using hwdetect.

Dunno for sure if that what you advised me to do : built initscripts from abs (Dec 12) then pacman -U it.
Now boot process still hangs up as soon as i use :

MOD_AUTOLOAD="yes"
MOD_BLACKLIST=()
# is now only needed for modules that are not detected by hwdetect.
#
MODULES=(!usbserial !ide-scsi !sata_uli !uli526x)

Uncommenting the 2 last modules doesn't help.

phrakture · 2005-12-14 16:16:10

aCoder wrote:

Did you try making a custom initrd? That should fix some of the speed issues.
I figured as much, but haven't got around to it.

The point being that the full image loads every module that used to be part of the kernel - it's a shade slower, just because it needs to call modprobe numerous times (though a "modprobe -a" would be slightly faster).

Making a custom initrd removes all the extra modules that your hardware doesn't need. My custom initrd loads 3 (to 5, can't recall) modules on boot and takes no time at all.

Mr Green · 2005-12-14 16:59:13

Making a custom initrd removes all the extra modules that your hardware doesn't need. My custom initrd loads 3 (to 5, can't recall) modules on boot and takes no time at all.

So why use it at all ?

what are the benefits to the user? ..

Bysshe · 2005-12-17 06:35:39

Okay, I upgraded to the testing kernel, so I'm curious about the kernel26-scsi having to be removed. More than anything, the error at the bottom. I believe I force-upgraded to the testing kernel. Went today for a pacman -Syu and got the following:

Remove:  kernel26-scsi

Targets: mkinitrd-1.01-24 kernel26-2.6.14.3-2 e2fsprogs-1.38-2
         filesystem-0.7.1-4 initscripts-0.7.1-16 less-394-1 man-pages-2.17-1
         module-init-tools-3.2.2-1 nss-mdns-0.7-2 openldap-2.2.30-1
         rp-pppoe-3.7-2

Total Package Size:   26.8 MB

Proceed with upgrade? [Y/n] Y

****************(watch packages download)*****************

checking package integrity... done.
removing kernel26-scsi... 
warning: /boot/kconfig26 saved as /boot/kconfig26.pacsave
done.
loading package data... done.
checking for file conflicts... 
error: the following file conflicts were found:
  kernel26: /boot/initrd26-full.img: exists in filesystem
  kernel26: /lib/modules/2.6.14-ARCH/modules.ofmap: exists in filesystem


errors occurred, no packages were upgraded.

I was thinking along the lines of force-upgrading again, but I don't want to dig myself deeper, because I'm not clear on what's going on here.

apeiro · 2005-12-17 08:33:29

Both conflicts are fine. The initrd26-full conflict exists because we now package a fallback initrd in the kernel package itself.

The second file is also safe to overwrite. -Syuf

Arch Linux

#26 2005-12-07 21:05:57

Re: INITRD - share your woes

#27 2005-12-07 21:28:07

Re: INITRD - share your woes

#28 2005-12-08 05:08:36

Re: INITRD - share your woes

#29 2005-12-08 07:50:09

Re: INITRD - share your woes

#30 2005-12-09 13:32:08

Re: INITRD - share your woes

#31 2005-12-09 18:51:07

Re: INITRD - share your woes

#32 2005-12-09 20:27:09

Re: INITRD - share your woes

#33 2005-12-10 04:58:26

Re: INITRD - share your woes

#34 2005-12-10 10:31:48

Re: INITRD - share your woes

#35 2005-12-10 11:05:37

Re: INITRD - share your woes

#36 2005-12-10 11:45:20

Re: INITRD - share your woes

#37 2005-12-10 19:25:16

Re: INITRD - share your woes

#38 2005-12-11 18:26:29

Re: INITRD - share your woes

#39 2005-12-11 20:25:04

Re: INITRD - share your woes

#40 2005-12-12 20:07:38

Re: INITRD - share your woes

#41 2005-12-12 20:25:44

Re: INITRD - share your woes

#42 2005-12-13 18:51:09

Re: INITRD - share your woes

#43 2005-12-13 19:06:35

Re: INITRD - share your woes

#44 2005-12-13 20:55:57

Re: INITRD - share your woes

#45 2005-12-14 02:09:43

Re: INITRD - share your woes

#46 2005-12-14 11:28:41

Re: INITRD - share your woes

#47 2005-12-14 16:16:10

Re: INITRD - share your woes

#48 2005-12-14 16:59:13

Re: INITRD - share your woes

#49 2005-12-17 06:35:39

Re: INITRD - share your woes

#50 2005-12-17 08:33:29

Re: INITRD - share your woes

Board footer