Closed lockheed closed 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
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?
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.
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).
In addition, when you don't use oroot (just leave it out of the cmdline), do you boot fine?
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.
I don't see a picture.
Also, can you tell me the version of your util-linux? (pacman -Q util-linux)
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/
Your version of util-linux may be too old. The current version is here https://www.archlinux.org/packages/core/x86_64/util-linux/
When util-linux inherited zramctl, it completely changed zramctl's command line options; I followed suite.
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.
What's your version of util-linux?
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
Try not using resume
After you did the update, did you rebuilt your initramfs?
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.
All right, try removing the resume section in the kernel cmdline and verify if you still have the same issue.
Looking at the fact that you use an encrypted swap, do you use LVM?
Can you also post your /etc/mkinitcpio.conf?
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:
MODULES="dm_mod dm_crypt zram ext2 btrfs overlay aes_x86_64 sha256 sha512 radeon"
BINARIES=""
FILES=""
#
#
#
#
#
HOOKS="base udev plymouth plymouth-encrypt autodetect oroot modconf block keyboard keymap lvm2 resume filesystems"
I haven't tested lvm support yet, but I suggest putting oroot after lvm2. LVM may need to set some stuff up first.
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.
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.
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.
This seems to be due to the cleanup_hook in udev
Actually, scratch that.
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.
Similarly, adding sleep 5s before "$mount_handler" /lroot allows oroot to function. So I can confirm it is a race condition due to udev.
Please update to the latest code. I've included a poller to wait for the udev device.
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.
Few more details:
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.
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.
fixed in a4eac82c788d8c961c76c195b2e303a8affe73de
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:
It then proceeds to autologin (I have autologin and X autostart), but crooks out like so:
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
/etc/fstab
Can you help?