You are not logged in.

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

phydeaux
Member
Registered: 2005-06-13
Posts: 68

Re: INITRD - share your woes

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

Offline

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

apeiro
Daddy
From: Victoria, BC, Canada
Registered: 2002-08-12
Posts: 771
Website

Re: INITRD - share your woes

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.

Offline

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

kth5
Member
Registered: 2004-04-29
Posts: 657
Website

Re: INITRD - share your woes

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. smile

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?


I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell

Offline

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

lessthanjake
Member
From: Norway
Registered: 2005-11-09
Posts: 319
Website

Re: INITRD - share your woes

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

Offline

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

mouse256
Member
From: Antwerpen, Belgium
Registered: 2005-08-24
Posts: 247

Re: INITRD - share your woes

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

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 sad

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?

Offline

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

tpowa
Developer
From: Lauingen , Germany
Registered: 2004-04-05
Posts: 2,322

Re: INITRD - share your woes

this should be fixed in new mkintrd that is launched soon

Offline

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

apeiro
Daddy
From: Victoria, BC, Canada
Registered: 2002-08-12
Posts: 771
Website

Re: INITRD - share your woes

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 sad

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.

Offline

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

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Re: INITRD - share your woes

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.

Offline

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

mouse256
Member
From: Antwerpen, Belgium
Registered: 2005-08-24
Posts: 247

Re: INITRD - share your woes

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.

Offline

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

kozaki
Member
From: London >. < Paris
Registered: 2005-06-13
Posts: 671
Website

Re: INITRD - share your woes

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


Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery smile) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9

Offline

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

tpowa
Developer
From: Lauingen , Germany
Registered: 2004-04-05
Posts: 2,322

Re: INITRD - share your woes

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.

Offline

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

Gullible Jones
Member
Registered: 2004-12-29
Posts: 4,863

Re: INITRD - share your woes

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...)

Offline

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

Moo-Crumpus
Member
From: Hessen / Germany
Registered: 2003-12-01
Posts: 1,487

Re: INITRD - share your woes

phrakture wrote:

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

xfs, jfs


Frumpus addict
[mu'.krum.pus], [frum.pus]

Offline

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

tpowa
Developer
From: Lauingen , Germany
Registered: 2004-04-05
Posts: 2,322

Re: INITRD - share your woes

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

Offline

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

Theoden
Member
Registered: 2005-03-03
Posts: 240

Re: INITRD - share your woes

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)


"If builders built buildings the way programmers write programs,
the first woodpecker that came along would destroy civilization."

Offline

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

apeiro
Daddy
From: Victoria, BC, Canada
Registered: 2002-08-12
Posts: 771
Website

Re: INITRD - share your woes

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.  smile

Offline

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

aCoder
Member
From: Medina, OH
Registered: 2004-03-07
Posts: 359
Website

Re: INITRD - share your woes

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.


If you develop an ear for sounds that are musical it is like developing an ego. You begin to refuse sounds that are not musical and that way cut yourself off from a good deal of experience.
  - John Cage

Offline

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

apeiro
Daddy
From: Victoria, BC, Canada
Registered: 2002-08-12
Posts: 771
Website

Re: INITRD - share your woes

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

Offline

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

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: INITRD - share your woes

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.

Offline

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

aCoder
Member
From: Medina, OH
Registered: 2004-03-07
Posts: 359
Website

Re: INITRD - share your woes

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.


If you develop an ear for sounds that are musical it is like developing an ego. You begin to refuse sounds that are not musical and that way cut yourself off from a good deal of experience.
  - John Cage

Offline

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

kozaki
Member
From: London >. < Paris
Registered: 2005-06-13
Posts: 671
Website

Re: INITRD - share your woes

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.


Seeded last month: Arch 50 gig, derivatives 1 gig
Desktop @3.3GHz 8 gig RAM, linux-ck
laptop #1 Atom 2 gig RAM, Arch linux stock i686 (6H w/ 6yrs old battery smile) #2: ARM Tegra K1, 4 gig RAM, ChrOS
Atom Z520 2 gig RAM, OMV (Debian 7) kernel 3.16 bpo on SDHC | PGP Key: 0xFF0157D9

Offline

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

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: INITRD - share your woes

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.

Offline

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

Mr Green
Forum Fellow
From: U.K.
Registered: 2003-12-21
Posts: 5,893
Website

Re: INITRD - share your woes

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? ..


Mr Green

Offline

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

Bysshe
Member
Registered: 2004-12-10
Posts: 271

Re: INITRD - share your woes

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.

Offline

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

apeiro
Daddy
From: Victoria, BC, Canada
Registered: 2002-08-12
Posts: 771
Website

Re: INITRD - share your woes

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

Offline

Board footer

Powered by FluxBB