[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#863388: live-boot: Added new functionality to live-boot: rootcopy, modularized filesystems, package installer

On 06/16/2017 05:13 AM, William Prochazka wrote:

Ahhh, a thousand apologies as my original submission didn't make it
clear.  The module stuff is all related to using the toram function.
When using toram, the module function doesn't work as expected.

If you specify "toram=something.module" (not documented in man page, but
the arg is parsed into MODULETORAM), it assumes this is a single
squashfs filesystem, not a module file (maybe just confusion with what a
"module" is).
If you specify "module=foo toram", it ignores any foo.module and tries
to copy the whole live directory.  Maybe then it honors the module file,
but I never get that far as I run out of RAM ;)

I can clean up the patch but the additions to the toram file check to
see if:
a) module = something and  toram, then calculate size based on the sum
of the parts in the module file and only copy those parts to ram, then
continue as before.

The normal behavior for toram=filesystem.squashfs is kept and toram
without a "module=" is also kept as before...really just takes care of
loading a module into ram.
Now it is clear, I'm sorry I missed it was about toram functionality, thanks for pointing out.
I haven't studied details of toram code but I used it enough to know it is somewhat inflexible (my pain point was trying to use live-toram tool with a non-squashfs image). Extending and polishing it would be appreciated. 




I concede that I didn't realize the module file could include a raw
directory since the man page refers to disk images.  It is a bit of a
pain to make a module file for each bootable filesystem you may want,
but I can make due with that if you don't like the actual rootcopy
cheatcode.  I might also point out that I would bet many people are
I should note that I'm just an outsider of this project so I don't have a say in what can or can not be accepted. I only replied because added functionality seemed redundant and I wanted to point it out. Now that I got my message across I count myself successfull :). I'm aware there is also some other functionality in your patch but I didn't really checked them and you should decide whether to clean them up to leverage existing functionality and push it for inclusion. 



unaware of this feature since it is buried in the module functions and
not well explained in the man page, but thanks for clearing that up.
It is indeed an important issue with live-boot documentation. It is a very capable set of scripts but so many times I've had to dig up the code to see how to use a functionality or whether a specific use case in my mind was actually supported or not. It is often possible to rely on implementation details to use it in ways it was originally thought or at least publicly documented. 




On Fri, 16 Jun 2017 00:47:56 +0300 Mert Dirik <mertdirik@gmail.com
<mailto:mertdirik@gmail.com>> wrote:


On Wed, 14 Jun 2017 01:48:05 +0000 William Prochazka wrote:
 > Well,
 >
 > 1. Root copy is not a squashfs filesystem, so it allows for quick
tweaking
 > and modification without having to "commit" your changes. This also

makes

 > modifications (for the purpose of troubleshooting) much easier.
 >
 > 2. The alternative filesystem module is still a single file. The new
 > feature allow for the specification and ordering of filesystem modules.
 > For example, imagine the following:
 > filesyste A contains all necessary files to boot a system into a basic
 > shell with basic functionality, nothing more. Branch filesystem B
contains
 > a bunch of advanced tools (coimpilers, scripting environments, etc.
Branch
 > filesystem C contains X and Branch Filesystem D contains all of the X
Bloat
 > applications.
 > Together, all four branches are roughly the size that the one
"monolithic"
 > filesystem D would have been if I wanted to use the legacy modules
 > directive, but now, I have a boot time option to specify if I want

just A

 > for a tiny system, (A and B) for more functionality, (A, B, and C)

for a

 > GUI, or (A, B, C, and D) for all of the bells and whistle. Now I

get all

 > of that and don't have four copies of the filesystem. Furthermore, if I
 > then add a file to A, It will be present when booting into D due to
 > squashfs.
 >
 > It is really nice.

I'm still not getting it. You can accomplish all of these with the
existing module functionality.

Modules don't have to be squashfs files. They can also be regular
directories. You can modify them freely. You can use them in the exact
same way you use overlay directories, because they end up being just
another layer of  the overlayfs mount. You can mix and match modules
using *.module files or change their ordering, because they are just
overlays. You can also select different *.module files with boot

parameters.


Sorry if I still miss something obvious but this seems to cover all
functionality you've brought so far.
Reply to: