new initramfs, testers welcome

iphitus · 2006-05-18 00:27:38

kernel modules are practically bound to the kernel they are compiled for, and thus, each kernel must have it's own image. Copying the image for the others will not work. btw, ArchCK is dead and long gone, so feel free to remove it. It will no longer be updated.

James

phrakture · 2006-05-18 03:17:38

brain0 wrote:

append="root=/dev/hdXY"
@phrakture: Even if we fix this in mkinitcpio, there would be much less problems if we recommended using this lilo.conf syntax. For grub this isn't an issue anyway.

brain0: Agreed.

lilsirecho: can you try:

append="root=/dev/hdXY rootfstype=ext3"

lilsirecho · 2006-05-18 04:20:56

Loaded lilo as below:
#
# /etc/lilo.conf
#

boot=/dev/hda
# This line often fixes L40 errors on bootup
# disk=/dev/hda bios=0x80

default=arch
timeout=50
lba32
prompt

image=/boot/vmlinuz26
label=arch
root=/dev/hda3
initrd=/boot/initrd26-full.img
read-only
image=/boot/vmlinuz26archck
label=archck
root=/dev/hda3
initrd=/boot/initramfs-2.6.15-archck.img
read-only
image=/boot/vmlinuz26beyond
label=2.6.16-beyond
root=/dev/hda3
initrd=/boot/initramfs-beyond.img
read-only
image=/boot/vmlinuz26beyond
label=cpio
initrd=/boot/ray.img
append="root=/dev/hda3 rootfstype=ext3"
read-only
image=/boot/vmlinuz26archck
label=cpio1
root=/dev/hda3
initrd=/boot/ray.img
read-only
#other=/dev/hda1
# label=dos

Modified Hooks in mkinitcpio to include autodetect priot to ide.

Ran /sbin/lilo .....

Rebooted and received kernel panic:
==================================================================
:: Loading Intramfs
:: Running Hook (udev)
:: Loading udev....done
:: Running Hook [usb]
:: Running Hook [Filesystems]
:: Loading root filesystem module ...ext3
:: Intramfs completed control passing to kinit

kinit : do mounts
--
-- These are the same as before

Kernel panic - not syncing: attempted to kill init!

--
--
--

Cerebral · 2006-05-18 14:06:51

Allrighty, I just installed it here and gave it a shot with both beyond and ARCH kernels. Seems to work fine, but I've got a fairly bland setup - ext3 root filesystem, whoopee!

One thing I noticed during boot, though, was that I get this message:

kinit: trying to mount /dev/root on /root with type ext2
EXT2-fs warning (device hda3): ext2_fill_super: warning: mounting ext3 filesystem as ext2

Do I need to worry about this?

FYI, my mkinitcpio.conf:

MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev autodetect ide filesystems"

-edit-
I guess it's not much of a problem; when / gets remounted during init it remounts it correctly:

$ mount
/dev/hda3 on / type ext3 (rw)

brain0 · 2006-05-18 15:25:52

You bootloader section for this kernel please

Cerebral · 2006-05-18 15:47:22

Hm? Yeah, sure:

# (1) Arch Linux -Beyond patchset
title  Arch Linux Beyond [/boot/vmlinuz26beyond] w cpio
root   (hd0,0)
kernel /vmlinuz26beyond root=/dev/hda3 ro devfs=nomount video=vesafb:1280x1024-16@75
initrd /cpio-beyond.img

# (3) Arch Linux
title  Arch Linux  [/boot/vmlinuz26] w cpio
root   (hd0,0)
kernel /vmlinuz26 root=/dev/hda3 ro devfs=nomount vga=0x305
initrd /cpio-ARCH.img

I get the same message in both kernels. I'll try adding rootfstype=ext3 as you suggested for lilsirecho in a moment and report back with the results.

-edit- as expected, rootfstype=ext3 gives kinit the clue it needs to mount it without any problems.

lilsirecho · 2006-05-18 16:32:19

Modified my lilo to include an arch kernel application ofthe mkinitcpio system.

image=/boot/vmlinuz26
label=cpio2
append="root=dev/hda3 roofstype=ext3"
initrd=/boot/rays.img
read-only

Ran in arch ....mkinitrd -g /boot/rays.img

Ran... /sbin/lilo -v

Rebooted with no problem....arch 0.7.2 GIMMICK was referred to in the boot process.

What indicator can be used to verify the mkinitcpio system is in operation?

phrakture · 2006-05-18 16:54:01

Cerebral wrote:

I get the same message in both kernels. I'll try adding rootfstype=ext3 as you suggested for lilsirecho in a moment and report back with the results.
-edit- as expected, rootfstype=ext3 gives kinit the clue it needs to mount it without any problems.

Yeah, I sent a message to the klibc ML - I'm fairly noobish about filesystem differences, but I have a feeling ext3 should be attempted before ext2.

One question - what output does the filesystem hook give you... it should be akin to:
:: Detecting root filesystem....ext3
Or something. The autodetection of the fs should override kinit's crappy fs handling (it actually iterates over all filesystesm in /proc/filesystems and tries to mount it... it's possible that ext2 just appears before ext3 and is sorta-succeeds).

lilsirecho wrote:

Rebooted with no problem....arch 0.7.2 GIMMICK was referred to in the boot process.

Hooray! That's a good sign. Can you try without the rootfstype, just so I know which parameter fixes it?

lilsirecho wrote:

What indicator can be used to verify the mkinitcpio system is in operation?

If the system boots, it works. Early-userspace is only there to get the root filesystem up and running, then it passes control over to the normal arch boot process. The 0.7.2 message is part of the normal arch boot process.

Cerebral · 2006-05-18 17:14:54

phrakture wrote:

One question - what output does the filesystem hook give you... it should be akin to:
:: Detecting root filesystem....ext3

Yeah, says :: Loading root filesystem module... ext3

phrakture wrote:

lilsirecho wrote:
Rebooted with no problem....arch 0.7.2 GIMMICK was referred to in the boot process.
Hooray! That's a good sign. Can you try without the rootfstype, just so I know which parameter fixes it?

In all seriousness, I think it failed before because he built the images with all the same modules - he was using one image for all kernels. Now he built an initramfs with ARCH modules, and booted the ARCH kernel with it, so it worked.

lilsirecho · 2006-05-18 17:15:18

Changed lilo to normal ....root=/dev/hda3...re-booted with no problem in the arch kernel mkinitcpio.. Works with either lilo setups in arch kernel.

Still have to solve the problem for beyond kernel.

phrakture · 2006-05-18 17:28:31

Cerebral wrote:

phrakture wrote:
One question - what output does the filesystem hook give you... it should be akin to:
:: Detecting root filesystem....ext3
Yeah, says :: Loading root filesystem module... ext3

Odd. I thought I had circumvented the kinit fs detection if it was properly detected. Response from the ML was that yes, ext3 should be detected first, so expect a fix for that (if I get bored, I'll fix it myself).

I guess this means I need to fix the rootfstype param passing, as if the filesystems hook detected things right, kinit shouldn't "try" mounting anything. It should just mount it assuming rootfstype is correct.

/me writes that one down for future reference

lilsirecho · 2006-05-18 17:32:32

Re-tried beyond kernel after booting into beyond. Removed...ray.img from... /boot file...entered append="root=/dev/hda3 roofstype=ext3"...in lilo...ran.../sbin/lilo -v....

Ran mkinitcpio -g /boot/ray.img.....

Re-booted into ....cpio ... Received kernel panic..

phrakture · 2006-05-18 17:37:07

lilsirecho:
when you generate an image for a different kernel than the one you are running, you need to use the -k option for mkinitcpio:

mkinitcpio -k 2.6.16-beyond -g /boot/beyond.img

You also need a different image for each kernel - they *are not* compatible between kernels.

In the future, a process like this wikk be automated, but for now, you need to regenerate the image for each kernel and on any version-changing kernel upgrade (2.6.17 when it's out).

lilsirecho · 2006-05-18 17:46:28

Phrakture;

As reported, I ran beyond kernel and made the.... mkiniitcpio -g /boot/ray.img...while in the beyond kernel system boot-up.

Kernel panic resulted.

Cerebral · 2006-05-18 18:10:41

phrakture wrote:

Odd. I thought I had circumvented the kinit fs detection if it was properly detected. Response from the ML was that yes, ext3 should be detected first, so expect a fix for that (if I get bored, I'll fix it myself).
I guess this means I need to fix the rootfstype param passing, as if the filesystems hook detected things right, kinit shouldn't "try" mounting anything. It should just mount it assuming rootfstype is correct.
/me writes that one down for future reference

Yeah, just for kicks I tested it with and without the rootfstype on the kernel line - in either case, the filesystems hook detects my root fs properly, but without the rootfstype kernel param kinit still tries to mount ext2.

brain0 · 2006-05-18 18:53:27

I suspect that in Cerebral's case loading the filesystem module fails for some reason and mounting falls back to ext2 (which is compiled into the kernel atm).

The filesystem module should be autoloaded on trying to mount anyway (the kernel does this afaik). So we should try this:
We do not reset the modprobe command to "/sbin/modprobe" in $INITRAMFS/init, instead we do this in $REALROOT/etc/rc.sysinit. From what I understand, the filesystem module should be loaded automatically when kinit tries to mount and we don't even need to detect the filesystem in our init script.

tomk · 2006-05-18 19:02:09

The following is not a problem i.e. everything works, but it's another variation on kinit's "let's try every fs we can find until something works" approach.

The kernel is a custom beyond build. mkinitcpio.conf is

MODULES=""
BINARIES=""
FILES=""
HOOKS="base udev autodetect ide filesystems resume"

mkinitcpio -M gives

Modules autodetected:
cdrom
ide-cd
ide-core
ide-disk
generic
piix
usbcore
uhci-hcd
bluetooth
iso9660
ufs
reiserfs
ext2

The fs modules included in the resulting image are ext2 and reiserfs.

Relevant boot messages are:

kinit: trying to mount /dev/root on /root with type iso9660
kinit: trying to mount /dev/root on /root with type ufs
kinit: trying to mount /dev/root on /root with type reiserfs

reiser being the correct one.

phrakture · 2006-05-18 19:17:47

Ok, the filesystem hook was supposed to take care of this (that's actually the point of it). Obviously, it's broken. I'll take a look at it later on today.

I have to laugh at the iso9660 inclusion though. Autodetecting filesystems is hard, so mkinitcpio simply scans all mounted partitions, and includes them - it seems you had your cdrom mounted (or possibly an iso image) when you built this. He he he.

edit: quick check of the filesystems hook - somehow the rootfstype stuff got removed. I will fix this later and release a new version tonight - when this updates, Cerebral/TomK let me know if this fixes your issue

tomk · 2006-05-18 19:55:21

phrakture wrote:

I have to laugh at the iso9660 inclusion though. Autodetecting filesystems is hard, so mkinitcpio simply scans all mounted partitions, and includes them - it seems you had your cdrom mounted (or possibly an iso image) when you built this.

Not so, actually - nothing relevant was mounted. This particular kernel has iso9660 (and ufs) support built-in, so I suppose that has something to do with it.

phrakture · 2006-05-18 19:58:17

tomk wrote:

Not so, actually - nothing relevant was mounted. This particular kernel has iso9660 (and ufs) support built-in, so I suppose that has something to do with it.

Interesting. In an effort to improve autodetection of filesystems, can you post the contents of /proc/filesystems?
Currently, autodetection removes the "nodev" entries and uses the ones which are indicated as having a device. Perhaps builtin filesystems are listed differently... /shrug

tomk · 2006-05-18 21:20:24

Spot on, phrak - the built-ins are nodev, just like the modular ones:

$ cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   bdev
nodev   proc
nodev   binfmt_misc
nodev   sockfs
nodev   pipefs
nodev   futexfs
nodev   tmpfs
nodev   inotifyfs
nodev   eventpollfs
nodev   devpts
nodev   ramfs
              iso9660
nodev   nfs
nodev   nfs4
              ufs
nodev   mqueue
nodev   rpc_pipefs
              reiserfs
nodev   fuse
nodev   usbfs
              ext2

lilsirecho · 2006-05-19 03:43:20

Downloaded the latest klibc and udev modules.

Using the append= statement, the beyond kernel now boots correctly.

I will try it without the append and report back.
EDIT: The kernel boots OK with ....root=/dev/hda3......

Problem solved!

Thanks

tomk · 2006-05-19 07:56:35

phrakture wrote:

I will fix this later and release a new version tonight - when this updates, Cerebral/TomK let me know if this fixes your issue

Fixed for me, with klibc 1.3.22-3 and klibc-udev 092-3.

Thanks phrak.

lilsirecho · 2006-05-20 16:27:25

After update to beyond -4 kernel, booted to beyond and entered ....mkinitcpio -g /boot/ray.img...
The system then re-booted iwith the mkinitcpio system successfully.

MAC!EK · 2006-06-06 22:31:29

# /sbin/mkinitcpio -c /boot/mkinitcpio-kernel26.conf -k 2.6.17-rc6-ARCH -g /boot/kernel26-fallback.img
:: Begin build
:: Parsing hook [base]
:: Parsing hook [udev]
:: Parsing hook [ide]
:: Parsing hook [scsi]
:: Parsing hook [sata]
:: Parsing hook [usbinput]
:: Parsing hook [filesystems]
:: Parsing hook [keymap]
Naruszenie ochrony pamięci

"Naruszenie ochrony pamięci" == "Segmentation fault"
Whats wrong?

EDIT:
I run it again with -v:

......
......
:: Parsing hook [keymap]
  adding file /bin/loadkeys
  adding file /bin/dumpkeys
  adding file /bin/kdb_mode
  adding file /bin/setfont
  adding file /keymap
Naruszenie ochrony pamięci

Arch Linux

#101 2006-05-18 00:27:38

Re: new initramfs, testers welcome

#102 2006-05-18 03:17:38

Re: new initramfs, testers welcome

#103 2006-05-18 04:20:56

Re: new initramfs, testers welcome

#104 2006-05-18 14:06:51

Re: new initramfs, testers welcome

#105 2006-05-18 15:25:52

Re: new initramfs, testers welcome

#106 2006-05-18 15:47:22

Re: new initramfs, testers welcome

#107 2006-05-18 16:32:19

Re: new initramfs, testers welcome

#108 2006-05-18 16:54:01

Re: new initramfs, testers welcome

#109 2006-05-18 17:14:54

Re: new initramfs, testers welcome

#110 2006-05-18 17:15:18

Re: new initramfs, testers welcome

#111 2006-05-18 17:28:31

Re: new initramfs, testers welcome

#112 2006-05-18 17:32:32

Re: new initramfs, testers welcome

#113 2006-05-18 17:37:07

Re: new initramfs, testers welcome

#114 2006-05-18 17:46:28

Re: new initramfs, testers welcome

#115 2006-05-18 18:10:41

Re: new initramfs, testers welcome

#116 2006-05-18 18:53:27

Re: new initramfs, testers welcome

#117 2006-05-18 19:02:09

Re: new initramfs, testers welcome

#118 2006-05-18 19:17:47

Re: new initramfs, testers welcome

#119 2006-05-18 19:55:21

Re: new initramfs, testers welcome

#120 2006-05-18 19:58:17

Re: new initramfs, testers welcome

#121 2006-05-18 21:20:24

Re: new initramfs, testers welcome

#122 2006-05-19 03:43:20

Re: new initramfs, testers welcome

#123 2006-05-19 07:56:35

Re: new initramfs, testers welcome

#124 2006-05-20 16:27:25

Re: new initramfs, testers welcome

#125 2006-06-06 22:31:29

Re: new initramfs, testers welcome

Board footer