Remasters don't pick up /home folder

[mikeslr]

AFAIK, there are currently only 3 applications for remastering: (1) the original builtin; (2) shinobar's remasterX, which for the most part just reorganized that to move all user-input to the beginning; and (3) nic007's remaster modules in nic0S-utilities suite.

I just used the latter two in a Puppy on which having originally SFS-loaded Google-Chrome64 SFS (not the portable) its files were located in /home and I subsequently built two other browsers which also were located in /home. Neither remaster automatically dealt with the existence of a /home folder. Not surprising. But what was particularly troubling is that nowhere during the remaster process was there an opportunity to modify the built to include such folder.

Actually, the reason for the remaster was that with the application files of three web-browsers in /home, the SaveFile had long grown beyond anyone's definition of "small" within the context "keep your SaveFile small".

Adding a /home folder was an intermediate step --modeled on FatDog64's success-- in attempting to respond to Google's crippling of the ability to run Chromium and clones as Root. Although we are now able to run those web-browsers as portables with 'no-sandbox' AFAIK if we want the security of being able to run as Spot --with Spot actually conforming to the restriction that it can't access any folder beyond its own-- the physical location of the browser's files must be in the Spot folder.

A possible work-arounds is relocate the spot folder from /home back to /root. I'll see if that now works.

Otherwise some modification of remaster scripts in required. Does remastering under FatDog64 --which developed the idea of a /home folder-- have a solution?

[nic007]

Need to distinguish between: home (called so by ROX but it's actually /root), /home or /mnt/home?

Puppy Remaster scripts deal with the running puppy filesystem only. /mnt/home is actually a shortcut (link) to /initrd/mnt/dev_save which is the partition where your savefile is located. If you included /mnt/home in the remaster, you will include all sorts of files that actually has nothing to do with your puppy operating system, like personal files, any other files that are just stored there, extra sfs files (which can be included in a remaster if they are loaded), etc. It's not part of the actual puppy running system. As a matter of interest - if you use my Alternative Remaster application, you will actually have the opportunity to include whatever other files you like before the new base sfs is created if you checked the "Final check" option at the start. You may of course also include anything extra when you are actually making an ISO.

Puppy's are not Dogs and Puppy remaster scripts can't be used for Dogs (and the other way around as far as I know), they have their own.

Another thing - Actually the browser application which you seem to have in /mnt/home in itself has nothing to do with your savefile. However when running the browser things like the browser cache is normally stored in /root which will fill up your savefile. Most of us move the browser folder created in /root when running the browser, out of /root, to say somewhere in /mnt/home and then symlink it back to /root so that it does not fill up the savefile. I don't know if running in spot works differently, never used it.

If you are talking about /home - The remaster script also does not include this folder (I have never seen this folder in action at any time I have used Puppy) . I see that the script excludes this folder specifically together with a few others like /tmp, /sys, /initrd folders. To include /home for any reason would be very easy though with a very small adjustment in the script.

[williams2]

A long time ago, Puppy did not use unionfs or aufs to make a layered file system.

In these old Pups, the savefile was mounted directly on /root,
so only /root was writable.

/bin was read-only
/sbin was read-only
/usr was read-only

/root was writable
/etc was writable, but only because it was a symlink to /root/.etc
/var was writable, but only because it was a symlink to /root/.var

/home/spot did not exist.
/home did not exist.
spot did not exist.

A Puppy user could create a user like spot, but /home did not exist.
/root was the only writable dir, so spot's home dir had to be put in /root

Which is why spot's dir was /root/spot instead of /home/spot, where it belonged.

A remaster can save all of the file system changes. This is easy to do.
There are things which can be deleted or left out, like tmp files, log files, cache files, etc.

If you want the remaster to work well on all of your computers, it can be good to not save files that are for 1 particular machine. Like modules and config files for a radeon video chipset when your other computer has a nvidia chipset.

If you want your remaster to work on many, many machines, for example, if you want to publish it on an iso as a Puppy derivative, you need to delete or leave out more things from the remastered sfs. For example, you would want to leave out your wifi configuration and id and password etc etc.

It is easiest to copy everything, including all of your personal stuff.

It's harder to make your script find and remove all the personal stuff.

i use my own remaster script. It copies everything in my old adrv.sfs file to /tmp
then copies and overwrites everything in /tmp with the changes to the file system,
then makes a new adrv.sfs file from /tmp

Just 3 lines in a script.

It's a lot harder to write a general purpose script that anyone might use.

[mikeslr]

Hi nic,
I guess I wasn't clear and you've never used Mike Walsh's Google-Chrome.sfs. I wasn't writing about /mnt/home, but rather a 'top-level' folder Google-Chrome creates. See diagram near the top of this post, viewtopic.php?p=584#p584. It's the folder 4th from the left edge.

Thanks william2 for the overview. I'll have to re-read it after I've had my second cup of coffee.

But it may be that Mike Walsh's recent work has rendered the problem academic. viewtopic.php?p=479#p479.

My morning routine is to have a cup of coffee before breakfast. Breakfast requires that I take 25 Units of Lantus (slow acting but long lasting insulin) and 5 Units of Humalog (short term acting insulin to handle the carb/sugar intake of food). Reverse the 2 and I also have to call the emergency squad as in about 15 minutes my blood-sugar level will drop below 50 and I'll go into a coma. So, I kind-of want to clear the 'cub-webs' before taking insulin. Reading what's new about Puppy Linux while I have the 1st cup of coffee (a) keeps me from being entirely distracted by the insanity of the current American Political and Economic situation and (b) presents sufficient complexity that it forces my mind to focus. Starting with the "Additional Software Section" alerts me to what's new before taking on whatever challenges the Beginners or Users Section may hold. Hence, I knew of Mike's recent work before turning to the responses of my question of yesterday.

Thanks, guys, for creating a place which balances interesting and sane in a world which has placed too much emphasis on the former.

[nic007]

Hi nic,
I guess I wasn't clear and you've never used Mike Walsh's Google-Chrome.sfs. I wasn't writing about /mnt/home, but rather a 'top-level' folder Google-Chrome creates. See diagram near the top of this post, viewtopic.php?p=584#p584. It's the folder 4th from the left edge.

Thanks william2 for the overview. I'll have to re-read it after I've had my second cup of coffee.

But it may be that Mike Walsh's recent work has rendered the problem academic. viewtopic.php?p=479#p479.

My morning routine is to have a cup of coffee before breakfast. Breakfast requires that I take 25 Units of Lantus (slow acting but long lasting insulin) and 5 Units of Humalog (short term acting insulin to handle the carb/sugar intake of food). Reverse the 2 and I also have to call the emergency squad as in about 15 minutes my blood-sugar level will drop below 50 and I'll go into a coma. So, I kind-of want to clear the 'cub-webs' before taking insulin. Reading what's new about Puppy Linux while I have the 1st cup of coffee (a) keeps me from being entirely distracted by the insanity of the current American Political and Economic situation and (b) presents sufficient complexity that it forces my mind to focus. Starting with the "Additional Software Section" alerts me to what's new before taking on whatever challenges the Beginners or Users Section may hold. Hence, I knew of Mike's recent work before turning to the responses of my question of yesterday.

Thanks, guys, for creating a place which balances interesting and sane in a world which has placed too much emphasis on the former.

So what you're saying is that the chrome sfs when loaded expands to the /home folder (a bit like Java and some Palemoon sfs's expand to the /opt folder). So the application itself is at that location. That will not be included in a new base sfs when using the classic remaster script because /home is one of the folders which are explicity excluded. However, it will be included if you choose so when running my alternative remaster script because the copying of files differs from the classic method in that the files are copied directly ftom their mounting points at /initrd/pup_ro?..

[mikewalsh]

@ Mike/Nic:-

@ Nic:-

When I started using the /home directory a couple of years ago, I did so because it was the way the FatDog team had got around the "normal user" thing. This was back before I got around to building the portable Chrome packages.

As to re-masters, etc., I'm a total 'noob' in that respect. I attempted a re-master of ETP's Chromebook_Pup (V.1) some 5 years ago, and was horrified by how large it turned out with all my then-favourite apps. I haven't really bothered since.

----------------------------------------

@ Mike:-

But it may be that Mike Walsh's recent work has rendered the problem academic. viewtopic.php?p=479#p479.

Somewhat off-topic here (though it may have a bearing on what you want to achieve), I can report - since I know that you're interested - that the current Chrome-portable build does indeed respect the 'spot' limitations. Downloads go very firmly to the /spot/Downloads directory, and nowhere else.....and uploads need to come from within /spot with the correct permissions. So the Spot2Root download/upload permissions changer definitely still has its place.

Basically, all I did was to get Chrome's 'LAUNCH' script (and the 'chrome-pup' wrapper-script in the main directory) to

Code: Select all

chown -R spot:spot

.....at each stage of the process, using a '$HERE' variable via Fred's 'readlink' trick. That, combined with adding a mini-'spot' directory into the main one, with the profile at Google_Chrome-portable/chrome/spot/.config/google-chrome, seems to have done the trick. Most of the 'clones' seem happy to have their profile re-named to simply 'PROFILE', but Chrome doesn't like that, and lets you know in no uncertain terms. You can have it set to create its 'PROFILE' within the main directory, bit it'll point-blank ignore that and insist on creating /google-chrome within /root/spot/.config or /home/spot/.config (depending on how your spot directory is set up).

So I thought, "To hell with it". Working with Chrome is a hell of a lot simpler than trying to fight it.....so I met it halfway, and gave it what it was looking for, albeit in a roundabout way. Chrome apparently couldn't give two hoots as to the location of the 'spot' directory it uses, just so long as the permissions are correct.....

----------------------------------------------------

The portable builds don't use the "--no-sandbox" switch.....and this is the outcome:

[Click to enlarge:-]




Which I'm satisfied with. (The Yama LSM stuff isn't worth bothering with as a rule.....unless you're a real security freak, and to achieve it you need to go into chrome://flags & trip about a million little-used switches.) For the average user, the above set-up is considered perfectly secure by Google themselves.


Mike.