site  contact  subhomenews

SeaMonkey delay at startup fixed

October 22, 2018 — BarryK

Ha ha, a relative, a chap who is an IT manager for a travel agency, was visiting my place, and I was demonstrating containers in EasyOS. I showed how an entire desktop can be in a container, then I was showing that I can just click on an icon in the deskto-container, and I chose "www" icon, which is SeaMonkey ...and nothing happened, it didn't start.

It did, after an embarrassingly long time. I quit SM, started it again, still took a long time. Hmmm, a consistent delay. So, it is timing-out, waiting for something at startup. The immediate thought is the Internet, but SM in the main host filesystem is not delayed by lack of Internet.

Well, in this case, there is a network connection via ethernet cable to the router, however, my Internet is through my phone hotspot, and that was turned off. In the container, the network connection is through a macvlan tunnel, to the eth0 port.

After turning on the phone hotspot, SM started immediately in the container.

So, what is SM trying to do at startup, that requires Internet access? I checked the Preferences, and these checkboxes are ticked:

Software Installation
[*] Allow websites to install add-ons and updates
[*] Automatically check for updates [*]Daily [ ]Weekly
[*] Automatically download and install the updates
[*] Personalize add-on recommendations

I have unticked the two auto check and download, now SM starts fast in the container.

Tags: easy

Package management based on SFS mega-packages

October 18, 2018 — BarryK

EasyOS has two package management systems. At the top of the screen are icons labeled "petget" and "sfsget".

The former is a derivative of the traditional PPM (Puppy Package Manager, or Pet Package Manager), which can install and uninstall PET packages, as well as those of other distros, such as DEB packages.

sfsget is a downloader and "installer" for SFS files. These have a long history from the early days of Puppy Linux, back around 2005. They are mega-packages, that are loaded as layers using aufs or overlayfs (and unionfs in the early days).

SFS files have some tremendous advantages, including extreme ease of installing and removing -- they are just a single file, that is included in the layered-filesystem to install, and simply removed to uninstall. Really, these were the first "universal apps", before others like Flatpak and Snaps got the limelight!

Well, not quite "universal". A SFS file was created in a particular release of Puppy Linux, and designed to work on top of the base-SFS -- which in Easy is named 'q.sfs'. In a nutshell, Puppy/Easy run with a layered filesystem with the base-SFS at the bottom, extra SFS mega-packages above, and the read-write layer on top.

In the case of EasyOS, you can read about these layers here:

One of my long-term goals with Easy is to make SFS files truly "universal". That is, you can download 'chromium-1,2,3.sfs' and it will "just work". Regardless of what version of Easy you are currently running. So, you could have an old favorite SFS, and continue to use it indefinitely.

What makes this scenario possible is containers, which was really "step 1", implementing Easy Containers. Now that is starting to look pretty solid, can move onto the proposed universal packages.

Like PET packages, SFS packages will have a one-line database entry, one field of which will state dependencies. For SFS, the deps will be SFS files. The deps field will have one entry, like this


...the first entry states the version of q.sfs required, which could be an exact version (&eq), or greater-than (&ge), less-than, or a range. This is the same syntax as used in the traditional Puppy database format. Most SFS files will be complete and will only require the one dep, a q.sfs file.

The SFS file and its dep(s) SFS file(s) can be loaded in a container, and will "just work". This is independent of whatever version Easy is currently running -- you can keep updating Easy to later versions, which essentially means newer q.sfs and kernel, and it does not affect the containers. You can chroot into an old container, and it will still work.

...with some caveats, such as kernel version compatibility.

The entire concept is extremely simple and easy to manage. What I am investigating now, is how to store these SFS files online, in the repository. Incidentally, down-the-track, this will be an opportunity for users to get involved -- user-created SFS files can be uploaded to the repo.

Another thing that I am thinking about is any special files that will need to be in an SFS file. For example, an equivalent of the 'pet.specs' file in PET packages. PETs also have a '' (post install) script, and the SFS might need an equivalent.

As they say, "the devil is in the details", but will get there!

SFS-based pups

The idea of creating a minimal Puppy and expanding it with SFS files, has a long history. This is before containers of course. One thing about the history of Puppy, is there has been so much creativity. Individuals have been inspired, though of course it has often happened that great innovations have lapsed.

Certainly worth a look, to see what has happened in the past. Links to the creations of some developers, such as 'jrb', 'RSH' (also known as 'Lazy Puppy', 'R-S-H', etc.) and 'wanderer':

Lazy Puppy:
Minimalist base:

I downloaded jrb's ChoicePup, only 63MB, hey, a blast from the past! Works on my midi-tower. 

I browsed through these forum threads, as thought there might be some nice ideas in there.

Earlier universal packages blog posts

I have posted some earlier thoughts about implementing universal packages:

Very quickly went off using Flatpak. I also went off the idea of creating universal packages from the binary packages of another distro (was considering Devuan). However, my universal packages, though designed to run on Easy, could also run on other distros, they will need to setup layered containers with the Easy SFS deps, such as q.sfs.


Apart from the massive dependencies required for Flatpak, the complexity and the enormous sizes, I examined the underlying sandbox mechanism and was worried that it seems a bit "light weight" in the security department. This is an interesting read: 

Of course, it is easy to snipe at another project. My experience with Flatpaks is brief, and I am sure it does have some merit!

Tags: easy

empty and script utilities for Easy Containers

October 17, 2018 — BarryK

Prior to releasing Easy 0.9.7, there was a problem with launching apps in containers. For 'audacious' (music player) for example, a desktop icon is created, clicking on it runs /usr/sbin/ec-chroot-audacious, which has this in it:

ec-chroot audacious

...which failed, yet does work from a terminal window and from the JWM menu, as I reported here:

I fixed it for 0.9.7, like this:

urxvt -name eclaunch -iconic -e ec-chroot audacious

...where "-iconic" will launch the urxvt window minimized, and the name "eclaunch" is recognised by JWM to hide the window. This is clumsy, but it works.

Something in the 'ec-chroot-audacious' script is expecting the script to have been launched from a terminal. As it hasn't, in the case of ROX-Filer, there is a failure -- though interesting, can launch from the JWM menu OK.

I did some more research on this, and found this excellent discussion:

...the example is given of the 'ls' command. This checks if run in a terminal or in a script, and if the former, outputs with color-highlighted text. In a script, you just want plain text, for parsing purposes. So, that is the gist of the situation, something in 'ec-chroot-audacious' is performing a test, can't find a terminal, and aborts ...or something like that.

The above reference describes using the 'script' command, which fortuitously is a busybox applet. Yes, it works:

script -q -c "ec-chroot audacious" /dev/null

...clicking on the desktop icon, I can see the new pseudo-tty node getting creating in /dev/pts, and removed when quit audacious.

The above link also mentions a command named 'empty', project page here:

That also works:

empty -f ec-chroot audacious

...empty also created named pipes in /tmp, for input and output, though I don't see that I would need them.

Will think about it tonight, whether to use 'script' or 'empty'. If I can't find any downside to 'script', will probably go for that, as it is already available (in busybox). 

Here is another interesting read:  

EDIT 2018-10-17:
Decided to use 'empty'. It is now compiled in oe-qky-src:  

Tags: easy

Chromium browser PET improved

October 15, 2018 — BarryK

I posted recently about creating a PET package of the Chromium web browser, for use in Easy:

There has been some feedback on it. FeodorF informed me about /etc/chromium/00-default.conf, where commandline options may be specified, so they don't have to actually be on the commandline. I have put this into the file:

CHROMIUM_FLAGS="--test-type --no-sandbox"

EDIT 2018-10-16: see below about "--test-type"

Chromium defaults to downloading and saving files to '/root/Downloads'. For Easy, want that to be '/mnt/wkg/home/downloads' for downloads, and '/mnt/wkg/home' for saving files, as '/mnt/wkg/home' is where all personal files are intended to be located.

There does not seem to be any commandline options to specify those paths, cannot find any official way to do it, so improvised this: in the PET, created file root/.config/chromium/Default/Preferences, with just this in it (and no CR on end of line):


At first startup, Chromium will read that file. Although I only put in a tiny portion of what goes into that file, no problem, Chromium will write to it with everything else.

Another tester, belham2, reported being unable to move Chromium into a container. Yes, it can be downloaded inside the "desk" container, using the package manager, that works great. However, if Chromium is installed in the host desktop, then the 'Easy Container Manager' run (Filesystem menu), there is no listing for chromium, so it cannot be made into its own container.
The reason is, it got filtered out as the 'easy-containers' script does not like the "EXEC=chromium --no-sandbox" line in the 'chromium.desktop' file -- it rejects a line with a space character in it.
The new PET has "EXEC=chromium", no space character, so now all should be good.

Here is the new PET, the "bk3" designates it is my modifications (87.3MB): 

Any problems, please post to the new forum:  

EDIT 2018-10-16
The "--no-sandbox" is needed to run in Easy, however it causes a warning message to appear at the top of the Chromium window, "You are using an unsupported commandline flag" -- very annoying, and it has to be manually closed.
I googled, and found how to suppress the warning message, by the "--test-type" parameter, as posted here:!topic/chromium-discuss/O4WpwWvGz4A

I had previously scanned through this list of the commandline flags:

...and the description of "--test-type" does not have any hint of what it can actually do. A bit more of a hint here:

Anyway, thanks to the guy who discovered this switch! The PET is now "bk3". 

Tags: easy

EasyOS 0.9.7 released

October 14, 2018 — BarryK

Yay, here it is! For x86_64 PCs, download from here:

I posted last night about difficulty with launching containerized apps from desktop icons:

There is now a workaround, clicking an icon runs 'urxvt' terminal emulator which then runs the container. You don't want to see the urxvt window, so JWM is setup to hide it -- when you click on a desktop containerized-app icon, if you watch carefully, you will see a window flicker briefly on the screen, then disappear as JWM hides it -- except, I found a couple of times that JWM failed to hide it, leaving behind a visible window in the tray, labeled "ec-chroot".

So, if you do see that "ec-chroot" appearing in the tray, just ignore it. I am going to have another careful look at this, really would prefer not to have the urxvt launcher. An alternative would be not to have ROX-Filer desktop icons at all, use either a JWM panel or icons in the tray.

Anyway, those who are interested in Easy Containers will now be "on the same page" as me, for testing purposes. That urxvt thing is just a launching detail, that I will investigate further.

Another item on the to-do list, is try to fix the Xorg crashing that I reported recently, due to glamoregl and the modesetting driver.

Oh yes, also need to go through the steps of frugal installation, and update/improve the docs. Will do that soon.

One good thing in 0.9.7, for me anyway, is my ethernet connection is now working reliably. At bootup, Easy runs the 'ifplugstatus' utility in a loop, probing the ethernet cable to see if it is active. The odd thing is, from the time that Easy brings "up" the eth0 interface, it can take from 5 to 26 seconds before the router responds and activates the cable, so that ifplugstatus will return "Link beat detected". Increasing the waiting time fixed it.

If you want to read a bit more, please browse this blog. Also, the last release was 0.9.6, both 32-bit and 64-bit:

It would be reasonable to summarize that most of my effort between 0.9.6 and 0.9.7 has been on Easy Containers.

One more thing, do not upgrade from an earlier installation. Treat 0.9.7 as a new install. Have fun!

Forum feedback is welcome here:   

Tags: easy

EasyOS Pyro 0.9.7 almost ready

October 14, 2018 — BarryK

Thought it was ready, built it, some final tests... found another bug, actually, something that worked before, now has decided not to!

The "desk" desktop-in-container is looking really good. It seems to run as fast as the main desktop -- no problem with watching 720p full-screen youtube videos in the desk-container.

Something that has been plaguing me for a few days, is this error message when JWM runs in a container:

tcgetattr(): inappropriate ioctl for device

...and JWM crashes. Not just JWM. This is happening when launch a container from the desktop icon, not when I do it from a terminal. OK also when launch from JWM menu.

I readup on reasons for this crash, and thought that I could use the 'stty' utility to fix it, but no go. The only thing that works is to launch the container via a terminal, so for example an "audacious" container icon will launch "urxvt -e ec-chroot audacious" -- and have to set JWM in the host system to hide the urxvt window.
It works, but not entirely satisfactory.

Anyway, just a couple of things to do, so 0.9.7 should be out tomorrow.

Tags: easy

Keyboard layout for bootup password

October 10, 2018 — BarryK

Earlier this year I wrote about encryption of folders in the working-partition of EasyOS:

This required entering a password in the initrd, before the folders have anything in them. It cannot be done after the folders have some content.

There is a problem though. It is fine for those of us with a US-layout keyboard, but there is a complication for others. I have setup the 'init' script in the initrd, to automatically apply the entered password as the password for 'root' and 'zeus' users.

This is a problem, because after bootup and you choose a non-US layout, then if you ever want to enter the password for 'root' or 'zeus', it might not be correct. I think that is the situation, if I have thought it through correctly.

So, in the 'init' script in the initrd, there is now a list of keyboard layouts, and you type a number corresponding to the one appropriate for your keyboard, then you enter the password.

The layout you choose is remembered, so future bootups will only ask for the password.

I do plan to create a GUI for this, both to select keyboard layout then enter password, or even have an on-screen keyboard and allow mouse input. The plan is to use LittlevGL for this, but that is "down the track".

Tags: easy