EasyOS 3.4.7 released

[BarryK]

"Jumping the gun" here, as version 3.4.7 is still uploading as I type this.
However, have to go out in about 10 minutes and will be away most of the day, so getting this post in quickly.

Here is the download, and release notes:

http://distro.ibiblio.org/easyos/amd64/ ... ell/3.4.7/

Won't get to a blog announcement until this afternoon.

EDIT:
Blog announcement:
https://bkhome.org/news/202204/easyos-v ... eased.html

And a snapshot, 1024x768 screen:

easy3.4.6-desk-icons-menu-1024x768-640x480.jpg (75.1 KiB) Viewed 2515 times

[BarryK]

Alfons sent me an email. He successfully updated from 3.4.5, except for some errors on the desktop. He sent a photo:

update-3.4.5-to-3.4.7.png (31.14 KiB) Viewed 2625 times

Yes, the same two issues exist as when updating from 3.4.5 to 3.4.6; the "sfsget" icon is wrong and no wallpaper. Fixes posted here:

viewtopic.php?p=55190#p55190

The overlapping icons can be fixed by right-click on any partition-icon, choose "Desktop drive icon manager", then tick the checkbox "Tick box to erase then redraw and realign existing icons", then restart X via the menu "Shutdown -> Rectify -> Restart X server"

[BologneChe]

Bonjour à vous!

Last night, I tried to do the update (via Update button) and it was a failure Everything was resumed this morning and everything is in order!

Mes salutations;

[BarryK]

Yes, sometimes there is a problem downloading from ibiblio.org. Perhaps they get a bit overloaded at certain time of day.

I updated from 3.4.6 without incident.

[debianfan]

Intel 82577lm network card cannot be driven

[BarryK]

Intel 82577lm network card cannot be driven

I did a quick search. It needs the 'e1000e' kernel module.

Is it loaded? Run "lsmod" in a terminal to find out.

I also saw, in a very brief search, someone said they had to reload it:

# modprobe -r e1000e

[debianfan]

Intel 82577lm network card cannot be driven

I did a quick search. It needs the 'e1000e' kernel module.

Is it loaded? Run "lsmod" in a terminal to find out.

I also saw, in a very brief search, someone said they had to reload it:

# modprobe -r e1000e

modprobe: FATAL: Module =r not found in directory /lib/modules/5.15.35

But probably not the reason for this module. I can use the old kernel of this wireless network card normally: 4.19.161, and running this command also prompts that the module cannot be found

[BarryK]

The module is there.

Code: Select all

# modinfo e1000e
filename:       /lib/modules/5.15.35/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko
license:        GPL v2
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
alias:          pci:v00008086d00005511sv*sd*bc*sc*i*
alias:          pci:v00008086d00005510sv*sd*bc*sc*i*
alias:          pci:v00008086d0000550Fsv*sd*bc*sc*i*
alias:          pci:v00008086d0000550Esv*sd*bc*sc*i*
....

I checked:

Code: Select all

# modprobe --help

The "-r" means remove module, which is only going to work if it is already loaded, which is what lsmod will tell you:

Code: Select all

# lsmod

...and it would be there if e1000e is the correct module for your network card. That happens automatically.

[williwaw]

updated from quite a while back so I just made a new frugal install. well, I would have tried the update feature but ibiblio is so slow. not usually a problem but downloads from there often get dropped

lots of new stuff to test, but I must say the soundcard setup works without issue. lots of little fixes make the difference, thanks for all the upgrades and detailing, Barry.

I also tried using the kernel line parameters instead of the initrd edit scripts. All seemed well until I tried to rollback to a saved session. something making the rollback fail, but removing the kernel line and using the initrd scripts works as expected

[BarryK]

I also tried using the kernel line parameters instead of the initrd edit scripts. All seemed well until I tried to rollback to a saved session. something making the rollback fail, but removing the kernel line and using the initrd scripts works as expected

...hmmm, ok, thanks for reporting.

[BarryK]

Here is something to look forward to, for 3.4.8:

https://bkhome.org/news/202205/easyshar ... aring.html

[foxy1]

Please please please can we have EasyOS 3.4.7 for the Raspberry Pi 4b.
Ive been waiting and checking the posts for months and am desperate to
try out this amazing distro.

[user1111]

Upgraded my (last version) 2.5 to 3.4.7. Somewhat cheated by actually dd'ing it to the same stick as running from and even though the second partition was hard loaded that install booted ok to ram only running mode, within which I repeated the dd to the then totally unloaded usb stick, which when rebooted again resulted in the correct creation and population of the second partition. 2.5 was pre auto-update days so I guess that's no longer a factor.

For my choice of fonts/screen resolution the default desktop icon names/text are somewhat crowded, overlapping in some cases. A quick re-labeling soon fixes that

i.png (207.12 KiB) Viewed 2121 times

Re-built the easy sfs to use lzo compressed as that's faster to load. See that mksquashfs supports -comp lz4 -Xhc but lz4 easy sfs loading isn't turned on in the kernel .config (zcat /proc/config.gz)

lzo is still around 5 times quicker at decompression than gzip (lz4 is around 4 times quicker than lzo), so containers ..etc. load quicker, albeit at the cost of less compression.

Most things I've run so far have worked great. Installed tigervnc and that connects to my Fatdog vnc server (x0vncserver) and runs really well (youtubes play nearly as well as if being played on the same box). I did have problems with sfsget and downloading kernel sources and devx where the transfer speeds were very slow, kb/sec. Plugging into ethernet resolved that. Checked my wifi speeds via a web site and it was running at >35Mbs, so don't know why sfsget was so slow, maybe the server was busy at the time.

The initial usb first time boot did leave you hanging a bit, to the verge of thinking the system may have locked up, only awareness/familiarity prevented press-hold of the power button and even then I was somewhat tempted. Unfamiliar users might not be as patient.

All of the inter-connectivity/sharing etc. is great. Nice and easy

Thanks Barry.

Feature request/suggestion : Extend to include being a wifi hotspot. I sometimes use my phone, with its wifi and mobile data both turned off, to be a hotspot that other local devices can wifi connect to to form a closed wifi group. If instead a desktop/laptop (EasyOS) was the wifi hotspot then you gain better control over what might be accessible to that group (via the ethernet that might also be connected to that (via iptables rules)).

[user1111]

Set the keyboard during initial setup to option 21 (gb). Main desktop has that correctly set (correct keycodes and /etc/keymap contains gb). Load Dunfell container and the keyboard is set to us (as does /etc/keymap also contain 'us').

Opening a terminal within the Dunfell container and running quickcountry ... and setting the appropriate keyboard/locale within that, exiting without 'restart' ... results in the correct keyboard layout being set.

[BarryK]

rufwoof,
I like your suggestions for simpler text labels on some of the icons!

[user1111]

Casual thought (not thought through deeply) ...

EasyOS starts with easy.sfs, vmlinux, initrd in the first partition.

First start up and a second partition is created using remaining available space, for storing changes .. etc.

Over time, changes may accumulate such that much of the top layer (easy sfs) are mostly replicated within the changes area, such that there are near three copies, one in the first partition, one that's copied to ram, another in the save area (second partition).

My casual thought being ... why not move easy sfs over to the changes area from the start. First run creates the second partition and moves easy sfs over to that, replacing easy sfs in the first partition with just a pointer/sym-link, reducing the size of the first partition and hence leaving more space available for the second partition.

Initially vmlinuz, initrd and easy.sfs first partition content, then when the second partition is created the first partition becomes vmlinuz, initrd and a sym link to easy.sfs stored in the second partition.

As part of first boot easy.sfs is copied into ram anyway, so also copying in vmlinuz, initrd ...etc. is not much more overhead, then reform the entire usb stick, creating a first partition large enough to hold vmlinuz, initrd and a sym link to easy.sfs ...etc.

[user1111]

Using easyOS and xrandr to scale my laptop 1366x768 screen to 1440x900 - so that matches my Fatdog servers screen

viewtopic.php?p=57241#p57241

results in the drive icons being shifted away from the tray

capture13885.png (112.2 KiB) Viewed 2036 times

IIRC there used to be a Puppy config option to define where drive icons are drawn - but can't find that option in EasyOS, does it exist?

Having both laptop and server running at the same resolution is nice for when you vnc connect using the full screen option - somewhat like having yet another container - but one that keeps running even after you detach

EasyOS and its system on a USB choice - makes it a great choice of desktop/client system, with its broad range of functionality/options

sshfs mount a server folder and that becomes just another rox folder from/to which you can drag/drop files/folders

I find that watching youtubes via the Fatdog server (that is ethernet/hard wired) using vnc from my easyOS laptop 'client' when using tigervnc has good quality - nearly as good as if being played directly on the laptop. No sound - unless that is also separately forwarded, but I believe the next version of Fatdog will include rx/sx for sending/receiving sound which may be better/lighter than sndiod/sndio

I also run OpenBSD on the server, within kvm/qemu, which is great as a always on httpd/sshd/etc server (secure), whilst in having real userid's Fatdog serves well at being a general server. Along with mobile phone connectivity and using hashbang as a tui (cli) server for tmux (mutt mail ...etc.), supplemented with EasyOS containers ... and that's a pretty broad/deep range of distributed networking/processing. Spoilt for choice

[BarryK]

Interesting effect with those drive icons!

Go to /etc/eventmanager, you will see this line:

ICON_PLACE_EDGE_GAP='auto+2'

That auto feature is not working right in your case, so just make it a fixed value:

ICON_PLACE_EDGE_GAP=68

Then you need to tell it to redraw the drive icons. Right-click on any of the partition icons and run "Desktop drive icon manager".
Tick the checkbox to redraw the icons, exit, then restart X.

Actually, the thought has just occurred to me, maybe the "auto" offset is working properly. Just do that second step to force redraw of the icons.

[puptex]

fyi..DisplayControl/XorgWizard not saving all settings between reboots. I originally installed EOS_3.47 on an old desktop system and am now running the same USB/SSD on a laptop (1366x768) with a vga second monitor (1280x1024) and when I turn off the laptop display in XorgWizard the laptop display comes back on after a reboot with the Off check box unchecked. Have to recheck it. The monitors are sharing the same desktop space (overlapping). Not sure if this is related to this not being the original system EOS was installed on or something else...

[user1111]

I've had a couple of boots that resulted in cli ... run xorgwizard prompts, where simply running xwin connected to the X/gui session fine without running xorgwizard, Further confirmation that there is a issue with settings not being saved/read

[BarryK]

Re-built the easy sfs to use lzo compressed as that's faster to load. See that mksquashfs supports -comp lz4 -Xhc but lz4 easy sfs loading isn't turned on in the kernel .config (zcat /proc/config.gz)

lzo is still around 5 times quicker at decompression than gzip (lz4 is around 4 times quicker than lzo), so containers ..etc. load quicker, albeit at the cost of less compression.

Thanks for the advice, I have moved to LZ4_HC:

https://bkhome.org/news/202205/easysfs- ... lz4hc.html

[BarryK]

I received an email from Mike C today, asking if the Dunfell series will continue, as he likes it.

For anyone else who wants to know, the answer is yes.

I plan to support Dunfell and Bookworm, indefinitely.

[BarryK]

A bit more news about the Dunfell series...

I am having to entertain myself in other ways tonight, as commenced an OpenEmbedded recompile at 2pm. Last time I did it, it took over 19 hours.

Yocto is an extra layer and management for OpenEmbedded, and they have published the releases:

https://wiki.yoctoproject.org/wiki/Releases

...the Dunfell release will be supported until mid-2024. In May 2022 there was a minor-point release, 3.1.16, so I have downloaded that, hence the recompile.

The plan is that Easy Dunfell 4.0 will be released soon, maybe in about a week.

[user1111]

Copying easy.sfs to ram makes access quicker after having been copied, but eats more of ram than if easy.sfs had just been sym linked into ram.

I changed init (in initrd) to use ln -s of easy.sfs to ram instead of copying to ram and it boots quicker, initially sees programs load slower the first time they're run, but that tends to be just as quick to start on subsequent program starts.

In the average session not all of the programs/files in easy.sfs will be read/accessed so all else being equal linking easy.sfs to ram is more efficient than copying it into ram.

If as part of normal operation the usb isn't unplugged anyway then sym linking is fine.

That all said perhaps there are other reasons/operations that require a copied version to be present in ram ???

init line 1474

Code: Select all

#[ ! -f /easy_ro/easy.sfs ] && cp -L -p /mnt/${WKG_DEV}/${WKG_DIR}releases/easy-${INIT_DISTRO_VERSION}/easy.sfs /easy_ro/ #181029 200830 -p
 [ ! -f /easy_ro/easy.sfs ] && ln -s /mnt/${WKG_DEV}/${WKG_DIR}releases/easy-${INIT_DISTRO_VERSION}/easy.sfs /easy_ro/easy.sfs #181029 200830 -p

If you conceptualise a sfs as being like a tar file, where each individual file is compressed before being added to the .tar (sfs) file, then if copied to ram you end up with copies of the compressed version and the uncompressed version once a file is accessed/used. Assuming average 50% compression that's 1.5 times the filesize of ram used for each file that is opened when the compressed sfs is copied to ram. Versus near 1.0 times if instead linked (ignoring the relatively small overhead for link pointers).

[BarryK]

rufwoof,
Yes, I understand what you are saying. Another factor also, is the read speed of SSDs is so high, another argument to not copy to RAM.

Maybe I could raise the cutoff. If RAM is 4GB or less, then don't copy easy.sfs to RAM. Require 8GB to copy.

Maybe for slower drives such as HDD (when it has to do a big head movement), the cutoff could be kept at 4GB.