Does "blkid" report it as "TYPE=btrfs" or "TYPE=BTRFS"?Wyk72 wrote:After a whole afternoon studying this (and other) threads on the subject, I managed to assemble (i.e. hack) a working upupbb 18.05+8 on an USB stick formatted with BTRFS.
gyro
Does "blkid" report it as "TYPE=btrfs" or "TYPE=BTRFS"?Wyk72 wrote:After a whole afternoon studying this (and other) threads on the subject, I managed to assemble (i.e. hack) a working upupbb 18.05+8 on an USB stick formatted with BTRFS.
You can't modify it, but you can re-layer it.gyro wrote:The results of my reading research are:
1) OverlayFs is much simpler that aufs, it seems to lack any ability to modify an existing stack.
If this proves to be true in practice, then the stack would have to be created once in "init", and then remain unchanged for the session.
"sfs_load" would be reduced to being an sfs manager whose results did not take effect until after a reboot.
Utilities that execute sfs files, by loading them into the aufs stack, executing the program inside and then unloading them would go.
There might also be some challanges with pupmode=13, since what happens when a directory that is part of an overlay is modified directly is undefined. So "snapmergepuppy" might have to go.
mkdir initramfs and then mount -o bind,ro / initramfs has the current / system also reflected in intramfs/ ... excepting any mounted folders, as though the root system had been shifted over/into the initramfs folder. So when we chroot to that then its pretty much the same, not too dissimilar to doing a chroot /gyro wrote:@ruwoof,
When you say "chrooted", are you referring to the line,
"mount -o bind,ro / initramfs"?
.. but we're not actually doing just a chroot / we're creating a stack/layered sytem, where / (initramfs folder) is at the bottom (lowerdir) in that stack. top is the top folder (the visible layer), changes is the folder where changes are stored (like whiteout files in aufs, but using overlayfs style instead), work is just a (empty) folder for overlayfs to work.I still can't quite get my head around the relationship between "top" and "/", since "initramfs" is the lowerdir of the stack.
Either really. Creating a file in the top (visible layer), adds that file to the changes folder (and vice-versa).I also would have thought you should be creating "/top/root/hello.txt" not "/changes/root/hello.txt".
If you exit the chroot, then you're back into the initramfs system, so yes you could create a entirely different stack set and chroot into that new stack. Maybe leaving the previous stack as before, or deleting it. If left as before then you'd have the option to again exit the chroot and revert back to that former stack. Best if the new stack has different changes/work folders as otherwise the new stack wouldn't work (work folder not empty) and/or the changes folder content for the original stack might have files/folders in it that conflicted with the correct operation/use of the new stack.Would this approach allow for the replacement of the stack with a different stack, i.e. containing a different sfs file in it's lowerdir list?