You are not logged in.
Salutations,
I have written a some initcpio scripts to take advantage of the new Overlayfs feature in kernel 3.18. Adding the hooks to /etc/mkinitcpio.conf and the kernel cmdline will allow one to boot into a non persistent mode. It is similar to a liveboot, but simpler in my opinion. Croot uses a 1GB compressed ramdisk on top of root, oroot uses a tmpfs disk (half total amount of ram) on top of root. Any changes when running this mode will be lost on reboot.
Offline
Well it's been a month since liveroot was first released. It now supports 3 forms of booting: live (run Arch Linux entirely on ram), compressed (run Arch Linux on a compressed ram block overlay), and raw (run Arch Linux on a tmpfs overlay). In addition, all these modes now generate a function called "overlay_flush". Overlay_flush lets one flush changes made on overlay (or on ram block device) to the backing disk. Why's this useful? Consider an OS that runs off of a USB. USB writes speeds are slow. One can run Arch Linux on one of these modes to avoid writing to the USB. When changes made are satisfactory, one can run overlay_flush to commit changes to the disk. One could easily turn this into a cronjob to do automatic syncing every hour or so.
Offline
Saw your post to aur-general the other day. Going to have to check this out sometime soon, it sounds really useful.
Offline
If we drop ISO support for the arch install img, we could just use liveroot + btrfs to generate a compressed installation img.
Easy to update, easy to modify.
Offline
Offline
Please pardon the lack of experience, but what is the difference between oroot=raw and oroot=live.
I'd like to make a Parted Magic-like USB that I can be removed once the OS has loaded and load on another machine.
I'd also like to have a separate entry in rEFInd that can used to update the OS. Would I have to make a separate initramfs-linux.img without the oroot hook or would I only need to have 2 entries (1 with and 1 without the kernel argument) and one initramfs-linux.img?
Offline
This is awesome!
Thank you Bluerider!
Para todos todo, para nosotros nada
Offline
Please pardon the lack of experience, but what is the difference between oroot=raw and oroot=live.
I'd like to make a Parted Magic-like USB that I can be removed once the OS has loaded and load on another machine.
I'd also like to have a separate entry in rEFInd that can used to update the OS. Would I have to make a separate initramfs-linux.img without the oroot hook or would I only need to have 2 entries (1 with and 1 without the kernel argument) and one initramfs-linux.img?
This is entirely possible. Please see the examples in /usr/share/liveroot.
You compile oroot into the initramfs but it won't do anything if you don't call it in the kernel cmdline.
Offline
The AUR package now recognizes the static compiler. Oroot started getting kind of ugly (well I didn't like how it was becoming) so I wrote a bash -> bash compiler.
1)When you use the AUR package it'll ask if you want to use the compiler. If you say "y", the installed oroot will be highly specific to your system based on what it read off the current kernel cmdline.
2) Now some may wonder what that "btrfs" option is... In order for that mode to work, one needs to have a subvolume called /snapshots and an initial snapshot of the root file system. When using the btrfs version, a snapshot is made everytime overlay_flush is called. That's pretty neat in my opinion.
Offline
To all, if it works for you; consider voting for the package!
I think it's abilities are quite good...but no one seems to know about it.
Offline
Please pardon the lack of experience, but what is the difference between oroot=raw and oroot=live.
Oroot=raw means use a tmpfs (no compression) overlay. Oroot=live means load all of root into compressed ram block (requires lots of ram, roughly half of root's size).
Offline
I've received a request on advising boot times using liveroot.
This is a really difficult concept when it comes to liveroot since it is entirely dependent on the read speed of root. Liveroot speeds up boot and running programs by writing to a ram block device instead of to disk. Otherwise it follows normal kernel cache policy meaning that it needs to read from stroage before caching the data. With that in mind, liveroot heavily benefits USB/SD based OS since they have low write speeds.
To get a rough measure of the speedup, divide the # of bytes needed to be loaded to reach userspace by the write speed of root. This should give you the # of seconds it takes to bootup.
In addition, liveroot doesn't only benefit bootup, since it writes to ram, it benefits all applications after they've been started up.
Since I run liveroot on a USB stick, I'd really rather not boot on disk (it will be excrutiating slow and waste my entire day).
Offline
Just to give an estimate :
Running on qemu with following parameters:
2.5G partition
1.8G allocated ram
USB : 32.3 MB/s read; 13.7 MB/s write; 1.56 msec access
zswap enabled
Gnome(X11) userspace
Note all times listed are in seconds
oroot=compressed : 12.657
oroot=live : 11.754
disk : 52.459
I only ran a single test because using QEMU confounds things (Linux disk caching system; I'm using zswap)
In general:
oroot=raw has the fastest bootup
oroot=live has the slowest bootup but fastest I/O (magnitudes faster)
oroot=compressed is a good compromise between oroot=raw and ram usage
Last edited by Bluerider (2015-04-18 19:46:46)
Offline
Some more estimates on real hardware (sample size = 1).
2.5G partition
4G DDR3 ram
USB: 93.3 MB/s read; 21.3 MB/s write; 1.16 msec
zswap enabled
Gnome(X11) userspace
With a sample size of 1 (n=1) and time in seconds:
oroot=compressed : 3.991
oroot=raw : 3.959
oroot=live : 2.699 (note, this doesn't include the 2:53.769 spent in kernel)
disk : 23.832
Offline
If i'm reading this correctly, then archiso already has support for overlay filesystems. At line 40:
# args: source, newroot, mountpoint
_mnt_overlayfs() {
local src="${1}"
local newroot="${2}"
local mnt="${3}"
mkdir -p /run/archiso/cowspace/${cow_directory}/upperdir /run/archiso/cowspace/${cow_directory}/workdir
mount -t overlay -o lowerdir=${src},upperdir=/run/archiso/cowspace/${cow_directory}/upperdir,workdir=/run/archiso/cowspace/${cow_directory}/workdir airootfs "${newroot}${mnt}"
}
Offline
Oh wow, that's interesting. Why does the arch iso use squashed FS then?
In addition, the kind of Arch ISO upgrade I'm talking about can be found in the btrfs version of liveroot. You can access it via the compiler. If you create a subvolume named /snapshots, you can use liveroot's overlay_flush generates snapshots. When you run in oroot=live mode, you will load the last snapshot which means you can now have multiple Arch ISO versions on the same ISO.
Updating the ISO would be a matter of updating and creating snapshots.
Offline
Oh wow, that's interesting. Why does the arch iso use squashed FS then?
Squahsfs is needed to compress the ext4 filesystem. Without squashfs the filesytem would be too big to fit on a CD.
In addition, the kind of Arch ISO upgrade I'm talking about can be found in the btrfs version of liveroot. You can access it via the compiler. If you create a subvolume named /snapshots, you can use liveroot's overlay_flush generates snapshots. When you run in oroot=live mode, you will load the last snapshot which means you can now have multiple Arch ISO versions on the same ISO.
Updating the ISO would be a matter of updating and creating snapshots.
I forgot to say that your contribution is very interesting. What you have explained here is not possible with the current archiso scripts. A problem is see is that ISO files are READ ONLY by definition, which means you can't update the ISO without generating a new one. What does work is copying the filesystem directly to a USB stick without using an ISO file though.
You have to consider that compressed btrfs filesytems compress each file individually, whereas squashfs compresses all the files in a filesystem at once into a single file. Thus squashfs has most likely a better compression ratio than btrfs compression. Would be interesting too see the size difference between both.
Offline
Why yes. I mention that using it for an Arch ISO would require dropping the ISO requirement and using a simple raw image.
Offline
I've got an idea for the arch iso topic. There are a lot of duplicated files in the x86 and i686 images of archiso, especially in the /usr directory. It could help to run the btrfs deduplication tool duperemove for space savings.
https://aur.archlinux.org/packages/duperemove
Offline
Interesting. We could also just package the duplicate files as a separate overlay layer and mount it during liveroot's mount.
Offline
You have to consider that compressed btrfs filesytems compress each file individually, whereas squashfs compresses all the files in a filesystem at once into a single file. Thus squashfs has most likely a better compression ratio than btrfs compression. Would be interesting too see the size difference between both.
Generally btrfs compression will be worse than squashfs since squashfs uses gzip and btrfs uses lzo/lz4. However, the flexibility one gains when using btrfs (as are most flexibilities with read/write systems) are more useful to me.
Offline
An interesting idea I had while running liveroot was the realization that pacman pkgs are compressed well with xz. One way to save space on a live usb would be to only sync the home folder with overlay_flush and then have a list of packages to install before starting up the system. I may offer that as a function of liveroot. It'll require the pacman cache.
Offline
The new option : oroot=package can be found in the packages branch of liveroot. It is only available by activating the compiler (bash compiler). Note, it is extremely experimental and not tested.
Last edited by Bluerider (2015-04-23 22:41:46)
Offline
The new option is basically done. There are some caveats.
Requires /var/cache/pacman/pkg to contain packages
Requires only one copy of each package (no old versions) in the cache
overlay_flush only syncs the home folder with oroot=packages
Here's some benchmarks on qemu with 1.8G ram, 2 cpu cores. All units are in (minutes:seconds)
oroot=live :3:07.21(kernel) 1.108(live)
oroot=packages :1:53.044 (kernel) 2.770 (packages)
Offline
Is their no documentation on how to actually use liveroot? Im kind of stranded on thread when looking throught the formums and google.
maybe a short tutoriaol or something?
here is what i have done so far.
1. Install liveroot from the aur.
2. cp /use/share/mkinitthingy.conf to /etc/mkThingyMaBob.conf (after backing up)
3. added oroot=live to the kernel cmd line (well I think i did anyway, i hit "e" at the grub prompt and added that to the linux line)
Last edited by darthearon (2015-07-03 11:29:15)
Cya At The Table
Offline