new initramfs, testers welcome

tpowa · 2006-05-03 09:41:37

Hi all,
for those who are interested in the new initramfs stuff,
check it out here http://www.archlinux.org/~tpowa/initramfs-udev/
updated tarballs will show up there.
It's fully in development atm, but if you want to give it a shot, go ahead and test it with us, that we can wrap out some glitches.
Download the tarball and run ./setup.sh as root.
check README.TXT too.
greetings
tpowa

waldek_a · 2006-05-03 13:46:25

is there any difference between the one used in the Beyond kernel? I'm asking because I use the Beyond kernel and it works fine for me.

Cheers

waldek

tpowa · 2006-05-03 13:49:03

well it's very different from iphitus and my stuff, totally modular and in the future it willl replace mkinitrd and mkinitramfs, that we have only 1 tool for all kernels that does everything we need.
greetings
tpowa

phrakture · 2006-05-03 20:48:23

waldek_a wrote:

is there any difference between the one used in the Beyond kernel? I'm asking because I use the Beyond kernel and it works fine for me.

The differences are in design, not necessarilly in implementation. It does, however, take advantage of klibc rather than busybox, making the resultant image much smaller. i.e. busybox+mdadm currently are about 1M in side, where as klibc, with all utilities and 'mdassemble' (autoassembly for raid devices) span around 250-300K.

In addition, the scripts, as tpowa said, are fully modular, thus making it easy to provide additional features without having to change the base package.

The default setup should use udev to configure your block devices, getting rid of the hard-coded block devices in the current setup.

There are a few other differences, which I'd be happy to discuss if anyone feels the need.
Subversion repository is here: http://phraktured.net/initramfs

tomk · 2006-05-03 21:14:33

I've just booted with the new image, and everything looks good. I used the default mkinitcpio.conf with kernel26ck from community. Here are two things I noticed:

- I accidentally ran mkinitcpio with no arguments, but it still seemed to work away - plenty of info on screen about what it was doing - so I'm thinking it produced an image. The question is, what's the file called, and where is it? :?

- With iphitus' mkinitramfs, I can expand the generated image by doing

gzip -dc < /boot/your_image_name.img | cpio -i

but this doesn't work with the new setup. Is there some other way I can have a look inside the image?

phrakture · 2006-05-03 23:24:03

tomk wrote:

I accidentally ran mkinitcpio with no arguments, but it still seemed to work away - plenty of info on screen about what it was doing - so I'm thinking it produced an image. The question is, what's the file called, and where is it? :?

Without parameters, it actually just does a "dry run" - it creates a file called ".tmpfilelist" containing a list of files that would go into the image and then deletes it when done.

The "quiet" parameter will become the default at a later time. No image is generated unless you pass "-g IMGNAME".

tomk wrote:

- With iphitus' mkinitramfs, I can expand the generated image by doing
gzip -dc < /boot/your_image_name.img | cpio -i
but this doesn't work with the new setup. Is there some other way I can have a look inside the image?

Hmm, the should be binary compatible. At least, they are from the kernel point of view. I can look at that later on.

For the record, you can use "-s myfilelist" to save the filelist used to generate the image and take a look at that. It doesn't lie. 8)

phrakture · 2006-05-03 23:36:53

tomk wrote:

I've just booted with the new image, and everything looks good. I used the default mkinitcpio.conf with kernel26ck from community.

PS Thanks for the test. It helps to get some extra input on these things. Right now the raid/lvm/encrypted root stuff is in a state of flux - I should have that fixed up the next time I get a few hours to sit down at my machine.

Did it boot any faster/slower? Were there any bottlenecks, as far as the output goes? Anything "look" odd?

Now, just a few suggestions to any other testers - add a second grub or lilo entry for testing this, and DO NOT use the same image name as an existing initrd/initramfs image. That way, if anything fails, you can always reboot your current system.

Try to break it, that's where the best bug reports come from - someone actively trying to make something screw up. 8)

lillwad · 2006-05-04 01:30:12

For what it's worth, I was finally able to boot the -beyond kernel using this. I was unable to do so with mkinitramfs 1.4-6. I can boot just fine on a SATA system (quickly, with no real bottle-necks) by adding either of the following to /etc/mkinitcpio.conf:

MODULES="ata_piix ahci sd_mod reiserfs"

or

HOOKS="base udev ide scsi sata filesystems autodetect"

I got a kernel panic with the default .conf file, and those were the only tweaks I tried. I apologize for not breaking anything , but I'm happy to finally be able to use the -beyond kernel.

lilsirecho · 2006-05-04 01:42:18

Tomk;

As I understand the postings, I could download the tar ball and install the setup material. This provides an alternate.... initrd/udev.... to the existing mkiniitramfs.

To utilize it I must identify a new entry in lilo for one of my three kernels, probably kernel26archck and enter a new label and change the initrd entry in lilo to:

initrd=/boot/mkinitcpio.img

I assume there is a need to generate the mkinitcpio.img file. This is not discussed as a step in the setup readme txt.

Correct me where I am wrongj

phrakture · 2006-05-04 01:48:54

The readme describes it...

readme.txt wrote:

now modify /etc/mkinitcpio.conf file to your needs,
when you are done just enter
mkinitcpio -g /boot/<yourimagefile>

the <yourimagefile> part can be anything, the name is freeform. It does not need to be mkinicpio.img

lilsirecho · 2006-05-04 02:26:02

tpowa;

The archck and -beyond kernels were based on 2.6.15.

Is this new mkinitcpio applicable to all kernels including the 2.6.16.x.x?

phrakture · 2006-05-04 04:33:36

tomk wrote:

gzip -dc < /boot/your_image_name.img | cpio -i

gunzip -dc < /boot/your_image_name.img | cpio -t

Note: gunzip, not gzip. cpio -t, not cpio -i.

tpowa · 2006-05-04 05:32:24

@lillwad could you try to remove scsi from HOOKS= ?

waldek_a · 2006-05-04 05:36:43

works fine with

MODULES="sata_via sd_mod reiserfs"
HOOKS="base udev"

phrakture,
thanks for the explanation. I was a bit confused with naming convention
- mkinitrd: initrd*.img with mkinitrd.conf and mkinitrd tool,
- mkinitramfs: initramfs*.img with mkinitramfs.conf and mkinitramfs tool,
- initramfs: whateverName with mkinitcpio.conf and mkinitcpio tool.

obvious question why not initcpiofs, is it because the "official" name for the package is initramfs? symmetry is nice.

will it support gensplash (through BINARIES? FILES?)?

cheers

waldek

tpowa · 2006-05-04 05:38:54

waldek please also try the autodetect and subsystem stuff, that is the main part that should work.
MODULES= is normally save when you know what's inside your machines, for testing it would be great if you could check the autodetection too
thanks

lilsirecho · 2006-05-04 06:22:55

tpowa;

Having fun trying out the new mkinitcpio.

Managed to decipher what is required but have a kernel panic result.

I ran pacman on the pkg.tar.gz for each of the required pkgs in the correct order.

Then accepted the mkinitcpio.conf as it stands and ran...mkinitcpio -g /boot/mkinitcpio.img

I then used kernel26bwyond as the carrier, modified lilo.conf to generate a new lilo selection called CPIO and entered....initrd=/boot/mkinitcpio.img.

Ran /sbin/lilo -v and received good lilo report.

Booted into kernel panic #1 in CPIO lilo select. Referred to IP missing.

Returned to mkinitcpio.conf and added modules as listed in rc.conf. Made no other changes.EDIT: Re-ran mkinitcpio -g /boot/mkinitcpio.img.

Rebooted into CPIO with another kernel panic with no reference to IP missing. The error is no k init at this kernel panic..

Am I to comment out all open entries in mkinitcpio.conf, such as; BINARIES and FILES?

waldek_a · 2006-05-04 07:35:17

tpowa I forgot to mention that autodetect worked fine. I can't remember exatly how many entries I had in MODULES and HOOKS (I'm at work right now, can't verify). But as far as I can recollect:

MODULES="reiserfs"
HOOKS="base udev autodetect"

I'll confirm when I'm back at home in the evening, I haven't had too much time to play with it this morning. I'll focus more on autodetection since the things I mentioned above work fine (based on the limited testing I did).

the suggested "sane defaults" worked fine too.

BTW I'm using it with the Beyond kernel.

cheers

waldek

tpowa · 2006-05-04 10:32:36

Hi folks,
uploaded our latest stuff to:
http://www.archlinux.org/~tpowa/initramfs-udev/
the autodetection is now real fast and must be put in front of the subsystems.
added usbinput,net and pcmcia hooks.
usbinput is for you with usb keyboard that are else stuck ramfs shell without any input possibility.
just run setup.sh again after untarring.
happy testing and booting

for us it would be great if you could check like this:
try to add your modules to MODULES=
then remove them from MODULES=
try the autodetection, also try to add more subsystems then you have, to see if stuff gets detected that is obviously not there.
for verbose output use -v option on mkinitcpio

thanks for your input and testing efforts
greetings
tpowa

_Gandalf_ · 2006-05-04 15:53:35

Nice guys to see this hitting beta stage
@tomk and all, attention: when u decompress it u need to use --no-absolute-filenames otherwize files will go to / instead of $PWD, i use

gunzip -c /boot/initcpio26.img | cpio -H newc --extract --quiet --no-absolute-filenames --no-preserve-owner --dot

waldek_a · 2006-05-04 18:14:04

I upgraded to the latest release. Maybe at the beginning a short description.
In both mkinitrd and mkinitramfs I need only the following entries:

REMOVE_IDE=1
REMOVE_SCSI=1
REMOVE_SATA=
REMOVE_CDROM=
REMOVE_USB=1
REMOVE_FW=1
REMOVE_RAID=1
REMOVE_DM=1
REMOVE_FS=

HOSTCONTROLLER_SATA="sata_via"
FILESYSTEMS="reiserfs"

/etc/fstab

/dev/sda3 swap swap defaults 0 0
/dev/sda1 / reiserfs defaults 0 0
/dev/sda2 /boot ext2 defaults 0 1
/dev/sda6 /home reiserfs defaults 0 0
/dev/sdb1 /mnt/backup xfs user,noauto 0 0

I tested initramfs aka mkinitcpio :-) in the configurations as below:

1.

MODULES=""
HOOKS="base udev autodetect"

log:

:: Parsing hook [autodetect]
::Generating image '/boot/cpiofs.img'...SUCCESS

I guess this is how it should be, then I changed it to:

2.

MODULES=""
HOOKS="base udev autodetect sata filesystems"

log:
:: Parsing hook [autodetect]
:: Parsing hook [sata]
adding dir /lib/modules
adding dir /lib/modules/2.6.16-beyond
adding dir /lib/modules/2.6.16-beyond/kernel
adding dir /lib/modules/2.6.16-beyond/kernel/drivers
adding dir /lib/modules/2.6.16-beyond/kernel/drivers/scsi
adding file /lib/modules/2.6.16-beyond/kernel/drivers/scsi/libata.ko
adding file /lib/modules/2.6.16-beyond/kernel/drivers/scsi/sata_via.ko
adding dir /lib/modules/2.6.16-beyond/kernel/drivers/block
adding file /lib/modules/2.6.16-beyond/kernel/drivers/block/sx8.ko
adding file /lib/modules/2.6.16-beyond/kernel/drivers/scsi/ahci.ko
adding file /lib/modules/2.6.16-beyond/kernel/drivers/scsi/pdc_adma.ko
adding file /lib/modules/2.6.16-beyond/kernel/drivers/scsi/sd_mod.ko
adding dir /lib/modules/2.6.16-beyond/kernel/drivers/cdrom
adding file /lib/modules/2.6.16-beyond/kernel/drivers/cdrom/cdrom.ko
adding file /lib/modules/2.6.16-beyond/kernel/drivers/scsi/sr_mod.ko
:: Parsing hook [filesystems]
adding dir /lib/modules/2.6.16-beyond/kernel/fs
adding dir /lib/modules/2.6.16-beyond/kernel/fs/reiserfs
adding file /lib/modules/2.6.16-beyond/kernel/fs/reiserfs/reiserfs.ko
adding file /hooks/filesystems
:: Generating module dependancies
adding file /lib/modules/2.6.16-beyond/modules.dep
adding file /lib/modules/2.6.16-beyond/modules.alias
adding file /lib/modules/2.6.16-beyond/modules.symbols
::Generating image '/boot/cpiofs.img'...SUCCESS

filesystems are detected correctly, sata modules too but there are some I think I don't need to boot succesfully, and ones like sx8 are not present in my system (some kind of Promise controller?) same goes to pdc_adma.

3.

MODULES="sata_via sd_mod reiserfs"
HOOKS="base udev"
or
HOOKS="base udev autodetect"

in the above cases kinit is trying to mount ext2 first and then reiserfs.

cheers

waldek

lillwad · 2006-05-04 20:51:08

@tpowa works great without scsi in HOOKS= under both the old and new package. Using

HOOKS="base udev autodetect ide sata filesystems"

with the old package spit out a lot of info like:

sr_mod: Unknown symbol cdrom_ioctl
sr_mod: Unknown symbol cdrom_media_changed
sr_mod: Unknown symbol cdrom_release
sr_mod: Unknown symbol cdrom_open
sr_mod: Unknown symbol unregister_cdrom
 sda1 sda2 sda3 sda4 <<4>sr_mod: Unknown symbol cdrom_number_of_slots
sr_mod: Unknown symbol register_cdrom
sr_mod: Unknown symbol cdrom_ioctl
sr_mod: Unknown symbol cdrom_media_changed
sr_mod: Unknown symbol cdrom_release
sr_mod: Unknown symbol cdrom_open
sr_mod: Unknown symbol unregister_cdrom

The new package does not. Not sure if this is useful, but I'm more than happy to provide feedback.

tpowa · 2006-05-04 22:13:18

@all or lillwad
hmm perhaps we should tell the people:
please use kernel option if you build an initrd for a different kernel you have booted, else boot the kernel you want to test first
else unkown symbols or other strange things might happen.

@ waldek:
MODULES=""
HOOKS="base udev autodetect"
this is the combination that will lead you into a kernel panic.
either use MODULES= or use autodetect + subsystems + filesystems you have.

baze · 2006-05-04 22:57:41

works with sata and usb keyboard here.

MODULES="reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect sata"

but i have the same thing waldek_a reported:

kinit tries to mount /dev/root on /root with type ext2
kinit tries to mount /dev/root on /root with type reiserfs

but it works fine.

lilsirecho · 2006-05-05 04:02:24

Previous post outlined my trial of the system.

I get kernel panic on all attempts.

MODULES="cramfs"

HOOKS="base udev ide filesystems autodetect"
I have tried on two kernels, archck and beyond.

What is my error?

tpowa · 2006-05-05 05:16:34

hmm kernel panic ... did you run setup.sh to install the packages?
what is your exact setup?
could you send me your /tmp/.tmpfilelist after a dry mkinitcpio run?

Arch Linux

#1 2006-05-03 09:41:37

new initramfs, testers welcome

#2 2006-05-03 13:46:25

Re: new initramfs, testers welcome

#3 2006-05-03 13:49:03

Re: new initramfs, testers welcome

#4 2006-05-03 20:48:23

Re: new initramfs, testers welcome

#5 2006-05-03 21:14:33

Re: new initramfs, testers welcome

#6 2006-05-03 23:24:03

Re: new initramfs, testers welcome

#7 2006-05-03 23:36:53

Re: new initramfs, testers welcome

#8 2006-05-04 01:30:12

Re: new initramfs, testers welcome

#9 2006-05-04 01:42:18

Re: new initramfs, testers welcome

#10 2006-05-04 01:48:54

Re: new initramfs, testers welcome

#11 2006-05-04 02:26:02

Re: new initramfs, testers welcome

#12 2006-05-04 04:33:36

Re: new initramfs, testers welcome

#13 2006-05-04 05:32:24

Re: new initramfs, testers welcome

#14 2006-05-04 05:36:43

Re: new initramfs, testers welcome

#15 2006-05-04 05:38:54

Re: new initramfs, testers welcome

#16 2006-05-04 06:22:55

Re: new initramfs, testers welcome

#17 2006-05-04 07:35:17

Re: new initramfs, testers welcome

#18 2006-05-04 10:32:36

Re: new initramfs, testers welcome

#19 2006-05-04 15:53:35

Re: new initramfs, testers welcome

#20 2006-05-04 18:14:04

Re: new initramfs, testers welcome

#21 2006-05-04 20:51:08

Re: new initramfs, testers welcome

#22 2006-05-04 22:13:18

Re: new initramfs, testers welcome

#23 2006-05-04 22:57:41

Re: new initramfs, testers welcome

#24 2006-05-05 04:02:24

Re: new initramfs, testers welcome

#25 2006-05-05 05:16:34

Re: new initramfs, testers welcome

Board footer