# No output visible from initramd using EFI boot

## msst

I try to achieve since hours now an initramfs disk that allows me to mount a Luks-crypt root. But I am running into a problem with the EFI boot system and debugging the initramdisk.

What I have here is a gentoo system that boots stable from the EFI bios using EFIstup. I can directly point the efibootmgr to the linux kernel, give the correct linux command line with -u (root and rootfstype) and all works. Boots lightning fast any normal root. I set that up a while ago and it was a pain in the a** to set up, but after it was done it worked forever.

Now if I want to boot a crypted root and therefore I need an initramfs that mounts the root in userspace - I read all the scattered documentation and managed indeed to get an initramfs to work! I build it directly into the kernel with the new initramfs source file feature from the kernel. And if I just let that thing mount my normal unencrypted rootfs it kind of works. Just that there is no output at all. I have the init script from the initramfs print status messages such as "mounting root fs...success" but nothing ever shows.

In fact this seems to be connected to the framebuffer thingy from EFI. I have EFI framebuffer enabled (necessary to see anything from the early boot!) and see the kernel coming up right to the moment where it hands over to the initramfs. Then nothing appears on the screen for a short time, and bang the framebuffer from the normal boot / init process kicks in and I see the normal bootcripts running from my now mounted root. I have tried putting in a delay (sleep 10) into the initramfs and then it takes 10 seconds longer but I only start seeing the output from the normal boot process.

Somehow that initramfs is unable to do any output and that prevents me from debugging it quite effectively.

Has anyone done such a thing (self made initramfs on an EFI system using framebuffers) already? Any idea what is going wrong here exactly and what to do now?

----------

## s4e8

you need a graphics console:

CONFIG_EARLY_PRINTK_EFI=y

CONFIG_FB_EFI=y

CONFIG_FRAMEBUFFER_CONSOLE=y

----------

## khayyam

s4e8 ... printk is the kernel print function ... much like printf() ... its not required to print to the console (though of course a console is useful ;). In the above list then probably only CONFIG_FRAMEBUFFER_CONSOLE=y is required, if the OP has a framebuffer (ie, inteldrmfb) then CONFIG_FB_EFI isn't needed.

@mas- ... in your init are you creating a /dev/console? ... ie:

```
mknod /dev/console c 5 1
```

If you're not set on creating your own then I might suggest you look at better-initramfs.

Currently I have the following:

```
% zgrep INITRAMFS_SOURCE /proc/config.gz

CONFIG_INITRAMFS_SOURCE="/usr/src/better-initramfs/sourceroot"

% cat /proc/cmdline

\EFI\linux\vmlinuz-3.13.11-ck.efi quiet ro nopat threadirqs video.use_native_backlight=1 rootfstype=ext4 luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root swsusp resume=/dev/mapper/vg-swap

% zcat /proc/config.gz | awk '/((FB|PRINTK)_EFI|CONSOLE)/'

# CONFIG_NETCONSOLE is not set

CONFIG_CONSOLE_TRANSLATIONS=y

CONFIG_VT_CONSOLE=y

CONFIG_VT_CONSOLE_SLEEP=y

CONFIG_HW_CONSOLE=y

CONFIG_VT_HW_CONSOLE_BINDING=y

# CONFIG_FB_EFI is not set

CONFIG_VGA_CONSOLE=y

CONFIG_DUMMY_CONSOLE=y

CONFIG_FRAMEBUFFER_CONSOLE=y

CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y

# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set

# CONFIG_EARLY_PRINTK_EFI is not set

% cat /proc/fb

0 inteldrmfb
```

HTH & best ... khay

----------

## s4e8

Yes, you are right, that's a safe list. earlyprintk only needed if kernel hang before hardware initialization. FB_EFI is very small, it's better try it first. Real DRM framebuffer is good but maybe buggy, eg: firmware blob or backlight problem.

 *khayyam wrote:*   

> s4e8 ... printk is the kernel print function ... much like printf() ... its not required to print to the console (though of course a console is useful . In the above list then probably only CONFIG_FRAMEBUFFER_CONSOLE=y is required, if the OP has a framebuffer (ie, inteldrmfb) then CONFIG_FB_EFI isn't needed.
> 
> 

 

----------

## tclover

Did you, by any chance, read dm-crypt LUKS article on the wiki? There are usefull guidances there along with (untested) init script (& build script.)

(Just wrote them down as a minimal tool without any actual testing.) (Yes, I am one of the contributors of the article.)

You do need console node. So, another approach is to include it directly in your initramfs (to not waste time on useless checking.)

Apart from that, checking the fd (for std{out,in,err} won't hurt. (Noticed that an `exec 0<$STDIN 1>$STDOUT (2>&1)' may be necessary.)

And you should _not_ have uvesafb enabled as builtin. (This is a source for trouble for sure.) Lastly, ponder which fb to enable for early boot (efi for you.) And then, modprobe drm kernel driver, if any, later to avoid possible issue. (The kernel config menu are a bit... too confusing for my taste. I've just kept asking to myself which one to use. And then efifb was the right spot because almost all drm stuff is build as module, here, to be able to switch to various drivers (proprietary blobs included) _seamlessly_.) 

Or else, follow that better-initramfs link or my sig. to get a functional one (that you don't need compressed... for kernel EFI stub. Available on both directions.) I do prefer mkinitrafs-ll for obvious reasons (not because I am the author but for... really great flexibilitiy and modularity: let the user do whatever (is) needed/wanted.)

----------

## msst

Wow, lots of helpful comments - thanks. I will go work them one by one.

 *Quote:*   

> CONFIG_EARLY_PRINTK_EFI=y 

 

I tried that option already yesterday. BIG mistake, has cost me an extra hour, as it does indeed printk the early kernel but conflicts with the video card drivers and hence rendered any kernel useless. Also I have no problem with the kernel initialization - that works. It goes amiss somewhere in the initrd process that I cannot see on the screen.

 *Quote:*   

> CONFIG_FB_EFI=y
> 
> CONFIG_FRAMEBUFFER_CONSOLE=y

 

Both enabled, see the full .config, which is currently working and booting via initramfs - I just do not see any output from the initramfs and do not know what goes wrong once I try to mount the crypted root:

https://bpaste.net/show/abf2ac45fd70

Please let me know if you see anything wrong there. But it seems have all the kernel options (plus EFI_FB) that khay has. Here is my cmdline and framebuffer:

```
core linux # cat /proc/cmdline 

root=/dev/sda5 ro rootfstype=btrfs root=/dev/sda5 ro rootfstype=btrfs

core linux # cat /proc/fb

0 radeondrmfb

```

 *Quote:*   

> if the OP has a framebuffer (ie, inteldrmfb) then CONFIG_FB_EFI isn't needed.

 

For me it seems to be needed. It did initially try without, but then I cannot see anything from the kernel boot process. All black and only kicks in one the rc-scripts are running and probably loading the radeondrmfb module?

 *Quote:*   

> @mas- ... in your init are you creating a /dev/console? ... ie: 

 

Yes, indirectly. I am mounting devtmpfs, see the init script, which I took from some webpage and adapted for me:

https://bpaste.net/show/c0a1e0b21a7e

And this is lsdev.txt, so what my initrd sees:

https://bpaste.net/show/df4103db169a

...which contains a console device.

 *Quote:*   

> Did you, by any chance, read dm-crypt LUKS article on the wiki? 

 

Very probably, I read like 20 scattered recipes. Cannot remember em all any more. This documentation is really a mess, because there are soo many different options, ways to do it etc.

 *Quote:*   

> Or else, follow that better-initramfs link or my sig. to get a functional one (that you don't need compressed... for kernel EFI stub. Available on both directions.) I do prefer mkinitrafs-ll for obvious reasons (not because I am the author but for... really great flexibilitiy and modularity: let the user do whatever (is) needed/wanted.)

 

That would be a way to work around it. I will give it a try later. But really, it is only a work-around, because I should simply be able to see the %!%%!% output from my initramfs. In the moment I only know that it is doing anything, because I see the debug files it creates. But not what is going wrong with the cryptomount. Here is the list of the included files by the way:

https://bpaste.net/show/3de95d6c3ab2

If anyone has an idea what is wrong and what I should try to get the screen to show the output, please let me know and I will try it. I have now invested sufficient time that I consider that a question of honour to continue tackling this bitchy problem. 8-;

----------

## msst

 *Quote:*   

> Or else, follow that better-initramfs link or my sig. to get a functional one

 

I tried mkinitramfs-ll now. Nice, it actually works! That is already much better than dracut or genkernel, which I could not get to work lately.

I also learnt something from it - very likely the problem is the missing drm / grafics module. I see your initrd loads this and I have a screen, voila. So I probably need to figure out what exactly to include for my own minisolution. Will steal shamelessly from your working config. 8-; Do you know what the minimum set of modules is? Just drm? Or should I try compiling the driver fixed into kernel?

By the way, I found two small bugs in mkinitramfs. When I boot with "iroot=sda5:btrfs:Yes" command line, the initrd from mkinitramfs-ll works flawlessly to boot in my uncrypted root. If I use "iroot=UUID=my-cryptroot-UUID::Yes ikroot=pwd" then I get 2 bugs:

1) The kernel console writes into the password prompt. Ugly, but workable.

2) The cryptsetup call works, but the mount to /newroot fails. When I then manually do "mount /dev/mapper/UUID\=blahblah /newroot" then it works. Some small script error I guess.

----------

## tclover

You seem to be using btrfs-root init script and related files. There isn't any `/dev/console' in the files included in the initramfs. You do attach a file listing many devices; and you're saying the console node is created indirectly by mounting devtmpfs on `/dev'. That's slightly a different thing. You _should_ have `/dev/console' in files included in the initramfs. Period. What get mounted on `/dev' is a different story.

This might be the solution of your problem.

(So, you're using BTRFS on LUKS? Lucky you... there is support for that in mkinitramfs-ll.) Good luck.

----------

## khayyam

 *mas- wrote:*   

>  *Quote:*   @mas- ... in your init are you creating a /dev/console? ... ie:  
> 
> Yes, indirectly. I am mounting devtmpfs, see the init script, which I took from some webpage and adapted for me:

 

mas- ... to restate what tclover says above, you will need /dev/console (and tty, zero, null, random, urandom) in place before you do anything like mount devtempfs. See init from better-initramfs as an example. I'd disagree with tclover that you need that file in /dev ... it can be created with mknod from init.

That really seems to be your issue here ... at least with the init you're using.

best ... khay

----------

## msst

 *Quote:*   

> mas- ... to restate what tclover says above, you will need /dev/console (and tty, zero, null, random, urandom) in place before you do anything like mount devtempfs. 

 

Ok, I was not aware of this. I though if devtmpfs makes the right file with right numbers then it should be ok. So I have now put that into my init script. I used the mknod way, that better-initramfs uses

https://bpaste.net/show/fe96509229c9

and booted first with my script into the unencrypted root to see what happens.

One the one hand, all commands seem to work as visible from init.log:

```
Executed: 'mknod /dev/console c 5 1'

Executed: 'mknod /dev/null c 1 3'

Executed: 'mknod /dev/tty c 5 0'

Executed: 'mknod /dev/urandom c 1 9'

Executed: 'mknod /dev/random c 1 8'

Executed: 'mknod /dev/zero c 1 5'

Executed: 'mount -t proc none /proc'

Executed: 'mount -t sysfs none /sys'

Executed: 'mount -t devtmpfs none /dev'

Executed: 'mount /mnt/root'

init.log lines 1-10/10 (END)
```

But it did not help with the visibility of the echo commands from my initrd. I still keep seeing only the kernel stuff from efi-fb, then a few seconds nothing happens, then it resumes when the regular init from my rootfs loads modules and drivers. So the missing console dev was not the cause of the problems. Apparently the /dev/console created from mounting devtmpfs is sufficient. I am gonna leave the mknod code in anyway to be sure and have that possible source of problems excluded.

What I will do now is experiment with the modules radeon, drm_kms_helper and drm, because I see that mkinitramfs-ll has these loaded.

----------

## tclover

 *mas- wrote:*   

> What I will do now is experiment with the modules radeon, drm_kms_helper and drm, because I see that mkinitramfs-ll has these loaded.

 

That should not be a solution... however, loading any other drm/${DRIVER}fb would take over the screen. EFIfb should handle that just fine like any other fb driver... or uvesafb for that matter. init should output to console just fine. (Then, you may add `exec </dev/console >/dev/console' to your init script. And then check if `/dev/fd' is (sym)linked to `/proc/self/fd'. Take a look at mkinitramfs-ll/init or better-iniramfs/init for additional checks about this.)

PARENTHESIS:

Sometimes, I do had a similar issue but it's not related to mkinitramfs-ll/init... rather SysVinit+OpenRC: when (mkinitramfs-ll/)init switch root, nothing is displayed on the console untill getty is spawned; more troubling, setting `rc_logger=yes' does nothing (nothing is written to the log.)

But this only happen sometimes with SysVinit+OpenRC and not Runit+OpenRC. After booting (once) with Runit+OpenRC, the issue goes away only... to come back later for mysterious reasons. I investigated this several time to no avail. 

To be clear, this is _only_ a SysVinit+OpenRC issue (& a nasty one at that--making debugging impossible because nothing is logged.)

(PARENTHESIS )END.

EDIT: You do need those nodes, they aren't optional.

----------

## msst

Thanks again, you were right, that it was also not the drm modules.

But I did learn that compiling the grafic card driver, drm and drm_kms_helper into the kernel and not using modules there does help - it makes the FB_EFI obsolete and gives a much nicer EFI console view. So I removed FB_EFI now.

And thanks to your help I think I got what the problem was now. I added this

```
 # Setup up and check some evtl. important miscellaneous stuff

  [ -h /dev/fd     ] || ln -fs /proc/self/fd   /dev/fd

  [ -h /dev/stderr ] || ln -fs /proc/self/fd/2 /dev/stderr

  [ -h /dev/stdin  ] || ln -fs /proc/self/fd/0 /dev/stdin

  [ -h /dev/stdout ] || ln -fs /proc/self/fd/1 /dev/stdout

  exec 0</dev/console 1>/dev/console 2>&1

```

But yeah, one step further, other problems. Now I can see whats happening and there is still more to debug. Will have a further look next days.

What I also did is indeed try out better-initramfs. That works out of the box and has a nice easy syntax. So far the easiest solution and what I would recommend for those who really don't want to go on this journey. Just a shame it is not inside the normal gentoo repositories. Instead we have all this stuff like dracut and genkernel, which seems to fail pretty often (as for me)...

Also really tough to get this initramfs right on ones own, but I will try a bit more.

----------

## khayyam

 *mas- wrote:*   

> What I also did is indeed try out better-initramfs. That works out of the box and has a nice easy syntax. So far the easiest solution and what I would recommend for those who really don't want to go on this journey. Just a shame it is not inside the normal gentoo repositories. Instead we have all this stuff like dracut and genkernel, which seems to fail pretty often (as for me)...

 

mas- ... its author (slashbeast) is in fact a gentoo developer, I imagine its not available as a package as its a build system itself (using Aboriginal Linux), rather than a tool (like genkernel or dracut) that extracts the binaries from the currently installed system.

Anyhow, yes, I'd recommend better-initramfs for anyone struggling with genkernel, dracut, etc, for enc_root (or lvm within enc_root).

best ... khay

----------

## tclover

 *mas- wrote:*   

> 
> 
> But I did learn that compiling the grafic card driver, drm and drm_kms_helper into the kernel and not using modules there does help - it makes the FB_EFI obsolete and gives a much nicer EFI console view. So I removed FB_EFI now.

 

It will if you don't ever need a propriatary blob (namely nVidia/Fglrx). Otherwise, you will have to go the two kernels way (which I found a little to funny and troublesome.) A saner solution would be... module.

 *mas- wrote:*   

> What I also did is indeed try out better-initramfs. That works out of the box and has a nice easy syntax. So far the easiest solution and what I would recommend for those who really don't want to go on this journey.

 

What syntax are you talking about? It's POSIX shell pluw a few helpers to make life easy for repeatitive task. (Just asking to know from other veiws.)

EDIT: There are mainly a couple of helper (3 by memory) which make a big difference with better-initramfs *directness* to set up a crypted block stack (with optional btrfs/zfs/lvm..).

* first, to set up key modes (there is no such a thing in better-initramfs);

* second, to set up keymode/key[file] depending on the *group* (meaning root/swap/resume which may have different raid array, lvm grpup, zfs pool ...) (again, no equivalent in better-initramfs);

* and third, support canonical block device (with or without `/dev/*/' prefix) along with UUID/LABEL (& detached header for dm-crypt LUKS) anywhere inthe block stack.

Well, as you may notice extra flexibity comes with at least 3 extra helpers. (Nothing scary here, because each helper has a very few lines: stk() for keymode...)

PARENTHESIS: DOING PR? (PARENTHESIS )END. So so.

----------

## tclover

 *khayyam wrote:*   

> 
> 
> Anyhow, yes, I'd recommend better-initramfs for anyone struggling with genkernel, dracut, etc, for enc_root (or lvm within enc_root).
> 
> 

 

I would recommend... mkinitramfs-ll because it's a _modular tool_ contrary to a build thing. I can only see a single advantage of it: build something out of a no working system.

But I'd rather have the ability to sync to current kernel+additional tools/packages (say to sync to new AUFS which has XATTR) seamlessly (with a single command) rather than that.

----------

## msst

```
What syntax are you talking about?
```

Sorry, that wasn't very clearly expressed. I meant actually both the coding style (I read through the init and functions scripts to see what I was/am missing so far) and the "user interface" in the form of the kernel command line, password prompt, how it reacts if you misconfigure it etc.

And purely from the point of what is easiest to use, understand and setup fast this would be why I recommended better-initramfs. Remember that I am not really much of a programmer and certainly no bash script guru. And I have probably already invested way more time into that matter than most would be willing to.

Setting up better-initramfs took 2-3 minutes for the compiler, and then 5 minutes looking into the readme/init to figure out the kernel command line and then it worked first run. mkinitramfs-ll the same thing took me about 30 minutes and 4-5 tries before I had understood all and the kernel command line correct. And I have to concentrate and read multiple times to understand how the init script works there.

Either way, in the weekend I will see if I can get my own little hack of a script running a bit better. Thanks to your help, now I can at least debug it. In the moment something with the device handling still fails - suprisingly now in the crypted root rc-init scripts (and its some bug in my scripts, as the same cryptroot boots perfect with both mkinitramfs-ll and better-initramfs). The cryptsetup and mount already works.

----------

## tclover

 *mas- wrote:*   

> And purely from the point of what is easiest to use, understand and setup fast this would be why I recommended better-initramfs. Remember that I am not really much of a programmer and certainly no bash script guru. And I have probably already invested way more time into that matter than most would be willing to.
> 
> Setting up better-initramfs took 2-3 minutes for the compiler, and then 5 minutes looking into the readme/init to figure out the kernel command line and then it worked first run. mkinitramfs-ll the same thing took me about 30 minutes and 4-5 tries before I had understood all and the kernel command line correct. And I have to concentrate and read multiple times to understand how the init script works there.

 

30m+... way too much. Building an initramfs should be easy... so I should put a summary in the `SYNOPSIS' after the required kernel command line argument stating what to set depending on the setup. (Each feature--, RAID, LVM, ZFS, BTRFS, AUFS+SquashFS, ZRAM,--require the appropriate command line argument if used; and LUKS require only setting a key-mode/file for root/swap/resume if crypted (because any or all can be crypted.) Easy isn't it?

30M+... really?

----------

## khayyam

 *tclover wrote:*   

>  *khayyam wrote:*   Anyhow, yes, I'd recommend better-initramfs for anyone struggling with genkernel, dracut, etc, for enc_root (or lvm within enc_root). 
> 
> I would recommend... mkinitramfs-ll because it's a _modular tool_ contrary to a build thing. I can only see a single advantage of it: build something out of a no working system.

 

tclover ... given your the author of mkinitramfs-ll then I wouldn't expect you would recommend any thing else. However, you're letting that bias cloud your evaluation, as there is certainly more than the "single advantage" you're currently accepting as a valid criteria.

```
# ls -l busybox =busybox

-rwxr-xr-x 1 root root  819860 2014-11-20 05:46 busybox

-rwxr-xr-x 1 root root 1827952 2013-09-14 14:38 /bin/busybox

# du -hs /usr/src/better-initramfs/sourceroot

2.8M  /usr/src/better-initramfs/sourceroot
```

That is 2.8M uncompressed ... it has cryptsetup, lvm, busybox, etc ... everything I need ... and doesn't rebuilt unless I decide that it does.

 *tclover wrote:*   

> But I'd rather have the ability to sync to current kernel+additional tools/packages (say to sync to new AUFS which has XATTR) seamlessly (with a single command) rather than that.

 

I'd rather *not* have that ... I don't believe an initramfs should need rebuilt when updating the kernel.

You're welcome to use, indeed recommend, whatever tool you like ... but your recommendation says much more about your maintainership than about the particulars of better-initramfs.

best ... khay

----------

## tclover

 *khayyam wrote:*   

> ...
> 
> tclover ... given your the author of mkinitramfs-ll then I wouldn't expect you would recommend any thing else. However, you're letting that bias cloud your evaluation, as there is certainly more than the "single advantage" you're currently accepting as a valid criteria.
> 
> ```
> ...

 

Is this supposed to mean something? Just asking... because I see nothing with that.

So you want to compare the size of something? And you're using only the size a single binary? I'm leaving the rest to you.

 *khayyam wrote:*   

> 
> 
>  *tclover wrote:*   But I'd rather have the ability to sync to current kernel+additional tools/packages (say to sync to new AUFS which has XATTR) seamlessly (with a single command) rather than that. 
> 
> I'd rather *not* have that ... I don't believe an initramfs should need rebuilt when updating the kernel.
> ...

 

Of course you're _completly_ free to have any trouble you choose to bear with. Do you _even_ still need to state it? I was just pointing to a possible issue when AUFS+SquashFS is used and XATTR wellcomed..., which _mean_, if you have no use of it... you don't need rebuilding... or else keep whatever you like.

EDIT: (DID I GET IT, THAT IS)

So your point is: you can have some stripped down binary in... that directory and avoid the need to sync to the current version available on the system?

This is also suported in mkinitramfs-ll... and there is indeed two little scripts for busybox and gnupg... Period (I do not want to waste unecessary time on this.)

(EDIT )END

----------

## khayyam

 *tclover wrote:*   

>  *khayyam wrote:*   [...] given your the author of mkinitramfs-ll then I wouldn't expect you would recommend any thing else. However, you're letting that bias cloud your evaluation, as there is certainly more than the "single advantage" you're currently accepting as a valid criteria.
> 
> ```
> # ls -l busybox =busybox
> 
> ...

 

tclover ... I get the impression you are being argumentative, again perhaps a reflection of your investment, and so attachment to, mkinitramfs-ll. Is that "meaningful", yes ... I'll "leave the rest to you" to figure out why it might be. I provided the size of a "single binary", but *also* the size of the entire uncompressed initramfs, so you can, if you so like, make *some* comparison (and certainly someone using genkernel, or dracut, can do the same).

 *tclover wrote:*   

>  *khayyam wrote:*   I'd rather *not* have that ... I don't believe an initramfs should need rebuilt when updating the kernel. You're welcome to use, indeed recommend, whatever tool you like ... but your recommendation says much more about your maintainership than about the particulars of better-initramfs. 
> 
> Of course you're _completly_ free to have any trouble you choose to bear with. Do you _even_ still need to state it? I was just pointing to a possible issue when AUFS+SquashFS is used and XATTR wellcomed..., which _mean_, if you have no use of it... you don't need rebuilding... or else keep whatever you like.

 

Its no "trouble", that's simply the term you've chosen to use to blacken the argument, and your "possible issue" is related to the fact that modules are involved, and as I'd said I'd rather *not* have that. Its not the fact that I don't have use of it, if I did I could solve this without having modules in the initramfs (and so avoid rebuilding the initramfs on kernel updates).

Anyhow, I don't think you want to have a sensible discussion about the issue, you seem to be completely blinded by your choices and/or maintainership. Good luck with it ...

best ... khay

----------

## tclover

 *khayyam wrote:*   

> Its no "trouble", that's simply the term you've chosen to use to blacken the argument, and your "possible issue" is related to the fact that modules are involved, and as I'd said I'd rather *not* have that. Its not the fact that I don't have use of it, if I did I could solve this without having modules in the initramfs (and so avoid rebuilding the initramfs on kernel updates).

 

Be verbose as you know how to be... I still cannot get that "possible issue" (on your side). Not to rebuild on kernel updates? Fine, there nothing that has a hard dependency on kernel modules in mkinitramfs-ll: just avoid having features that depends on it, or else, build them into the kernel what need to be to avoid it (to state it otherwise.) (Everything can be configured in the configuration file of the build script for this end.)

mkinitramfs-ll does not impose a _right_ way of doing things that should be done to have rootfs mounted: kernel modules+live package is just the default. No kernel modules & striped down binaries is supported.

EDIT:

I don't remeber a project that aim to provide a busubox like multi-purpose stripped down binary: this is also supported, just make the symlink in the root directory of the image to get this kind of support. And it's easy at that, so to speak, no fixed _right_ way imposed to the end user on how to get rootfs mounted. (But there are _few_ ways to get it done, simple & easy with that.)

----------

## khayyam

 *tclover wrote:*   

>  *khayyam wrote:*   Its no "trouble", that's simply the term you've chosen to use to blacken the argument, and your "possible issue" is related to the fact that modules are involved, and as I'd said I'd rather *not* have that. Its not the fact that I don't have use of it, if I did I could solve this without having modules in the initramfs (and so avoid rebuilding the initramfs on kernel updates). 
> 
> Be verbose as you know how to be... I still cannot get that "possible issue" (on your side). Not to rebuild on kernel updates? Fine, there nothing that has a hard dependency on kernel modules in mkinitramfs-ll: just avoid having features that depends on it, or else, build them into the kernel what need to be to avoid it (to state it otherwise.) (Everything can be configured in the configuration file of the build script for this end.)

 

tclover ... I'm not always sure I understand your english, or how well you're understanding mine, the "possible issue" didn't come from me (at least as something directed toward the use of mkinitcpio-II) but your "a possible issue when AUFS+SquashFS is used". As I said, *if* there is an issue there its due to having modules in the initramfs, it can (as you suggest above) be "built into the kernel". You had stated this as a counter to better-initramfs:

 *tclover wrote:*   

> I can only see a single advantage of it: build something out of a no working system. But I'd rather have the ability to sync to current kernel+additional tools/packages (say to sync to new AUFS which has XATTR) seamlessly (with a single command) rather than that.

 

So, I was pointing out that this "have the ability" doesn't matter in the least as far as better-initramfs is concerned, and it certainly isn't a mark against it (as you suggest).

 *tclover wrote:*   

> mkinitramfs-ll does not impose a _right_ way of doing things that should be done to have rootfs mounted: kernel modules+live package is just the default. No kernel modules & striped down binaries is supported.

 

I've not said that better-initramfs is "the right way", only that the "single advantage" you provided wasn't the only advantage. Now, so as to provide another "advantage", given that mkinitcpio-II supports "striped down binaries" can you also create a 2.8M (uncompressed) initramfs with cryptsetup, lvm, busybox, askpass, init, and whatever else is needed?

 *tclover wrote:*   

> I don't remeber a project that aim to provide a busubox like multi-purpose stripped down binary: this is also supported, just make the symlink in the root directory of the image to get this kind of support. And it's easy at that, so to speak, no fixed _right_ way imposed to the end user on how to get rootfs mounted. (But there are _few_ ways to get it done, simple & easy with that.)

 

This "right way" seems to come entirely from you, no one in this thread (myself included) have said that "{x} is the right way", you seem to be arguing against something which is of your own invention. Now, mkinitcpio-II may support "stripped down binaries" but its not building the entire initramfs using uClibc ... thats *not* to say it makes it any better than mkinitcpio-II ... only that your only "single advantage" is not the only advantage.

best ... khay

----------

## tclover

 *khayyam wrote:*   

> I've not said that better-initramfs is "the right way", only that the "single advantage" you provided wasn't the only advantage. Now, so as to provide another "advantage", given that mkinitcpio-II supports "striped down binaries" can you also create a 2.8M (uncompressed) initramfs with cryptsetup, lvm, busybox, askpass, init, and whatever else is needed?

 

Yes. And I will bring coffee and pastries on your bed tomorrow. The formaer _is_ up to the end user, and the latter a _joke_ (to makes things clear enough.)

EDIT:

That seems to be a concern of yours... so feel free to do whater you want/need with the tool. Period.

----------

## khayyam

 *tclover wrote:*   

>  *khayyam wrote:*   I've not said that better-initramfs is "the right way", only that the "single advantage" you provided wasn't the only advantage. Now, so as to provide another "advantage", given that mkinitcpio-II supports "striped down binaries" can you also create a 2.8M (uncompressed) initramfs with cryptsetup, lvm, busybox, askpass, init, and whatever else is needed? 
> 
> Yes. And I will bring coffee and pastries on your bed tomorrow. The formaer _is_ up to the end user, and the latter a _joke_ (to makes things clear enough.) That seems to be a concern of yours... so feel free to do whater you want/need with the tool. Period.

 

tclover ... well, if I had some idea of what the "formaer" (sic) and "latter" in my above quoted text was was I'd probably understand what on earth you're trying to say. Anyhow, right now it seems that you're not really engaging with any substantive point so there's really nothing more to say. Note that you've not made the case for using mkinitcpio-II any stronger, in fact you've weakened it.

best ... khay

----------

## tclover

 *khayyam wrote:*   

> (...) mkinitcpio-II (...)

 

How many times did you used that name? Sir, you're completely mistaken... because I wasn't talking about mkinitcpio*. Period, a **bold** one: NO NEED TO EVER COME IN THIS THREAD AGAIN.

----------

## khayyam

 *tclover wrote:*   

>  *khayyam wrote:*   (...) mkinitcpio-II (...) 
> 
> How many times did you used that name? Sir, you're completely mistaken... because I wasn't talking about mkinitcpio*. Period, a **bold** one: NO NEED TO EVER COME IN THIS THREAD AGAIN.

 

tclover ... mearly a misidentification on my part, I of course meant mkinitramfs-ll, easy enough mistake to make. Now, did anyone think for one second I was *not* talking about mkinitramfs-ll ... no. So, while you're acting all indignant about a trivial matter you again omit to reply to the substance of the issue, because of course you can't, your full of bluster and that's about it. Good luck with that attitude, I'm sure you've put a lot of people off checking out mkinitramfs-ll ... if only due to your behaviour.

best ... and hopefully this is indeed the last I hear of it ... khay

----------

## msst

No need to go into a flame-war over the best tool. They both work fine.  :Cool: 

And I have to thank both khay and tclover for the helpful remarks. I have it all running now. Both better-initramfs / mkinitramfs-ll and my own little script works now.

In the end what I had to do was instead trying to unmount /dev I needed to mount -move it to the new root. Leaving it mounted makes the rc scripts run amok.

And after that I needed to also recompile xorg and its grafic drivers, as compiling the drm and radeon module into the kernel seems to have changed something there as well.

Phew, really much work to get this going. If someone wants it easier use one of the above mentioned initramfs builder solutions. Much easier than hacking that together oneself. And forget any recipes posted anywhere with a small "init" script. That is what I started from - did not work really. Neither did genkernel or dracut for me. Stick to better-initramfs or mkinitramfs-ll.

----------

## tclover

It was not my intention to go into the "better tool" "war"... even if I won't be surprised if khay state otherwise. As he pretty much stated my "supposedly" bias _for_ mknitramfs-ll _quickly_ and then rejected entirely the "tool" entirely because of... "my mistakes",--there are certainly _more_ than typos on my side but... there are, certainly, more than _a_ mistake in his side as well.

To make a _short_ story short, I've just recommended mknitramfs-ll with something short: flexibility--which khay _named_ bias right away. And then I stated _a_ reason,--build an initramfs on a disfunctional/incomplete system,--as advantage of better-initramfs. This was not supposed to be complete list of advantages of both project, I've just picked _one_ that stands out on both side.

However, khay just kept pushing in a defensive way as if I was putting his dear _tool_ in a corner to make it look differently than it _really_ is. And then, I picked a _valid_ issue along the way (AUFS+SquashFS+XATTR) because it has the kernel module+utils update requirement (that makes updating the initramfs _required_ in any case.) But this just ended... in a momentum that seemed like a complete rejection because of, first--my _bias_, second--_my mistakes_ and third--_my behavior_; when, in fact, I've just ended the discussion with a _complete_ rejection of his position with... something he just used _himself_ for... a _complete_ rejection: _a mistake_.

No war, no flame needed here.

----------

