new initramfs, testers welcome

_Gandalf_ · 2006-06-06 22:40:59

Try this:

mkinitcpio -s
gen_init_cpio /tmp/.tmpfilelist.XXXX

where XXXX is a random number and see if it segfault, if it does then try to install gen-init-cpio package again or debug it via strace

phrakture · 2006-06-07 22:59:13

Erm, I think that one's my fault - an 'ldd' issue with keymap. I'll be release an new package later tonight, and we can see if that's fixed.

_Gandalf_ · 2006-06-13 16:09:33

Anyone tried the encryption stuff ?
Actually, it's pretty much not working, the root is detected as encrypted device, but:
1- no /dev/mapper folder so mknod /dev/mapper/control will fail, ok folder created and issue is gone.
2- now control is created, a password is asked and /dev/mapper/root is created as it should be, but when the control is passed to kinit and rc.sysinit take the hand on the boot, /dev/mapper/root does not exist and our setup here does not use /initrd to provide root mapper device, so i did the old mkinitrd trick (in filesystem hook) to copy /dev/mapper/root to /new_root/initrd/dev/mapper/root where rc.sysinit finds it and copy/use it but again i ran into very ugly troubles after that I don't know if i should blame my knowledge on this (1st encryption attempt) or the poor encrypt hook

brain0 · 2006-06-13 17:24:36

_Gandalf_ wrote:

Anyone tried the encryption stuff ?

Yes, works fine.

Actually, it's pretty much not working, the root is detected as encrypted device, but:
1- no /dev/mapper folder so mknod /dev/mapper/control will fail, ok folder created and issue is gone.

It is there, at least it works here perfectly

2- now control is created, a password is asked and /dev/mapper/root is created as it should be, but when the control is passed to kinit and rc.sysinit take the hand on the boot, /dev/mapper/root does not exist and our setup here does not use /initrd to provide root mapper device, so i did the old mkinitrd trick (in filesystem hook) to copy /dev/mapper/root to /new_root/initrd/dev/mapper/root where rc.sysinit finds it and copy/use it but again i ran into very ugly troubles after that I don't know if i should blame my knowledge on this (1st encryption attempt) or the poor encrypt hook

That is taken care of with udev. This device stealing trick is very ugly and has been removed intentionally.

_Gandalf_ · 2006-06-13 17:44:53

Then maybe i'm doing something wrong ? a little summary
cryptsetup luksFormat /dev/hda6
cryptsetup luksOpen /dev/hda6 root
mke2fs -j /dev/mapper/root
(install system ..)
add encrypt hook before the filesystem hook after udev and reboot
I got an error about /dev/mapper not found and a panic
I added the folder manually in the encrypt hook, that fixed it, and the system booted but I can't even login, I tried with init 1, /dev/mapper/root does not exist and so the root device is not mounted (well at least not after the early user-space..

brain0 · 2006-06-13 18:19:27

_Gandalf_ wrote:

I got an error about /dev/mapper not found and a panic
I added the folder manually in the encrypt hook, that fixed it

That's a bug, I use both lvm2 and encryption, lvm2 creates the directory, encrypt doesn't, add

add_dir "/dev/mapper"

to the encrypt install hook.

and the system booted but I can't even login, I tried with init 1, /dev/mapper/root does not exist and so the root device is not mounted (well at least not after the early user-space..

I still haven't removed my old custom udev rule to create the devices. Perhaps something is wrong in udev.rules.
Line 192 in udev.rules says KERNEL=="dm-[0-9]*", NAME="", maybe remove that, it seems to break the rule in line 363.

_Gandalf_ · 2006-06-13 23:46:22

That was my solution for hte /dev/mapper folder, anyway 1st, my bad, I donno how on earth did i remove login.defs when i was restoring /etc files, so login problem wasn't related to udev, anyway as for the error about /dev/mapper/root i was getting is solved now, I just removed the like

KERNEL=="dm-[0-9]*", NAME=""

which gave me /dev/mapper/root now and everything works very fine

Thx

phrakture · 2006-06-14 00:16:40

brain0 wrote:

That's a bug, I use both lvm2 and encryption, lvm2 creates the directory, encrypt doesn't, add
add_dir "/dev/mapper"
to the encrypt install hook.

Thanks, fixed in svn.

brain0 · 2006-06-14 11:45:24

_Gandalf_ wrote:

That was my solution for hte /dev/mapper folder, anyway 1st, my bad, I donno how on earth did i remove login.defs when i was restoring /etc files, so login problem wasn't related to udev, anyway as for the error about /dev/mapper/root i was getting is solved now, I just removed the like
KERNEL=="dm-[0-9]*", NAME=""
which gave me /dev/mapper/root now and everything works very fine
Thx

This is all fixed in testing now in the updated mkinitcpio, device-mapper, udev, cryptsetup packages. The hooks have been moved out of mkinitcpio into these packages btw.

damjan · 2006-06-16 03:07:14

I'm using mkinitcpio-0.4.2-1 from testing, on an otherwise non-testing Arch.
Thes hook in the userui userui 0.6.3-2 package tries this:
for f in /etc/splash/suspend2/*; do add_file $f; done
but there's a directory there "images/" and add_file will not create the correct entry in the file list, so later gen_init_cpio complains and the theme images are not added.

I'd also suggest to add an add_dir_recursively function in /lib/initcpio/functions, so that add_dir_recursively it can be used in situations like this.

Here's what I've come up with, but I'm sure I have bugs
add_dir_recursively ()
{
for f in $1/*; do
[ -d $f ] && add_dir_recursively $f
[ -f $f ] && add_file $f
done
}

damjan · 2006-06-16 03:10:38

Also, about the "-a" option. Maybe it should also assume "-s" .. I just made a list of files I'd like in the initcpio.img, and after running mkinitcpio it deleted my filelist... ARGH.. didn't expect that.

Also a "-p Prepend to an existing filelist." option might be usefull.

phrakture · 2006-06-16 14:42:33

damjan wrote:

Also, about the "-a" option. Maybe it should also assume "-s" .. I just made a list of files I'd like in the initcpio.img, and after running mkinitcpio it deleted my filelist... ARGH.. didn't expect that.

Good idea - I will fix in svn

damjan wrote:

Also a "-p Prepend to an existing filelist." option might be usefull.

Hmmm, I don't know about that - the order of the file list doesn't make a huge difference, especially if both are auto-generated... and really the -a and -s stuff is for diagnostics more than anything else.
If you want files/binaries in the initcpio image, try using the FILES and BINARIES entries in the config files.

brain0 · 2006-06-16 16:02:06

damjan wrote:

I'm using mkinitcpio-0.4.2-1 from testing, on an otherwise non-testing Arch.
Thes hook in the userui userui 0.6.3-2 package tries this:
for f in /etc/splash/suspend2/*; do add_file $f; done
but there's a directory there "images/" and add_file will not create the correct entry in the file list, so later gen_init_cpio complains and the theme images are not added.
I'd also suggest to add an add_dir_recursively function in /lib/initcpio/functions, so that add_dir_recursively it can be used in situations like this.
Here's what I've come up with, but I'm sure I have bugs
add_dir_recursively ()
{
for f in $1/*; do
[ -d $f ] && add_dir_recursively $f
[ -f $f ] && add_file $f
done
}

Sorry, I just wrote the hook and sent it to ipthitus, but never actually tested it with fbsplash (due to a slow machine). The best solution would indeed be a add_dir_recursive() function, hopefully that will be added *looks at phrakture*.

damjan · 2006-06-16 18:13:37

phrakture wrote:

Hmmm, I don't know about that - the order of the file list doesn't make a huge difference, especially if both are auto-generated... and really the -a and -s stuff is for diagnostics more than anything else.
If you want files/binaries in the initcpio image, try using the FILES and BINARIES entries in the config files.

True, while playing with the filelist to see what's going on I completely forgot about the config file

phrakture · 2006-06-16 18:24:48

brain0 wrote:

The best solution would indeed be a add_dir_recursive() function, hopefully that will be added *looks at phrakture*.

Added in svn, as "add_full_dir" (I like the name better.. 'recursively' is hard to spell, heh)

hudson · 2006-06-29 18:59:34

Hi guys,

I was not that confused about gensplash at boot but now I am... Before I changed to mkinitcpio from mkinitrmfs everything worked like a charm with my beyond kernel. Now I get my boot screen up and running after udev has been loaded, Why is that? How can I make it load faster? Also, my background image is not being set on VCs at boot, I have tried to add this line in rc.conf without any luck:

 CONSOLEFONT=default8x16.psfu.gz

My mkinitcpio looks like this:

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

...and in my grub file:

title beyondNsplash
root (hd1,0)
kernel /vmlinuz26beyond root=/dev/hdb3 video=vesafb:ywrap,1024x768-32@75 splash=silent,kdgraphics,theme:NewLinux,fadein quiet CONSOLE=/dev/tty1 resume2=swap:/dev/hdb2 ro
initrd /foo.img
boot

Now some good news about your work, my boot time to login screen is why much faster than with mkinitramfs, good work guys!!! And everything else is working as it suppose too, but I havent tested all of it but so for so good.

Snowman · 2006-06-29 19:03:29

The current gensplash doesn't work with mkinitcpio. dtw hasn't added the needed hook yet.

hudson · 2006-06-29 19:17:29

I must have missed that one when going through the 8 pages.. :oops:
Btw. do I need an extra module loaded if I want tvout??

Thx in advance!!!

ahioros · 2006-06-30 13:44:25

Snowman wrote:

The current gensplash doesn't work with mkinitcpio. dtw hasn't added the needed hook yet.

:-(
but mkinitcpio works fine for me :-)

damjan · 2006-07-01 13:28:46

Snowman wrote:

The current gensplash doesn't work with mkinitcpio. dtw hasn't added the needed hook yet.

It surelly works. You just need to include the proper files in the initial ram disk.

Just add
BINARIES="/sbin/splash_helper"
FILES="your splash theme files here"
to /etc/mkinitcpio.conf and recreate the ram disk.

Phrodo_00 · 2006-07-01 18:40:36

damjan wrote:

Snowman wrote:
The current gensplash doesn't work with mkinitcpio. dtw hasn't added the needed hook yet.
It surelly works. You just need to include the proper files in the initial ram disk.
Just add
BINARIES="/sbin/splash_helper"
FILES="your splash theme files here"
to /etc/mkinitcpio.conf and recreate the ram disk.

I'll try that, I had already thought of that, but I didn't know what to include... Thank you BTW ^^

hudson · 2006-07-03 10:14:12

Thx. duders, I will try that when I get home from work

ahioros · 2006-07-03 22:55:31

Gensplash works fine on initcpio

just add on /etc/mkinitcpio.conf

BINARIES="/sbin/splash_helper"
FILES="/etc/splash/darch/1024x768.cfg /etc/splash/darch/images/background-1024x768.png /etc/splash/darch/images/verbose-1024x768.png /etc/splash/darch/Vera.ttf"
this example is for the darch theme

tnks to damjan for the tip.

_Gandalf_ · 2006-07-03 23:04:12

Or you can hack mkinitcpio yourself
http://wael.nasreddine.com/trash/splashutils/
i did it a long time ago, but still dtw didn't implement it, phrakture need HCONFIG implementation too, that's done as well

geekner · 2006-07-08 05:16:58

I havent had a chance to see if this was reported before, so forgive me if this was already mentioned. 8)

I currently run kernel26beyond and mkinitcpio from testing, I recently had to install a replacement motherboard. Replacing the motherboard also changed the chipset and modules, from via to nforce3 drivers (Abit KV8-Max3 (via) to Abit NF8-V2 (nf3)). On boot, the wrong IDE module was loaded and there was a kernel panic (Could not read hd(0,0) or something similer). I had to load an older kernel (2.6.15-archck) and manually remake the beyond mkinitcpio image, after that it booted fine. Is that normal or a bug? Archck kernel had no problems detecting the right IDE drives after a major hardware change. It seems to just be a functionality issue or bug with mkinitcpio. Any clarification would be appreciated.

Arch Linux

#126 2006-06-06 22:40:59

Re: new initramfs, testers welcome

#127 2006-06-07 22:59:13

Re: new initramfs, testers welcome

#128 2006-06-13 16:09:33

Re: new initramfs, testers welcome

#129 2006-06-13 17:24:36

Re: new initramfs, testers welcome

#130 2006-06-13 17:44:53

Re: new initramfs, testers welcome

#131 2006-06-13 18:19:27

Re: new initramfs, testers welcome

#132 2006-06-13 23:46:22

Re: new initramfs, testers welcome

#133 2006-06-14 00:16:40

Re: new initramfs, testers welcome

#134 2006-06-14 11:45:24

Re: new initramfs, testers welcome

#135 2006-06-16 03:07:14

Re: new initramfs, testers welcome

#136 2006-06-16 03:10:38

Re: new initramfs, testers welcome

#137 2006-06-16 14:42:33

Re: new initramfs, testers welcome

#138 2006-06-16 16:02:06

Re: new initramfs, testers welcome

#139 2006-06-16 18:13:37

Re: new initramfs, testers welcome

#140 2006-06-16 18:24:48

Re: new initramfs, testers welcome

#141 2006-06-29 18:59:34

Re: new initramfs, testers welcome

#142 2006-06-29 19:03:29

Re: new initramfs, testers welcome

#143 2006-06-29 19:17:29

Re: new initramfs, testers welcome

#144 2006-06-30 13:44:25

Re: new initramfs, testers welcome

#145 2006-07-01 13:28:46

Re: new initramfs, testers welcome

#146 2006-07-01 18:40:36

Re: new initramfs, testers welcome

#147 2006-07-03 10:14:12

Re: new initramfs, testers welcome

#148 2006-07-03 22:55:31

Re: new initramfs, testers welcome

#149 2006-07-03 23:04:12

Re: new initramfs, testers welcome

#150 2006-07-08 05:16:58

Re: new initramfs, testers welcome

Board footer