You don't need to unless you want to use something non-standard/built in for your root. In my case, I wanted everything on my system to be in lvm. That included swap and suspending/resuming from that swap. To do this, you need to use an initrd.

I tried your script in a stable system and everything worked perfectly afterwards was an attempt to implement all the same under baselayout2. Unfortunately, under baselayout2 I have nothing left. If memory serves me is not the error was

No volume groups found

and before that even when the assembly initrd-lvm2 script could not create the necessary device.

But if it still works then I will just glad. This means that where I had committed a mistake.
In any case, thanks.

Be sure to re-grab the script as it changed when I added support for baselayout2. The support for baselayout2 was only necessary for creating the initrd on a baselayout2 machine. The old script could boot a machine that had baselayout2 on it as long as the initrd was created on a baselayout1 machine.

If you get errors when running the script, you can assume that the script will probably not work right when booting the machine. In this case, send me the errors and I can try to help.

I had to make a slight modification to the script. Apparently TuxOnIce now suggests that its options be passed as resume=, rather than resume2=, and noresume rather than noresume2. I simply changed all occurrences of resume2 to resume, but since I believe both are still valid, you may want to write in a test for either of them...

would you consider putting your script under some version control, just mark each edit with a new version nr with some # comment line? i am assuming right now the script in the first post is the latest modified version, right.

as a side note - i now have a situation where i have some different configurations, some with raid, some with lvm2, some with both, some with luks included and i decided to move everything to tuxonice init script architecture - http://wiki.tuxonice.net/EncryptedSwapAndRoot

unfortunately this mechanism still lacks a good manual initramfs creation mechanism. right now i compile my initramfs into the kernel with the builtin mech, this lets me do a good build mechanism, but really sucks when you have to change something small in the init script.

but at the same time, stuff like uvesafb+v86d now uses the kernel builtin mechanism, so its kinda hard to move away from this too.

raffi, my vision is, that your script has been largely superseded in basic functionality when it comes to init, but it definitely has unique value in simply letting one create an initramfs quickly. ideally, that functionality would be integrated with tuxonice init mechanism, which in my view is the best (most functional) one available at the moment. it also needs only minor modifications for lvm2 + raid handling (which i already did on my systems). i dont see a point in having many of these different but same init scripts, i think everyone would benefit if there was an effort merger. ive already contacted alon lev bar (tuxonice) about this and he says all patches are welcome. the bad thing is i am not seeing any shared development tools, like repository and stuff, but perhaps all that could be worked out.

A quick look at the tuxonice page you posted a link to seems to me that we simply have two different goals. I'm using the same kernel mechanism that the tuxonice stuff is using. I just started with the lvm init scripts and modified things for my needs.

I have not been very interested in writing a generic do every possible thing initramfs, I've just added features that I have need of when I run into problems. Feel free to borrow/steal/re-write any portion as patches or add ons to the the tuxonice encryption stuff. If you come up with a generic way of adding features, I might end up switching

kernel config based on genkernel default config, only raid is builtin:

Code:

# grep RAID /usr/src/linux/.config
CONFIG_RAID_ATTRS=m
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_AACRAID=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
# CONFIG_MD_RAID0 is not set
CONFIG_MD_RAID1=y
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set

# grep DM_ /usr/src/linux/.config
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
CONFIG_BLK_DEV_DM_BBR=m
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set

- sys-apps/baselayout-2.0.1 was built with the following:
USE="(multilib) -build"
- sys-kernel/gentoo-sources-2.6.29-r5 was built with the following:
USE="(multilib) -build -symlink"_________________Optimism is solely an absence of information. / Optimismus ist nur ein Mangel an Information.
(Arthur Schopenhauer)

The job control message should not be a problem. If you add lvm2rescue to the command line, you should be able to type. You will need to either load the correct modules with the script, or compile in the correct disk drivers into your kernel. Not knowing what you are running, I can't tell you what that would be.

The job control message should not be a problem. If you add lvm2rescue to the command line, you should be able to type. You will need to either load the correct modules with the script, or compile in the correct disk drivers into your kernel. Not knowing what you are running, I can't tell you what that would be.

Given the above I can think of a reason to have swap not in a logical volume, but I can't think of a reason to have it in a LV. Root? Yes. Swap? ?

I did it because I can. Kind of like why people climb mountains.

As for how well it works, I usually have a small swap partition for emergencies only, ANY swap is way too slow. Memory is cheap enough now you should probably not be using it much any more. Not like the days when you wanted 2x swap to memory.

I am wondering if I still need to use suspend2-sources to use your method.

I also plan to eventually go with RAID-1 as well as LVM2 on the root filesystem, but for now I am just using a simple 320 GB drive. Since I have 8 GB, it is usually easier to sleep than to hibernate. Does your method support both of these?

I am wondering if I still need to use suspend2-sources to use your method.

I also plan to eventually go with RAID-1 as well as LVM2 on the root filesystem, but for now I am just using a simple 320 GB drive. Since I have 8 GB, it is usually easier to sleep than to hibernate. Does your method support both of these?

Thanks!

suspend2 has become tuxonice, so if you wanted to use it you could use tuxonice. As to NEED, no use whatever works for you. The tuxonice stuff allows suspend to work well, I have not tried with other kernels.