EasyOS version 2.3.2, June 22, 2020

[BarryK]

Say I have a base system that includes a .Xresources that if present takes precedence over .Xdefaults. If the bottom ro layer has a .Xresources and no .Xdefaults and I create a .Xdefaults in the rw top layer and delete the .Xresources (.wh file created in the rw layer) then it works as expected with the preferred .Xdefaults being used. I shut down and .wh files are deleted and the next load has both .Xdefaults and .Xresources present and .Xresources is incorrectly used .Xdefaults ignored.

I may have it wrong about the way things are set up with .Xresources taking precedence over .Xdefaults, but I envisage that something along the above lines could create problems ??? (there are other cases of series of potential files with one being given precedence according to specific tested for existence order). Equally my understanding could be wrong.

Good! This is why I invited feedback, thought someone might think of a reason not to delete all the whiteout files!

For that particular example, you would have to create .Xresources and .Xdefaults on the top level.

Yes, if someone deletes a config file, coz they don't want it anymore, if the whiteout file gets removed, that file will be back at next bootup.

However, if that config file exists in a SFS file, it is because it is needed. For upgrading to next version, it may be important that the user not be able to remove important files on the SFS layers.

But then, the user could create a replacement config file, that does nothing. Food for thought.

It is good to rethink the fundamentals sometimes.

[rufwoof]

Another example I believe would be using a Bourne type shell and ~/.profile

If you want ~/.profile to be used you have to ensure neither ~/.bash_profile or ~/.bash_login exist otherwise ~/.profile wont be used.

If the bottom ro layer has ~/.bash_profile and no ~/.profile, but the user wants to switch over to using ~/.profile, creates that file, deletes ~/.bash_profile (.wh file created) and a reboot reinstates the ~/.bash_profile because the .wh file was deleted ... then they'd be left wondering how the ~/.bash_profile that they'd deleted had reappeared and that they were running that and not their ~./profile file.

Extract from man bash

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

[belham2]

Another example I believe would be using a Bourne type shell and ~/.profile

If you want ~/.profile to be used you have to ensure neither ~/.bash_profile or ~/.bash_login exist otherwise ~/.profile wont be used.

If the bottom ro layer has ~/.bash_profile and no ~/.profile, but the user wants to switch over to using ~/.profile, creates that file, deletes ~/.bash_profile (.wh file created) and a reboot reinstates the ~/.bash_profile because the .wh file was deleted ... then they'd be left wondering how the ~/.bash_profile that they'd deleted had reappeared and that they were running that and not their ~./profile file.

Extract from man bash

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

Dam#, rufwoof, some days you make my head hurt----gotta read it 4-5 times before even a little sinks through This is just a suggestion, but we need a murga-thread section entitled: "Rufwoof's Corner" or even better 'School Time: Advanced Puppy Corner". . Between Barry, Micko, Phil, you, Toni, Wiak and Fred......I swear I really am back in school some days wondering from one classroom to the next trying to figure out just what in heck is being discussed. It's like being back at Sandia all over again. Anyhow, thank heavens I can create separate folders in my browser just to keep on top of all the links you guys create---right in the middle of threads no less!-----so I don't spend time hunting for them when something later, days, weeks or months, pops up in my mind & I realize.... Hahah!! that's what he meant.

[BarryK]

[followup for 'frugal' installed EasyLinux4.0 Seamonkey problem]

Ok, took a further look at this, and here's the problem: notice in the /usr/bin/seamonkey script anything weird?

Code: Select all

#!/bin/sh
 APP='/usr/bin/seamonkey.bin'
[ -f /root/spot/.mozilla/seamonkey/a2bvafqx.default/places.sqlite ] && ln -snf /usr/lib/x86_64-linux-gnu/seamonkey/seamonkey /usr/bin/seamonkey.bin
#script to run $APP as spot...
ARGS=""
[ $1 ] && while [ "$1" ]; do ARGS="$ARGS "$1""; shift; done
if [ $(id -u) -eq 0 ]; then
 [ $XAUTHORITY ] && cp $XAUTHORITY /root/spot/.Xauthority 2>/dev/null
 touch /root/spot/.Xauthority
 #following line is mostly there to catch any root:root files that may have got copied in...
 chown -R spot:spot /root/spot &
 export XAUTHORITY=/root/spot/.Xauthority  
 export XDG_CONFIG_HOME=/root/spot/.config
 export XDG_CACHE_HOME=/root/spot/.cache
 export XDG_DATA_HOME=/root/spot/.local/share
 exec su spot -s /bin/sh -c ""$APP" $ARGS"
else #precaution
 exec "$APP" "$ARGS"
fi

Specifically, this line:

Code: Select all

[ -f /root/spot/.mozilla/seamonkey/a2bvafqx.default/places.sqlite ] && ln -snf /usr/lib/x86_64-linux-gnu/seamonkey/seamonkey /usr/bin/seamonkey.bin 

If you check your directory for the actual Seamonkey folder, it is NOT in ......./x86_64-linux-gnu....... The script is creating a broken link shortcut every time for seamonkey.bin when the seamonkey spot script in /usr/bin is launched. So, to remedy this, remove the ...../x86_64-linux-gnu......and you'll have the regular Seamonkey (outside the Container) running again as 'spot'.

Weird that this problem only occurs in 'frugal' boots and not for full-install easylinux. Is no one else running this 'frugally' and didn't see this?? Or did my playing with adding a simple 'jwmrc.personal" file to the /root/.jwm folder cause this? Either way, it's fixed now.

Thanks for reporting that. Now fixed in woofQ. Reported in my blog:

http://bkhome.org/news/201709/run-as-sp ... fixed.html

[smokey01]

Last night I tried 0.4 on a 16GB USB3 stick which went quite well. It boots in 20 seconds. A couple of things I noticed:
Hardinfo looks for files in /usr/lib64/hardinfo when they are actually in /usr/lib/hardinfo
Desktop terminal icon opens rxvt and not urxvt. I only discovered this by using radky's urxvtcontrol.
Looks and works very well. Although I'm not keen on using the DD command, the one line install command worked very well.
Nice work.

[smokey01]

@Barry, I found a more serious problem. I just tried the same USB stick on my small asus netbook. Everything seem to boot fine until I clicked on the File icon and sdd2 could not be accessed because it doesn't exist. It does on my desktop. The lappy only has sda1 and sdb1 and sdb2 when the USB stick is plugged in. Because of this the previous saves were not loaded or changes saved at shutdown.

Sfsget and wifi all worked fine but it won't exist on a reboot. I think it needs to be a bit more portable between machines.

Cheers

[technosaurus]

I know Barry experimented with musl-libc before, but I thought I would bring up alpine linux as a possible base distro or container builder since it is musl-libc based and also the official docker distro. They even have a glibc compatibility layer that allows commercial apps and plugins (including flash) compiled against glibc to run on musl-libc.

One of the things making it difficult to build a puppy-like distro based on alpine is the lack of a "Categories" field in the package database, though I did respond to a thread on their forum requesting it here. I also mention using the MimeType field from the *.desktop file so that, if there is no default handler, the default handler could offer to install one. It could even provide an Icon

Using a package's desktop file could also allow the package manager, distro builder and container makers to have localization since the Name, GenericName and Comment keys can each be localized.

I experimented with a similar method when I was working on jwm-tools - integrating the package manager into a jwm menu (which BTW was way faster and much more intuitive) This makes the (fast) package installer menu have the same look and layout as the normal "start" menu, so users don't have to spend unnecessary brain function trying to figure out where the package they just installed ended up (and as a side effect it makes integration with the start menu generator practically free)

Anyhow, my point is, its not just Alpine, each distro has different package database information and split up their package differently. To alleviate this, I am considering posting a modification to the desktop entry specification to add a new Type [Package] and associated Keys like InstalledSize, Depends, Provides,... In the mean time I am working on a script that generates a package database entry that could be used by any distro.

[BarryK]

I know Barry experimented with musl-libc before, but I thought I would bring up alpine linux as a possible base distro or container builder since it is musl-libc based and also the official docker distro. They even have a glibc compatibility layer that allows commercial apps and plugins (including flash) compiled against glibc to run on musl-libc.

One of the things making it difficult to build a puppy-like distro based on alpine is the lack of a "Categories" field in the package database, though I did respond to a thread on their forum requesting it here. I also mention using the MimeType field from the *.desktop file so that, if there is no default handler, the default handler could offer to install one. It could even provide an Icon

Using a package's desktop file could also allow the package manager, distro builder and container makers to have localization since the Name, GenericName and Comment keys can each be localized.

I experimented with a similar method when I was working on jwm-tools - integrating the package manager into a jwm menu (which BTW was way faster and much more intuitive) This makes the (fast) package installer menu have the same look and layout as the normal "start" menu, so users don't have to spend unnecessary brain function trying to figure out where the package they just installed ended up (and as a side effect it makes integration with the start menu generator practically free)

Anyhow, my point is, its not just Alpine, each distro has different package database information and split up their package differently. To alleviate this, I am considering posting a modification to the desktop entry specification to add a new Type [Package] and associated Keys like InstalledSize, Depends, Provides,... In the mean time I am working on a script that generates a package database entry that could be used by any distro.

Wow, I didn't know about gcompat, that is a game-changer.

Yeah, Alpine Linux is an amazing distro.

[BarryK]

Another example I believe would be using a Bourne type shell and ~/.profile

If you want ~/.profile to be used you have to ensure neither ~/.bash_profile or ~/.bash_login exist otherwise ~/.profile wont be used.

If the bottom ro layer has ~/.bash_profile and no ~/.profile, but the user wants to switch over to using ~/.profile, creates that file, deletes ~/.bash_profile (.wh file created) and a reboot reinstates the ~/.bash_profile because the .wh file was deleted ... then they'd be left wondering how the ~/.bash_profile that they'd deleted had reappeared and that they were running that and not their ~./profile file.

Extract from man bash

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

The counter-argument would be that whatever is underneath, in q.sfs, is how Easy is intended to be run. There is /root/.profile, no /root/.bash_profile or .bash_login.

So if the user just creates them on top, no whiteout files are involved. If they create those .bash* files and delete .profile, then .profile would pop back later -- which wouldn't matter, but would be disconcerting.

These situations do seem to be rare, so maybe we could still delete all the whiteouts, except for these exceptions?

[BarryK]

Say I have a base system that includes a .Xresources that if present takes precedence over .Xdefaults. If the bottom ro layer has a .Xresources and no .Xdefaults and I create a .Xdefaults in the rw top layer and delete the .Xresources (.wh file created in the rw layer) then it works as expected with the preferred .Xdefaults being used. I shut down and .wh files are deleted and the next load has both .Xdefaults and .Xresources present and .Xresources is incorrectly used .Xdefaults ignored.

I may have it wrong about the way things are set up with .Xresources taking precedence over .Xdefaults, but I envisage that something along the above lines could create problems ??? (there are other cases of series of potential files with one being given precedence according to specific tested for existence order). Equally my understanding could be wrong.

I hunted for some info on this. In Puppy/Quirky/Easy, /root/.Xresources is loaded in /root/.xinitrc:

Code: Select all

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/usr/lib/X11/xinit/Xresources
sysmodmap=/usr/lib/X11/xinit/.Xmodmap
# merge in defaults and keymaps
if [ -f $sysresources ]; then
    xrdb -merge -nocpp $sysresources
fi
if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi
if [ -f $userresources ]; then
    xrdb -merge -nocpp $userresources
fi
if [ -f $usermodmap ]; then
    xmodmap $usermodmap
fi

This explains how .Xdefaults comes into the picture:

https://groups.google.com/forum/#!msg/c ... 3DETcIHGwJ

Quoting:

Xlib Programming Manual P.441

Prior to X11R2, X resource settings were read from .Xdefaults file
in users home directory and optionally on whatever machine the X client
was running on, so multiple files was hard to maintain.

Later on, xrdb program was made to store users resource settings from
in .Xresources into the XA_RESOURCE_MANAGER property of the root window
on the current X server, so all clients connected to the same server has
access to them. If the user hasn't called xrdb to set the property, then
.Xdefaults is read.

I have decided to delete all the whiteout files, whenever the sfs layers change, or at a version upgrade.

One "corner case' is where user creates .bash_profile or .bash_login, so these are detected and deleted.

I know that it seems too radical, but I haven't found a good enough argument not to do it, and there are arguments in favour of doing it.

[BarryK]

Here is something to get the brain cells churning:

http://bkhome.org/news/201709/managing- ... ootup.html

It is a very fundamental question, when we have just one read-write layer on top, why do we want whiteout files at all?

I am no dev, far from it. And I think I don't really understand it.
Nevertheless, since no one is commenting as yet...
Answer to the question: to remove builtin packages (and remaster)

Yeah, deleting the whiteout files will bring all the "removed" packages back.

However, if the remaster is done in the same session that the builtin files are removed, then it will work.

EDIT
I have implemented deletion of all whiteout files only when there is a change of sfs layers or a version upgrade.

So it won't affect you normally, and the removing of inbuilt pkgs will work ok.

[BarryK]

3) I do nothing else to Easy except launch Easy Package manager to update it, then closed it. Then I add a file to /root/.jwm where I created a "jwmrc-personal" file, with only one entry that allows the jwm tray to show the minixcal clock in big, bold font. Here's the entry:

Code: Select all

<ClockStyle>
 <Font>Ionic Charge-18:slant=italic:weight=demibold</Font>
</ClockStyle>

Saved this, went back to desktop, restarted Jwm, all was fine as the clock jumped up to my setting.

Yes, file /root/.jwm/jwmrc-personal was in jwmconfig2 PET, which has now been replaced by radky's PupControl PET.

I have fixed this by putting jwmrc-personal into the jwm PET.

[BarryK]

Get Flash goes thru the motions of downloading, but then shows
a notice as refusing to install the files.
An external flash plugin seems irrelevant anyway as it is already
built in to SM v2.48, so the get flash facility can be removed.

Yes, getflash 1.7-1 looks for /usr/lib64/mozilla/plugins. Fixed.

Also some missing icons, fixed.

Have bumped the PET to 1.8, will upload soon.

[BarryK]

I have backed off from deleting all the whiteout files in the rw layer (folder .session).

In initramfs, there is /sbin/fixlayers, that does integrity checking when the layers change.

It checks the whiteout files to make sure nothing important in q.sfs is blocked.

Changing the subject, in the "How Easy works" page, I have described "session.sfs", which accumulates the rw layer as a read-only compressed squashfs filesystem at a version upgrade.

However, have been increasingly doubtful about its usefulness, and have now removed it.

This will simplify the "How Easy works" page, one less abstract concept to try and explain.

Now there are just the two layers, .session rw on top, q.sfs ro on bottom, with optional sfs files inserted.

[BarryK]

As previously discussed, Menu Setup entry:
Check Dependencies installed pkg, is shown twice.

Thanks for reporting. Fixed.

[BarryK]

Desktop terminal icon opens rxvt and not urxvt. I only discovered this by using radky's urxvtcontrol.

Thanks, fixed.

[BarryK]

9. SNS not connecting at first boot was seen. I cannot find anything that has changed in SNS but have seen this issue in
WoofCE Pups. In addition in recent Pups I have seen intermittent failure to connect subsequently following a reboot.
The profile is not lost but is not read. Changing to a static I/P does not cure the problem but at least eliminates
DHCP as a suspect. I do wonder whether this is something to do with more recent kernels/firmware when 2 viable cards
are detected, i.e wireless & ethernet. In the past it was quite common to need to install additional firmware before a
wireless/bt card became available for selection.

I haven't checked first-bootup yet, but did get that reconnect failure on a reboot. Testing with ethernet.

I found the cause: Easy is too fast, or dhcpcd has become slower.

In /usr/local/simple_network_setup/rc.network, "dhcpcd eth0" is launched, then the script checks /etc/resolv.conf to see if it has changed.

dhcpcd daemonizes and returns to the script before having written to /etc/resolv.conf

I put in a little delay, "sleep 0.1", now works.

[belham2]

Hi Barry,

Had a quick question that I wanted to run by you: I've got this partition showing up in Thunar, yet nowhere else in Easy is it being seen. Terminal "blkid" shows it doesn't exist. Mounting it shows the partition to be "empty" yet Gparted can't see it either. Any ideas what this could be?? Would it be related to the Containers, and is their partition to use whenever we fire up a "Containered" program we've set up?

Thanks for any ideas/help with this.

[BarryK]

Hi Barry,

Had a quick question that I wanted to run by you: I've got this partition showing up in Thunar, yet nowhere else in Easy is it being seen. Terminal "blkid" shows it doesn't exist. Mounting it shows the partition to be "empty" yet Gparted can't see it either. Any ideas what this could be?? Would it be related to the Containers, and is their partition to use whenever we fire up a "Containered" program we've set up?

Thanks for any ideas/help with this.

I don't know. What name does Thunar give to this partition?

[BarryK]

3. Hardinfo refused to launch suggesting that permissions were a possible cause.
They were O/K, but I resolved the issue by copying /usr/lib/hardinfo to /usr/lib64

4. The exec line in Urxvt Terminal Emulator desktop file points incorrectly at rxvt. (Changed to urxvt)

Thanks. These are fixed.