bluerider / liveroot

Initcpio hooks for overlayfs ontop of root
BSD 3-Clause "New" or "Revised" License
79 stars 13 forks source link

Configuration issue #6

Closed lockheed closed 9 years ago

lockheed commented 9 years ago

Hi bluerider.

A very interesting project, alas I found no documentation that could help with problems I experience while trying to set it up.

I have 3,5GB ram and LUKS-encrypted root partition (which also contains 'home' folder). I followed the instructions displayed after installing the package from AUR, added the HOOKS and MODULES and run "mkinitcpio -p linux", but the system does not boot properly.

The list of errors during boot:

Failed to start Load/Save random seed. Failed to start Rebuild Hardware Database. Failed to start Rebuild Dynamic Linker Cache. etc, etc...

It then proceeds to autologin (I have autologin and X autostart), but crooks out like so:

xauth: error in locking authority file /home/user/.Xauthority Fatal server error: Cannot move old log file /var/log/Xorg.0.log to /var/log/Xorg.0.log.old and then drops to command line.

I proceed to investigate from command line, but "ls /" returns nothing, and Midnight Commander starts within home folder, but is unable to exit it. So I think there is something wrong with root being mounted.

Here are my config files:

syslinux.cfg

LABEL archRAM MENU LABEL Arch Linux RAM LINUX ../vmlinuz-linux APPEND root=/dev/mapper/crypt-root cryptdevice=/dev/disk/by-uuid/088a724f-1947-4655-b4ce-fe99fc3f6a06:szyfr oroot=compresssed rw quiet splash resume=/dev/mapper/crypt-swap INITRD ../initramfs-linux.img

/etc/fstab

/dev/mapper/crypt-root / btrfs noatime,autodefrag,compress=lzo,space_cache 0 0 /dev/sda3 /boot ext2 defaults,rw,relatime 0 0 /dev/mapper/crypt-swap swap swap defaults 0 0 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0 tmpfs /home/user/.cache tmpfs noatime,nodev,nosuid 0 0

Can you help?

lockheed commented 9 years ago

On 25/03/15 15:21, bluerider wrote:

What's your kernel cmdline?

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86047622.

Hi,

As per my post:

root=/dev/mapper/crypt-root cryptdevice=/dev/disk/by uuid/088a724f1947-4655-b4ce-fe99fc3f6a06:szyfr oroot=compresssed rw quiet splash resume=/dev/mapper/crypt-swap

bluerider commented 9 years ago

Oh yes, I removed the comment once I fully read your post.

Can you remove quiet and add break to your kernel cmdline? Then run ls /lroot. Post the contents here?

lockheed commented 9 years ago

On 25/03/15 15:29, bluerider wrote:

Oh yes, I removed the comment once I fully read your post.

Can you remove quiet and add break to your kernel cmdline? Then run ls /lroot. Post the contents here?

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86050597.

It boots into rootfs, but I cant type anything sensible because the letters I type are invisible, and when I hit enter, the error report is never what I typed in. For example, I type in blindly ls /lroot but the error message says l: unknow command or lro: no such file

etc, etc.

bluerider commented 9 years ago

Can you change the kernel cmdline as per my suggestions for debugging? The issue is if /lroot is being mounted but zramctl fails to build the ram block. Also make sure you're using the most recent code (updated 3:38 EST) since it fixed an issue with util-linux (undocumented change in zramctl behavior).

bluerider commented 9 years ago

In addition, when you don't use oroot (just leave it out of the cmdline), do you boot fine?

lockheed commented 9 years ago

Can you change the kernel cmdline as per my suggestions for debugging? The issue is if /lroot is being mounted but zramctl fails to build the ram block.

Yes, I did this and what I wrote in the previous mail was the result. I attached a picture of what I see after boot.

Also make sure you're using the most recent code (updated 3:38 EST) since it fixed an issue with util-linux (undocumented change in zramctl behavior).

Yes, I installed first time 2 hours ago and now I reinstalled it just to be sure.

In addition, when you don't use oroot (just leave it out of the cmdline), do you boot fine?

Yes. Regular kernel line boots just fine.

bluerider commented 9 years ago

I don't see a picture.

bluerider commented 9 years ago

Also, can you tell me the version of your util-linux? (pacman -Q util-linux)

lockheed commented 9 years ago

On 25/03/15 16:27, bluerider wrote:

Also, can you tell me the version of your util-linux? (pacman -Q util-linux)

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86081937.

util-linux 2.25.2-1

Picture is here: http://postimg.org/image/uptik3hr7/

bluerider commented 9 years ago

Your version of util-linux may be too old. The current version is here https://www.archlinux.org/packages/core/x86_64/util-linux/

bluerider commented 9 years ago

When util-linux inherited zramctl, it completely changed zramctl's command line options; I followed suite.

lockheed commented 9 years ago

On 25/03/15 16:33, bluerider wrote:

When util-linux inherited zramctl, it completely changed zramctl's command line options; I followed suite.

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86083866.

Hi,

I updated util-linux and reinstalled everything. Still the same problem.

bluerider commented 9 years ago

What's your version of util-linux?

lockheed commented 9 years ago

On 25/03/15 19:08, bluerider wrote:

What's your version of util-linux?

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86153423.

I did full system update. It is now

$ pacman -Q util-linux util-linux 2.26.1-3

bluerider commented 9 years ago

Try not using resume

bluerider commented 9 years ago

After you did the update, did you rebuilt your initramfs?

lockheed commented 9 years ago

On 25/03/15 19:52, bluerider wrote:

After you did the update, did you rebuilt your initramfs?

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86170585.

Yes.

bluerider commented 9 years ago

All right, try removing the resume section in the kernel cmdline and verify if you still have the same issue.

bluerider commented 9 years ago

Looking at the fact that you use an encrypted swap, do you use LVM?

bluerider commented 9 years ago

Can you also post your /etc/mkinitcpio.conf?

lockheed commented 9 years ago

On 25/03/15 21:01, bluerider wrote:

Can you also post your /etc/mkinitcpio.conf?

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86196172.

Yes, I am using LVM. Here's /etc/mkinitcpio.conf:

vim:set ft=sh

MODULES

The following modules are loaded before any boot hooks are

run. Advanced users may wish to specify all system modules

in this array. For instance:

MODULES="piix ide_disk reiserfs"

MODULES="dm_mod dm_crypt zram ext2 btrfs overlay aes_x86_64 sha256 sha512 radeon"

BINARIES

This setting includes any additional binaries a given user may

wish into the CPIO image. This is run last, so it may be used to

override the actual binaries included by a given hook

BINARIES are dependency parsed, so you may safely ignore libraries

BINARIES=""

FILES

This setting is similar to BINARIES above, however, files are added

as-is and are not parsed in any way. This is useful for config files.

FILES=""

HOOKS

This is the most important setting in this file. The HOOKS control the

modules and scripts added to the image, and what happens at boot time.

Order is important, and it is recommended that you do not change the

order in which HOOKS are added. Run 'mkinitcpio -H ' for

help on a given hook.

'base' is required unless you know precisely what you are doing.

'udev' is required in order to automatically load modules

'filesystems' is required unless you specify your fs modules in MODULES

Examples:

This setup specifies all modules in the MODULES setting above.

No raid, lvm2, or encrypted root is needed.

HOOKS="base"

#

This setup will autodetect all modules for your system and should

work as a sane default

HOOKS="base udev autodetect block filesystems"

#

This setup will generate a 'full' image which supports most systems.

No autodetection is done.

HOOKS="base udev block filesystems"

#

This setup assembles a pata mdadm array with an encrypted root FS.

Note: See 'mkinitcpio -H mdadm' for more information on raid devices.

HOOKS="base udev block mdadm encrypt filesystems"

#

This setup loads an lvm2 volume group on a usb device.

HOOKS="base udev block lvm2 filesystems"

#

NOTE: If you have /usr on a separate partition, you MUST include the

usr, fsck and shutdown hooks.

HOOKS="base udev plymouth plymouth-encrypt autodetect oroot modconf block keyboard keymap lvm2 resume filesystems"

COMPRESSION

Use this to compress the initramfs image. By default, gzip compression

is used. Use 'cat' to create an uncompressed image.

COMPRESSION="gzip"

COMPRESSION="bzip2"

COMPRESSION="lzma"

COMPRESSION="xz"

COMPRESSION="lzop"

COMPRESSION="lz4"

COMPRESSION_OPTIONS

Additional options for the compressor

COMPRESSION_OPTIONS=""

bluerider commented 9 years ago

I haven't tested lvm support yet, but I suggest putting oroot after lvm2. LVM may need to set some stuff up first.

lockheed commented 9 years ago

On 25/03/15 21:05, bluerider wrote:

I haven't tested lvm support yet, but I suggest putting oroot after lvm2. LVM may need to set some stuff up first.

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86198175.

The root has to be inside LUKS container, and because I am using btrfs, I have to use LVM to divide LUKS container into partitions.

BTW, I just tested after resuming resume=. No change.

bluerider commented 9 years ago

Okay. You can keep resume, just move oroot to occur after lvm2 in your hooks in /etc/mkinitcpio.conf and verify if it works or not.

bluerider commented 9 years ago

I just set up a similar system, I'm not able to mount root since it can't find it. It seems that the position of lvm2 doesn't matter since it's an early hook. Oroot fails to mount the root device on lvm becuase it can't find it. When this occurs if one does ls /dev/mapper; one does see the root device. However, modifying the oroot hook to ls /dev/mapper reveals no such device (but the LVM storage group is mounted). Moving oroot around doesn't seem to change this behavior.

Something must occur between break and running hook functions that maps the lvm devices.

bluerider commented 9 years ago

This seems to be due to the cleanup_hook in udev

bluerider commented 9 years ago

Actually, scratch that.

bluerider commented 9 years ago

Adding : launch_interactive_shell just before "$mount_handler" /lroot allows oroot to boot fine (you'll need to press exit). I think we're looking at a race condition here.

bluerider commented 9 years ago

Similarly, adding sleep 5s before "$mount_handler" /lroot allows oroot to function. So I can confirm it is a race condition due to udev.

bluerider commented 9 years ago

Please update to the latest code. I've included a poller to wait for the udev device.

lockheed commented 9 years ago

It works!

The only error I get on boot is something like "Failed to start common transient on machine-id on disk."

However, it boots into the system and desktop session starts.

Now, I have few questions about how liveroot actually works and what is it supposed to do.

I run "htop" and I can see that the system occupies as much RAM as when not using liveroot (~600MB out out 3330 MB total). The only change I can see is that my swap space went from 3300 MB to 4630 MB.

Also, every program start as slow as after normal boot, and also when they start, the HDD LED lights up indicating disk read.

So I see no difference from not using liveroot.

Can you explain?

Many thanks!

On 26/03/15 00:44, bluerider wrote:

Please upload to the latest code. I've included a poller to wait for the udev device.

— Reply to this email directly or view it on GitHub https://github.com/bluerider/liveroot/issues/6#issuecomment-86254440.

lockheed commented 9 years ago

Few more details:

  1. The non-critical error I mentioned is: "Failed to start commit on transient on machine-id on the disk."
  2. The system is definitely running from overlayfs as indicated by the output of $ mount command.
  3. overlay_flush command does not exist in the system.
bluerider commented 9 years ago

The transient machine-id is an allowed error in systemd. It's not important. Regarding how liveroot works; it generally works by reading from disk but writing to ram. The compresed and raw mode works this way except compressed is a bit more clever since it might compress the data in ram to save space. If you want to run entirely off of ram, you'll want to use oroot=live. However, as per the warning in the install script in the AUR PKGBUILD, you need at least half the amount of ram as your root drive. So, if you haev a 4GB root, you need at least 2G of ram.

bluerider commented 9 years ago

If you run in oroot=live, you wont' be conducting I/O on disk for root. However, you use lvm so that means your swapdisk will still be used. When running as oroot=live, it's pointless to have hibernation to disk since the point is not to use page to the disk.

In addition, there's one more interesting piece of code from liveroot that I'm quite happy with. When running in an oroot mode, liveroot generates /usr/bin/overlay_flush. overlay_flush can flush the data from the overlay onto the backing disk. This means you can make some changes to root, if you do not like those changes, you could just reboot and they won't exist on root. However, if you do like them, you can use overlay_flush to write those changes to disk. Example, I want to test out gnome-shell. I run in oroot=compressed; install gnome packages. If I like Gnome I can use overlay_flush to write to disk, if I don't; I just reboot and I won't have gnome installed. It saves me the uninstalling step, possible SSD wear, and any backing disk logging.

bluerider commented 9 years ago

fixed in a4eac82c788d8c961c76c195b2e303a8affe73de