EasyOS version 2.3.2, June 22, 2020

[zygo]

Barry,

Could you compile Hiawatha with xslt support. This would allow it to produce the directory index in HTML. Then it would be compatible with sfsget.

Edit: Sorry: HTML directory index works but no sfs found by sfsget.

Thanks

[rufwoof]

I dropped unsquashfs into the initrd (used the main sfs version and copied over the ldd's for that into initrd's /lib folder - expands initrd to around 8.3MB (non compressed)).

Testing main session snapshots using lzo level 1, lz4 and lz4 high compression ... had respective compressed file sizes of 376, 435, 368 MB (noted purely for relative comparison).

I've tweaked the /sbin/rollback script within initrd so that when doing a rollback of the main session, instead of rm -rf of the existing .session it just mv's that to a .delme version and kicks off a rm -rf of that .delme folder in the background ... so the boot is less held up wating to wade through 1GB or whatever of deleting existing .session folder content

I've also replaced the mount and cp existing method of roll back (.session) with a unsquashfs.

Overall considering time to create a snapshot (choice of compression) and time to rollback a session within the initrd ... I've settled for a choice of -comp lzo -Xcompression-level 1 for snapshots created within easy-version-control. Takes around 30 seconds with the unsquashfs progress bar being shown when initrd rolls back that 376MB snapshot sfs on my (11 year old HDD frugal install) setup.

That's for a debian bootstrapped save folder content, with firefox-esr/cwm installed. I've noticed that with use (firefox cache) the save folder (.session) can grow to 750MB+ compressed (lzo level 1) size quite easily (and potentially considerably more if other Debian packages were installed/used (Openshot, Libre, Audacity, Gimp ..etc.), so the standard/as-is EasyOS method of rm -rf and then mount/cp the .session when using considerably slower gzip ... could/will lead to considerably slow reboots when rolling back for some. lzo level 1 based compression/decompression seems to me to be the better choice for reducing down those delays, at least for HDD frugal based EasyOS setups. Especially if Iike me you rollback often (under Puppy things changes are stored in (finite) ram and you can set it to only (optionally) save at the end of a session, so if you have a clean version you might just shutdown without saving, so the next reboot is also clean. With EasyOS the approach is different (changes are stored on disk - so only restricted by available disk space), set things up, and create a snapshot (sfs) of that clean version, use it, then roll back (unsquashfs) the clean version back into the .session (save) area. So you end up tending to rollback at each/every reboot in order to achieve repeated clean boots (as opposed to wading around in muddy boots ))

[BarryK]

Guys, lots of posts for me to read back on sometime. For now, getting the work done so far out as a release, version 1.0.11 has arrived:

http://bkhome.org/news/201903/easyos-x8 ... eased.html

This is a very interesting release. Not much has changed after bootup, all the new stuff happens at early bootup.

[rufwoof]

I'm still on 1.0. ec-chroot within that doesn't cater for already having another Xephyr process running (i.e. if using Xephyr for something else). That may have been fixed in a later release however ???

I'm running both the easy container (on :1) and a pure debian (on :2), so a workaround is to just ensure I start the easy container first.

A nice 'feature' is that provided you leave one window open in each of the main, easy and debian displays, then alt-tab flips you between them.

Screenshot is with debian firefox-esr running on :2, easy container with firefox quantum running on :1 and the main session as per the screenshot, running top. Both the separate firefox sessions are playing youtubes ... but the sound is only heard from one (whichever grabs /dev/snd first).

[Sage]

1.0.11: Works well. Some duplication setting locale lang+k/b at boot up and again in setup panel? Regret the logic of direct frugal install to HD doesn't help in respect of .iso on optical media when using for diagnosis, rectification, demonstration, etc.

[BarryK]

Already a couple of bugs found in 1.0.11:

http://bkhome.org/news/201903/bugs-in-easyos-1011.html

...note item-2, upgrading an existing installation, requires a manual fix.

[blgs]

manual fix fix for easyOS 1.0.11 wasn' the correct solution for me. Switched back to the previous version (1.0.,

Waiting for the permanent fix before updating again.

[Billtoo]

New install to a 64GB Sandisk Cruzer flash drive.
Installed firefox and devx sfs files,added Vlc and Gnome MPV with
petget.
Gnome MPV and Vlc work well.

Enjoying new version so far,
Thanks.

EDIT: the flash drive is a Sandisk Ultra,

[BarryK]

Already a couple of bugs found in 1.0.11:

http://bkhome.org/news/201903/bugs-in-easyos-1011.html

...note item-2, upgrading an existing installation, requires a manual fix.

I fixed those two bugs, and have re-uploaded 1.0.11.

The "salt" problem with encryption is fixed, I think. Now using a fixed string for the salt, and for an existing installation, if the fixed string fails, it falls back to using the $WKG_DISKID as the salt, as before.

Notice to everyone, if you want to do an install to hard drive, grab this latest upload. From now on, the salt problem shall be no more.

[BarryK]

New install to a 64GB Sandisk Cruzer flash drive.
Installed firefox and devx sfs files,added Vlc and Gnome MPV with
petget.
Gnome MPV and Vlc work well.

Enjoying new version so far,
Thanks.

EDIT: the flash drive is a Sandisk Ultra,

Good, thanks for confirming that the media-player PETs work.

[BarryK]

manual fix fix for easyOS 1.0.11 wasn' the correct solution for me. Switched back to the previous version (1.0.,

Waiting for the permanent fix before updating again.

Grab the re-uploaded 1.0.11 image file. To upgrade an existing installation, when you click on 'initrd', don't choose the automatic fix. You will need to manually edit 'BOOT_SPECS' to have the correct values for the BOOT_UUID and WKG_UUID.

For future upgrades, automatic fixing of BOOT_SPECS should work, as long as I don't shift the gaol-posts again.

[blgs]

Downloaded easy-1.0.11-amd64.img.gz 2019-Mar-08 16:08:47. (latest update?)

Running easyOS 1.0.8. Did open the new image file (easy-1.0.11) by clicking two times. Copied the 3 files to the boot partition.
Manualy edit the initird file wit the correct UUID's for boot and the working partition.

Rebooted the computer. During bootup the boot and working partition are recognized. The screens regarding the language/keyboard and pasword setiing appears.

Then it stops....

I have attached a jpg file with the error.

Currently I'm switching back to easyos 1.0.8.

[BarryK]

Downloaded easy-1.0.11-amd64.img.gz 2019-Mar-08 16:08:47. (latest update?)

Running easyOS 1.0.8. Did open the new image file (easy-1.0.11) by clicking two times. Copied the 3 files to the boot partition.
Manualy edit the initird file wit the correct UUID's for boot and the working partition.

Rebooted the computer. During bootup the boot and working partition are recognized. The screens regarding the language/keyboard and pasword setiing appears.

Then it stops....

I have attached a jpg file with the error.

Currently I'm switching back to easyos 1.0.8.

The fact that you get the GUI asking for locale/keyboard-layout shows that the BOOT_SPECS file is wrong.

You only get that GUI at first bootup, not when doing an upgrade.

The reason for this is probably that you did not fix WKG_DIR. For example, if you had previously set it as WKG_DIR='easy/', then you will have to manually do so to the new BOOT_SPECS.

I have now fixed the script that handles this, /usr/sbin/edit-initramfs, which will be in Easy 1.0.12, and have updated the docs online:

https://easyos.org/user/easy-version-up ... grade.html

But, you can test the script. Download, remove the fake ".gz", make sure it is executable, and replace the script in /usr/sbin

I hope that you have success this time!

[rufwoof]

I do like the fundamental flipping of the EasyOS design.

Puppy pulls in other systems (Debian ... etc.) programs to use as its own, within its own environment; EasyOS core permits other systems to be run within controlled environment, set up a debian bootstrap folder for instance and use a combination of Xephyr, unshare, capabilities dropping and chroot ... to run the native (kernel/binary compatible) version of that ... Easy OS in effect becomes a hypervisor that can limit (or not) what system resources are made available.

Puppy saves changes to ram, which is finite. EasyOS saves changes to disk and via snapshots/rollbacks caters for whether changes are persistent, or not.

Of the two, EasyOS's design feels to be distinctly better IMO.

I've just added a debian bootstrap folder into /usr/local/debian-stretch for instance, which expanded the easy.sfs by around 50MB. Fire up a terminal and chroot that and I'm in a pure debian (main repo only) terminal session, into which I can use apt to build whatever debian system I desire within that, and EasyOS caters for what resources are made available, or not, or whether those changes are saved, or not. I can even create different versions, saving each to separate snapshots ... such that any one of those snapshots can be restored at any time, without having to reboot.

Multiple desktops are nice, as that way you can better mentally separate what systems might be running at the same time. Leave desktop 1 for EasyOS main, Easy container on desktop 2, Debian on desktop 3 ...etc. Yet despite such multiple systems running concurrently, operationally they're as good as running on bare metal (because fundamentally they are). Works incredibly well, even on my 11 year old (2GB ram) hardware. And software choice galore. Want to run Audacity? Then pick which OS you'd rather run that under, Puppy, Debian, Ubuntu ...etc. and just install/run it within that environment/desktop. Neat! Thanks Barry.

[rufwoof]

1.0.11 for my kit (BIOS, frugal HDD installed) the framebuffer isn't activated until very late. Predominately a text boot, with the kernel activating the framebuffer just before X is loaded.

So the current init in 1.0.11 throws out a error message on first run (/dev/fb0 exists but isn't activated, so when the logo for instance is run ... ERROR>> messages are generated).

The way I had X and network connection (and everything else) working inside init before was to actually chroot the main systems sfs sbin/init, and tagged on a exit (back into initrd's init) at the end of /etc/profile. Along with a flagging setup so that on subsequent loads it didn't just exit after re-running /etc/profile.

EDIT:

Ran checks and if prior to using the framebuffer in initrd/init such as loading the logo, running cp /dev/fb0 /dev/null and checking $? (return code) is one way to ensure the framebuffer is active before writing to it. The copy does however take a second or so to do when it is available (booting with video=640x480 i.e. text mode flashes through that (fails) pretty much instantly), so rather than copying the whole framebuffer, just coping 10 bytes or so is quicker. Line 254 or so in initrd being changed to ...

Code: Select all

#190307 display logo, -f = reduces to fit screen, keeps proportions
[ -e /dev/fb0 ] && head -c 10 /dev/fb0 > /dev/null && idump -f logo1920x1440.png

There are a couple of other /dev/fb0 usage in init, but they're subject to ext4 and I'm booting frugally to a non ext4 partition so I haven't tested those (no password being set, so no need for ask keyboard/password etc.).

[lp-dolittle]

Hi Barry,

am I right to suppose that your - hopefully not final - decision to abandon the .iso option also means that it no longer will be possible to run EasyOS in RAM exclusively (for example for security reasons, repair, etcetera)?

For sure, this option would be highly appreciated by many EasyOS users who would like to dd the iso-image on a flash stick; but, of course, EsayOS is your OS, and we respect your decisions.

Do you have in mind to offer an alternative, an option to run EasyOS totally in RAM without any additionally attached drive and in absence of an internal hard disk?

kind regards

[blgs]

The working directoy was in my system:
WKG_DIR=' ' without '/' up to and including EasyOS 1.0.8.

But in EasyOs 1.0.11 it fails, both in upgrade and in fresh frugal installations.

WKG_DIR=' /' with '/'
Fails in EasyOs 1.0.11, in upgrade and in fresh frugal installations.

WKG_DIR='easy/'
Also fails in upgrade anf frugal installation.

Somewhere I'm doing something but what!.

[Rodney Byne]

To Barry,
In 1.0.11,
Firefox downloaded from the repository doesn't
run when its desktop "New" container is clicked.

Incidentally this 64.0 is an old version and repository
should be updated to a Quantum 65.0.1

Let's hope 1.0.12 is better.

Regards.

[rufwoof]

am I right to suppose that your - hopefully not final - decision to abandon the .iso option also means that it no longer will be possible to run EasyOS in RAM exclusively (for example for security reasons, repair, etcetera)?

For sure, this option would be highly appreciated by many EasyOS users who would like to dd the iso-image on a flash stick; but, of course, EsayOS is your OS, and we respect your decisions.

I frugal to HDD, but isn't the .iso for burning to optical media (CD/DVD), .img is for dd to flashstick ?

Both can boot/run from just the dvd/usb without touching the HDD. Dropping the iso just removes the burning to optical media option.

[Rodney Byne]

To Barry,
whoops sorry, I've just found from the petget download, SMPlayer
doesn't launch as it says the QT5 script is missing.

As happens I had QT5-5.10.1-pyro64.pet on a backup files usb,
so installed that and SMPlayer then ran OK.
Regards.