# HOWTO: initramfs with optional RAID|LUKS|LVM|TOI|AUFS

## tclover

NOTE: deleted (as of 21 june 2012 at 11:41 AM) that old post which I would not update...

interested users can follow the link of the repository is here.

----------

## tclover

Beware that rootfs default mount options added on 2011-06-17 should not be empty! If you don't want to have `noatime' as default mount option for rootfs and nothing instead, just reverse the line, where lv_mtopt is defined, to the way it was before--with the script of 2011-06-16 for example--with a conditional expression, otherwise mounting rootfs will fails! You're warned! A single mount option is required if you remove `noatime' before `$lv_mtopt'.

EDIT: This is not true anymore if you grab the second release! If you want noatime mount option for rootfs and aufs branches you know what to do!

----------

## tclover

UPPATE: cleaned up the mess of bb-initrd.sh and initrd-ll.sh main initramfs building scripts. Somebody managed to make use of the old ones? LOL. There were and still there IS no warranty at all! Now, one should fetch the initramfs-luks-lvm-sqfsd.git ones instead of those posted above. I'll clean up a little of that huge post latter... just imagine what i have to undergo to find what i have to update.  :Very Happy: 

----------

## tclover

UPDATE: commit d951240 following minor commits update ended up by... a major upate of the building scripts--busybox and initramfs--, and a root/build.sh was added to ease the building of the two step. I don't remember where is located the applets of busybox in the building directory otherwise I could add a `cp */applets $PWD/bin-amd64' in build-busybox-ll.sh'--I wouldn't build a new bb to find out the location of the applets would I? I guess the building tools/scripts are more polished/finished now... but that applets copy and may the long sed cmd in that same script could hang on. Let me know of both thing and I'll fix them in a commit...

----------

## tclover

As of today, the scripts that were on the first post where deleted as I'm not going to update the same thing in multiple places--git make it easy to maintain, update and get a updated clone in no time. There's no reason to keep outdated stuff there. I guess now I had adressed the major bottleneck that make editing the building tools of initramfs/busybox necessary after adressing the init script main features and sqfsd-rebuild which were already quite complete for a long time now, in fact only minor fix/editing was made since... Now one can easily build his/her initramfs seamlessly in his/her location of the cloned repository. One has only to make sure that a static gpg-1.* binary is copied over bin-amd64 and a static busybox with its applets and generated *.bin keymap. Once that material is copied over there, one could build an initramfs with running ./mkinitramfs with or without any argument--one can choose to build for a specific kernel or default will be for $(uname -r) with an optional extra version string--and the built initramfs will be built to /boot/kernel-$(uname -r)-ll-initrd.xz by default or with your kernel version and an appended extra version!

That's all.

----------

## tclover

I've went into updating the build scripts--gnupg, busybox, initramfs-ll--and sqfsd-rebuild to make use of optional arguments instead of positional argument which were a bit annoying.

Now each scripts has version string and help arguments. Just run one with `[-h|--help] [-v|--version]' to get going and got usefull information about the optional arguments.

If one run build/gnupg script without an optional argument, the script will just build a static gnupg-1.4* asap--this is in intent of this script isn't it?

Now, f one run build/busybox without an argument, nothing will happen, or rather with the latest commit print the help. This was introduced with the fact that now build/busybox can be used to build obviously a static binary or to generate a keymap [unicode compatible if need be] from a busybox binary. So builld/busybox need at least an argument to build a binary or generate a  keymap from a binary. There are optional parameter to build a minimal [-m|--minimal], install busybox or not [-i|--install] or input an ARCH for uClibc build.

The major update is build/initramfs-ll which went into a complete rewrite. Now there's a misc/initramfs-ll.conf file which can be modified to one liking about almost everything that can be included in the initramfs. Now, the script will copy the fsck.<rootfs> binary and dependency library obtained with `ldd /sbin/fsc.<rootfs>' from FSCK variable (defined in misc/initramfs-ll.conf) which can be list of FS!

Now one can run `build/initramfs-ll -f[|--full]' to build an initramfs for kernel $(uname -r) if K_VERSION is not defined with full support for LUKS+LVM2+GPG. 

EDIT3: if runned without an argument and with default config file provided, it build an initramfs with LUKS only support! GPG+LVM2+AUFS2 support should be explicitly appended to the command line, else enable them in the configuration file (iAUFS=y, iGPG=y and iLVM=y) or else the easy way for those three is to append a `-f[|--full]' optional parameter.

Finaly, build.sh is not functional anymore but who care about a two lines script anyway. If I update that one and introduce the previous changes, an easy ebuild could be written afterwards and will be included in my shared overlay. So everything could be done more automatically. Automatic is evil.... oh come on we're not yet on M$ area.

EDIT: beware that dependency library of fsck.<fs> may be not enough for other FS than ext* FS. For now I've just tested for ext4. Maybe copying the dependency libraries of those libraries may be required for, say, other FS like xfs, jfs, reiser{fs,4} et. al. I have those libraries installed on my rootfs but did not bother to check out. I will include a revision if need be, just report the issues.

EDIT2: And, of course, sqfsd/sqfsd-rebuild make use of optional parameters, one can change anything from command line easily now.

----------

## tclover

I have just added an ebuild for sys-boot/initramfs-ll-9999 (git based repo) the other day. More info on the ebuild/overlay is over there topic 889918.

Many changes went to the repository, check the commits for more info. I have fixed "echo msg disappearing issue" and clean up more than a little the init script but i will commit the newer version later as i have a (double) issue with the newer one--fsck.<fs> and mount just do nothing... VG/LV group is available, i can fsck.<fs> and mount the LV once forced to the minimal shell because of that issue; i added a few debugging lines to see what was happening and indeed the mapping just got printed out on th screen after a `die' as that should get printed before... i have no idea what is happening. Well, the thing is i removed most of, if not all, `$(echo $var|cut ...)' thing and the script should be mush more faster when it comes to parse arguments/variables... it may be the cause of it but i cannot think of something.

EDIT: and yes, anyone should get the newer building scripts as those new one fix many issues moreover being very handy than ever before which i won't write on a ChangeLog... it'll be to long for my taste. An ebuild make it very easy now! moreover with the git repo one can see the changes and decide to update or not.

EDIT2: and there should be a major fix for TOI and closing LUKS PV after a failure to mount rootfs for the next release.

----------

## tclover

init script went into several updates, clean up and fixes. A single issue remains--fsck dies for some reason, the same was true for mount (for rootfs). It seems echo-ing a value at the end on exec_cryptsetup() and/or exec_lvm() was the source of it... well at least partially. In an update I have switched to exec_cryptsetup() to echo `/dev/apper/$mapping' instead setting global variable removing this solved a sort of racing/lagging in echo-ing messages, so `/dev/mapper/$mapping' go to `mount -t $rootfs -o $mount_opts /dev/mapper/$mapping /newroot' in time. This revert did not solve the issue of fsck, I have thought to remove the echo-ing of `/dev/mapper/$VG-LV' at the end of exec_lvm() hopping to solve fsck failure to no avail.

Still following? Anyway, so no fsck for this release, or rather don't use it... or else... one would be dropped to a minimal shell and be forced to fsck, mount rootfs and then sys related squashed dirs and then switch root manually. That's not too time consuming to do if one need to fsck rootfs. I had thought to delay this release, until when?, as it fixes many issues... splash wasn't working for sure in the previous releases I did not notice it as I don't use any splash at the moment, and maybe TOI is either fixed or messed--it was working before. See the commits for more infos.

----------

## tclover

I have fixed the fsck failure issue and commited the changes to the repository, now, finally everything should be functional. I will add a new tag for this release later. I have previously fixed mkifs-ll_gen which was still using old scripts names (initramfs-ll instead of mkifs-ll sigh... that name change brought too much hassle, sriously), so when trying to make use of mkifs-ll_gen to build everything... nothing would happen. Although one could still build everything using the other scripts. Well, that was an easy fix and as that script hasn't much contains one could have spotted the issue easily. Anyway, here comes v0.3.5 release!

NOTE: you're welcome solemeni.

EDIT: And yes, now the applets is not mandatory, if there's not an applets a `busybox install -s' would be commented in from the init script. Checkout the commits for more info.

----------

## tclover

There's a bug with the previous release, `ikmap' need an extra colon `:' even if there's no font appended after the key map! just append a colon `:' to avoid it. I will fix it latter.

----------

## tclover

I commited a fix for `ikmap=<kmap>:' mandatory colon `:' issue, that commit should fix it, if not... append one again. I've just seen a peculiar failure after rebooting yesterday with that fix so I rm-ed my previous initramfs for new ones. I did not reboot yet.

And yet another mkifs-ll important update! I cleaned, again, the script. Now one has to only append module names to MODULES array group and the script will take care of copying the modules and `echo $module >> /etc/modules/$group' without any additional hassle if the modules exist, if not a message will be printed as warning but the initramfs build will keep going. So FS variable was thrown away in favor of MODULES/MOD. I guess I could threw away MOD variable as well... but I'm not sure if one can make use of it by putting modules dependencies into it, so the $group won't be stuffed with numerous modules. Well, I don't know if busybox modprobe applet take care of that nicely. Still not decide to keep it yet not knowing that.Last edited by tclover on Fri Sep 09, 2011 12:02 pm; edited 1 time in total

----------

## tclover

And... the ebuild package was renamed after... enter sys-boot/mkinitramfs-ll (sys-boot/initramfs-ll is gone). I guess I'm done with name changes... untill next time.  :Very Happy: 

----------

## tclover

 *master 1560ab5->98ca002 wrote:*   

> init update to parse [real_|]init=* arg so one can test/switch to OpenRc/Systemd; and initrd prefix/name change so grub-1.9x might find the initramfs in /boot

 

----------

## tclover

I've just added a stable ebuild which will track the latest stable master branch because some scripts will be broken while updating this and that. I cannot possibly, well I could with a little effort, update the whole stuff or possibly think twice, maybe three times, before pushing updates that would possibly broke other scripts. Anyway, the scripts aren't difficult to debug because they're pretty plain, really there's nothing much in them, they might be a bit long but that's all. So for those who do not want to risk a few sec to lose to debug a script, just grab the latest stable TAG or ebuild and everything should be fine. 

And, I've pushed a mkifs-ll (zsh script) on devel branch, I won't update the other ones to zsh because there's virtually nothing to simplify/gain.

The good news is that, now, FSCK, SPLASHS and FONTS variable are somewhat "arrays", I say somewhat because they really aren't, so one can add more than one spalsh theme, font and fsck.$fs without worrying about which fancy splash themes/fonts or fsck(s) binary-ies get included in the initramfs.

----------

## tclover

 *master 6635c08 wrote:*   

>  sys-boot/mkinitramfs-ll-0.3.5_p20111020 revision bump. i am just having a peculiar issue with sandbox... i cannot merge -9999 version without accesses violation while i can with the other ebuild(s)! anyway, everything should be rock stable with this one 

 

Talking about a peculiar issue...

Notable changes: now x86 users won't need to modify/change the lib64 directory/symlink as now the script take of that. And a failure to copy splash(s)/font(s)/keymap(s) won't stop/halp the script as those one can append more than one at a time.

NOTE: what is the amd64 string arch with amd64 no-multilib? I could easily add that case if...

----------

## tclover

Finally, I've just changed the name of repository to mkinitramfs-ll! so now old links with `initramfs-luks-lvm-sqfsd' should be changed to `mkinitramfs-ll', hopefully it's short to write.

What's new?

Well, the zsh migration of the devel branch is now complete for mkifs-ll{,.conf,_{bb,gen,gpg}} and sqfsd/sqfsd-rebuild (aka sdr). So those who prefer to play with zsh scripts instead of bash's or plain POSIX may grab those new ones.

The update went with a few features added here and there. There's a new kernel cmdline argumment imod=* that can be used to load extras modules with the boot module group.

mkifs-ll went through minor fixes.

sqfsd/sqfsd-rebuild (or sdr for short) went through severals updates that should make it easy now to add the script to cron job(?). Well, there's an offset argument `-o [|--offset=]<int>' that can be used to rebuild squashed dirs based on the ratio (percentage) of the aufs rw branch (on the ro one); and the script *should* take care of handling util-linux updates... when `cp' command and its dependency libraries get updated meaning that `cp' will fail to copy over/update the underlying files linked to it--I still had to update that package, util-linux, to see if the new fix is effective;--and there's a new  `--arch=', `--arch=32' for example, for handling `/lib$ARCH/rc/init.d' and `/lib$ARCH/splash/cache' for x86 users without modifying the script.

EDIT: And there's a zsh USE flag for the stable/tarball ebuild to grap zsh scripts instead of bash ones. 

Am I the only whose having issue to merge live ebuils (git) with the new sandbox update? I tried to rmerge an old one to no avail...

----------

## gw

tclover:

Thanks a lot for your continuing work on this! Very much appreciate it, as full root encryption is such an important issue, escpecially on laptops!

Is the support thread (https://forums.gentoo.org/viewtopic-t-370023.html) still functioning? I was posting some questions there recently.

As I'm trying to follow your setup, my main issue with your scripts is the following: can I use the init unmodified when I'm neither using lvm, hibernation, or squashed dirs? I'm just trying to get an initramfs up and running that decrypts my luks encrypted, btrfs formatted root, and then switches to it. As I am no programmer, I am having kind of a hard time exactly understanding what your init does  :Smile: 

Thanks for your help (and coding!)

gw

----------

## tclover

 *gw wrote:*   

> As I'm trying to follow your setup, my main issue with your scripts is the following: can I use the init unmodified when I'm neither using lvm, hibernation, or squashed dirs? I'm just trying to get an initramfs up and running that decrypts my luks encrypted, btrfs formatted root, and then switches to it. As I am no programmer, I am having kind of a hard time exactly understanding what your init does 

 

You can of course. Well I tried to make the title understandable by putting `+' or logical `or' to some extend meaning that you can use a feature by putting the right kernel cmdline. If you don't put a kernel cmdline argument (of a particular feature), that's mean you don't use that particular feature. Maybe I should repace the `+' to `|' which might be more clearer(?) The only limitation is... using unencrypted PV(s) or Physical Volume(s) which is possible for rootfs only, swap and resume (TuxOnIce) should be at least used with encrypted PV(s) or LVM2 LV(s) (Logical Volume) if you like.

And for the topic, I don't know, the script that Reikinio posted on the wiki wasn't updated for ages. I've just took it and tried to adapt it to my needs which grow over time. Once again, almost everything is optional to some extend but the unencrypted PV(s) case, but hey, that's quite logical because the goal of the script is bringing userspace from LVM2[and|or LUKS] or something near that. It's not a general purpose initramfs building tools that one can find out there. That being said, you can use it for a general purpose without TuxOnIce encrpted file|LV|PV requirement because a swap file|LV|PV can be taken care of by dmcrypt init service.

EDIT: Anyway, there's not enough place in title to be more clearer, so the `+' just made their way trough without any choice.

EDIT2: you should take the latest sdr[|sqfsd-rebuild] or the live ebuild if you can merge it, I cannot even if the Makefile is identical in every way, which fix an evaluation for the offset feauture/parameter.

----------

## gw

Hi tclover, thanks for your quick response here and on the "System Encryption DM-Crypt with LUKS" thread!

Actually, for me "|" instead of "+" would have been clearer! but it doesn't matter as it is being made explicit here now anyways.

Please keep up the good work on this project! I think it would help a lot for people like me, if the decisive init script contained more comments on what it is actually doing. Or a simple overview explication of the proceedings in plain english.

Actually for me, the challange in following the wiki "DM-Crypt with LUKS" was, that is is trying to make so many things at the same time. I do appreciate the overall solution, as it offers very useful features, but a more straightforward simple solution to start with would also help a lot. From that first solution one could then explore more sophisticated solutions. Perhaps one could also emphasize more the fact, that, as complicated and flexible the init script might be, it also serves the most simple setups (e.g. encrypted root + passphrase).

For example, I was wondering what the advantage of lvm would be if I'm only planning to have /boot /swap and root partitions: is it better to do these with lvm instead of making actual physical partitions (as I did now on my, hopefully!, dual boot, gpt-partitionned MacBook pro)?

Thanks again,

gw

----------

## tclover

Well, updated the thing again with a new optional goodie. Previous `ichkpt' cmdline argument became `ishrl' (for i[nit] s[hell] r[un]l[evel] if that matters). ishrl has the old same behaviour to drop to a minimal shell runlevel when something like `ishrl=3f' (and yes the runlevels were renamed... 3<d|f|m> [<decrypt|fsck|mount>] for root 2<s|r> [<swap|resume>] 4<c|u|s> [<clean|umount|switch>]) will drop to the minimal shell just before fsck-ing rootfs, `ishrl=4m' just before mounting rootfs and after fsck-ing rootfs if and only if you appended something like `iroot=root-myVG:c:ext4' (you have to enable fsck of course!) for an ext4 rootfs with a LVM LV (Logical Volume) within `myVG' VG (Volume Group). 

Or else append something like `ishrl=:2', notice the collon `:', and the argument `2' will be passed directly to `/sbin/init' and your machine would be brought to `nonetwork' level or with `ishrl=:1' to `single' runlevel. Systemd users... maybe a `ishrl=:--crash-shell' may be of use? I thought systemd was so much better in every aspect compared to OpenRC as some are saying. I have no idea how one can boot to something similar to OpenRC runlevels.

WARN: do not append whatever you like if you don't want a kernel panic!

And yes, I added this because I found myself, too often to my taste, being forced to drop to the minimal shell just to run `exec switch_root /newroot /sbin/init <n>'! Now, saved to trouble myself for a silly think like that.  :Very Happy: 

So reading README and ChangeLog maybe of use for [some]body.

NOTE: new ebuild/tags[|tarball] are available.

You may be right gw, but this is not a HOWTO that goes to explain every single details in a more understandable manner for those who are not seasoned, at least a little, to LUKS/LVM--there'are better HOWTO out there--... it'll be too much of hassle, but instead try to make/add more fexibilty for a *usable* init script for different scenarios/hardware/profiles. Just take a look of how long everything is compared to a simple short *static* init script that will just fit a single usage/user... Things could be improved, but this HOWTO require that the user know what [s]he doing and not rely on automatic script which should fit for every *user*.

----------

## tclover

```
*2011-11-24:

    * added UUID|LABEL for any PV encrypted or not, remdev or `/boot' PV;

    * now ilvm argument can simply be a comma separated list of files in 

      remdev or `/boot' device which can be a line seperated list of PVs;

    * added a sort of "executing" user scripts for each shell runlevel;

    * added LVM2 support for unencrypted PVs, meaning that swap and/or resume 

      [file(s)] can be on unencrypted PVs and root of course;

      in this case a single word or character is enough in ilvm argument to

      activate LVM, no need for PV list in this case;

    * added cryptsetup-1.4.1 support (loop files, detached header); and fixes.
```

----------

## tclover

I pushed two tags--v4.2_zsh-r2 for zsh scripts and a v0.4.2_bash-r2--there's nothing really but license changes: i added CC BY-SA-2.5 to get an init script more fitted for the gentoo unofficial wiki and 3.0 for the official (this version was already there) and GPL-2 for GPL-3 haters and i may add a bsd 4 closes license later.

Those scripts should be more readable than before, especially the long init script. The others tools may not at first glance because of the use of a single array for any options provided by the script: this was a good move to ease the management of multiple variables.

NOTE: I may not update the unofficial wiki page beside the broken github links. And I might contribute to a new article in the official wiki but I do not want to write the whole article.

NOTE2: I edited the ebuilds and the tags name to not force users to remove manually the old tarballs which was necessary for a while now.

----------

## tclover

I've just added a 2-clause BSD license.

----------

## tclover

I've commited the other day RAID support to the scripts (init and mkifs-ll initramfs building script).

So now, one can use [LUKS+]LVM on top of RAID arrays but not the opposite. 

One can build an intramfs with mdadm binary and kernel module for RAID with an optional `/etc/mdadm.conf' file enbeded to the initramfs. An optional file because one can use a kernel cmdline argument like `iraid=md<u>-UUID=<uuid>-<v>' with <u> the RAID array and <v> the partion number used to assemble an array. Say, md0 is an array build on /dev/sd[abcd]1 would be `iraid=md0-UUID=<uuid>-1' and everything will go as expected just like the other cmdline arguments.

----------

## tclover

fix release which bring thousand of lines of update and fixes... I've just noticed that a few command line options weren't listed a few scripts which caused infinite loop (for bash version). 

Last bits of update are in the tree.

----------

## d-fens

hi,

i'm trying to get a new nas serverup with following layout

/dev/sda1 boot ext2 

/dev/sda2 luks crypted partition

mirrored on sdb

so i need the initramfs to first decrypt /dev/sda2 and /dev/sdb2 and then create the zfs pool containing everything needed from /dev/mapper/crypt-a + /dev/mapper/crypt-b

i tried with genkernel but it just seems to allow luksopen one device, and not two (or more)

is this the tool i need to get it running and do you have any hints?

----------

