EasyOS 3.4.1 released

[BarryK]

Announce here:

https://bkhome.org/news/202202/easyos-v ... eased.html

I have got some other things to do for a few days, so thought would bring out 3.4.1. Quite a few fixes since 3.4.
See list of changes in the release notes:

https://distro.ibiblio.org/easyos/amd64 ... -notes.htm

[Airdale]

I upgraded from a computer with 3.3 and another with 3.4 to 3.4.1 using EasyUpdate.

Works great without issues!

capture5765.png (182.44 KiB) Viewed 1832 times

However, I had no trouble with 3.4 on my hardware, so I'm not sure that this confirms that the bugs are fixed.

But so far so good.

[BologneChe]

@BarryK
The transition from version 3.3 to 3.4.1 is a success! Nice work and sincere thank you! I like this clean desktop!!!!

Voilà!

[Berto]

Wow! very red, but very nice design - and very clear and readable fonts. I like the new desktop feeling very much. Updated manually from 3.3 to 3.4.1 - evreything is working well.

Regards Berto

[BarryK]

Holden has reported by email that his AMD Ryzen 5 5600g PC gets to "loading kernel modules" then hangs.
But, some other distros, such as Manjaro, OpenSUSE and PCLinuxOS do work.

[TerryH]

I held off updating from 3.3 until now, as I have been using a clean desktop with all launchers in additional jwm trays. I had concerns that this new clean set up may not match how I like and be more work. The update went well and the setup was very simple, I just re-added the include statement for my Tray2. I now don't have to bother editing .xinitrc to remove the check for container launchers, or alter the check for defaultbrowser, so my changes weren't clobbered on rebooting. So for me this update is very worthwhile.

Just one observation, the EasyApps icons in the window that appears are all mis-aligned. All of the selection options are similarly mis-aligned, as the screenshot displays. The window is not resizable, so I couldn't check how it would appear if maximised and then reset. See screenshot.

Also I just noticed that the output image from TAS is written to /root directory. Not sure if it is still known that the output is written to /root or just a hang over from my old changes and should be written to a /files directory.

Edit: I believe I found the cause of the misalignment. the gui_control script used only caters for font up to 108 DPI. Currently I am using a 10.8" screen which is 1920x1080, everything is so tiny I need to adjust the DPI setting to more clearly see things, in EasyOS I currently have it set to 132.

Edit 2: Changed gui_control to cater for 132 DPI, window is now rendered with icons aligned.

[BarryK]

I held off updating from 3.3 until now, as I have been using a clean desktop with all launchers in additional jwm trays. I had concerns that this new clean set up may not match how I like and be more work. The update went well and the setup was very simple, I just re-added the include statement for my Tray2. I now don't have to bother editing .xinitrc to remove the check for container launchers, or alter the check for defaultbrowser, so my changes weren't clobbered on rebooting. So for me this update is very worthwhile.

Just one observation, the EasyApps icons in the window that appears are all mis-aligned. All of the selection options are similarly mis-aligned, as the screenshot displays. The window is not resizable, so I couldn't check how it would appear if maximised and then reset. See screenshot.

Also I just noticed that the output image from TAS is written to /root directory. Not sure if it is still known that the output is written to /root or just a hang over from my old changes and should be written to a /files directory.

Edit: I believe I found the cause of the misalignment. the gui_control script used only caters for font up to 108 DPI. Currently I am using a 10.8" screen which is 1920x1080, everything is so tiny I need to adjust the DPI setting to more clearly see things, in EasyOS I currently have it set to 132.

Edit 2: Changed gui_control to cater for 132 DPI, window is now rendered with icons aligned.

Thanks for letting me know about that dpi problem.

[BarryK]

I held off updating from 3.3 until now, as I have been using a clean desktop with all launchers in additional jwm trays. I had concerns that this new clean set up may not match how I like and be more work. The update went well and the setup was very simple, I just re-added the include statement for my Tray2. I now don't have to bother editing .xinitrc to remove the check for container launchers, or alter the check for defaultbrowser, so my changes weren't clobbered on rebooting. So for me this update is very worthwhile.

Just one observation, the EasyApps icons in the window that appears are all mis-aligned. All of the selection options are similarly mis-aligned, as the screenshot displays. The window is not resizable, so I couldn't check how it would appear if maximised and then reset. See screenshot.

Also I just noticed that the output image from TAS is written to /root directory. Not sure if it is still known that the output is written to /root or just a hang over from my old changes and should be written to a /files directory.

Edit: I believe I found the cause of the misalignment. the gui_control script used only caters for font up to 108 DPI. Currently I am using a 10.8" screen which is 1920x1080, everything is so tiny I need to adjust the DPI setting to more clearly see things, in EasyOS I currently have it set to 132.

Edit 2: Changed gui_control to cater for 132 DPI, window is now rendered with icons aligned.

OK, fixed:

https://bkhome.org/news/202202/easyapps ... ments.html

Also went through and did a lot of fixing of offered apps. PET is now 3.1.2.

[rudyt]

I run EasyOS in frugal mode, sharing the sda3 partition with Slackware, TinyCore and VoidPup. EasyOS boot files are in /mnt/sda3/EasyOS, and wkg_dir is in /mnt/sda3/EasyOS/wkg_dir

Every time I Shutdown or Reboot from the EasyOS menu into another linux (ex: FossaPup64 on /mnt/sda2/FossaPup), running fsck on /dev/sda3 reports the drive was not cleanly unmounted and proceeds to fix it..

Happens every time. Maybe it doesn't happen with a dedicated EasyOS drive or partition, but it definitely happens in the case above

[BarryK]

I run EasyOS in frugal mode, sharing the sda3 partition with Slackware, TinyCore and VoidPup. EasyOS boot files are in /mnt/sda3/EasyOS, and wkg_dir is in /mnt/sda3/EasyOS/wkg_dir

Every time I Shutdown or Reboot from the EasyOS menu into another linux (ex: FossaPup64 on /mnt/sda2/FossaPup), running fsck on /dev/sda3 reports the drive was not cleanly unmounted and proceeds to fix it..

Happens every time. Maybe it doesn't happen with a dedicated EasyOS drive or partition, but it definitely happens in the case above

What is the filesystem in sda3? It should be ext4, with journaling enabled.

[BarryK]

Also I just noticed that the output image from TAS is written to /root directory. Not sure if it is still known that the output is written to /root or just a hang over from my old changes and should be written to a /files directory.

Thanks for reporting that, fixed:

https://bkhome.org/news/202202/take-a-s ... -bump.html

It will be fixed, but the old /root/.take_a_shot.rc has to be deleted.

[rudyt]

I run EasyOS in frugal mode, sharing the sda3 partition with Slackware, TinyCore and VoidPup. EasyOS boot files are in /mnt/sda3/EasyOS, and wkg_dir is in /mnt/sda3/EasyOS/wkg_dir

Every time I Shutdown or Reboot from the EasyOS menu into another linux (ex: FossaPup64 on /mnt/sda2/FossaPup), running fsck on /dev/sda3 reports the drive was not cleanly unmounted and proceeds to fix it..

Happens every time. Maybe it doesn't happen with a dedicated EasyOS drive or partition, but it definitely happens in the case above

What is the filesystem in sda3? It should be ext4, with journaling enabled.

Sorry, sda3 is an ext2 filesystem. I wrote that in my OP but it looks like I must have edited it out by mistake.

I can see my problem not manifesting itself in a journaled ext4 FS because it's very tolerant of a brute-force shutdown without unmounting. Maybe I'll add an explicit unmount to the shutdown and reboot scripts, but that would make my version an orphan and I'd have to do it for every version.

Your reply also implies that EasyOS shouldn't be run on an external flash drive because the repeated journal writes would accelerate the demise of the flash.

[BarryK]

@rudyt
Awhile back, I did research into the longetivity of flash drives and the ext4 f.s. with journal, and determined that it does not significantly reduce the lifetime.

EasyOS used to have ext4 without journal, based on the assumption about flash longetivity.
However, due to the "unclean" state of the f.s. after shutdown, introduced the journal.

Note, Puppy Linux has the same problem, in certain PUPMODEs. The problem is due to the aufs or overlayfs layers not able to unmount cleanly.

Note also, the "unclean" state of the f.s. is minor, the f.s. is not corrupted in any way.

Note also, a feature of flash drives is that they, these days, have wear-leveling, which greatly extends their life.

[rudy]

@rudyt
Awhile back, I did research into the longetivity of flash drives and the ext4 f.s. with journal, and determined that it does not significantly reduce the lifetime.

EasyOS used to have ext4 without journal, based on the assumption about flash longetivity.
However, due to the "unclean" state of the f.s. after shutdown, introduced the journal.

Note, Puppy Linux has the same problem, in certain PUPMODEs. The problem is due to the aufs or overlayfs layers not able to unmount cleanly.

Note also, the "unclean" state of the f.s. is minor, the f.s. is not corrupted in any way.

Note also, a feature of flash drives is that they, these days, have wear-leveling, which greatly extends their life.

Hi Barry, thanks for the elaborate reply. I did know about wear leveling, but that's usually not a feature on low end thumb drives that are typically used for file transport. Wear leveling is definitely a feature on larger SSDs meant to be system drives. I don't use USB flash devices with EasyOS because they're way too slow. The activity light seems to be flashing almost all the time, probably due to the journal writes.

I'm not worried about the possible data loss because the errors are mostly harmless (empty DTIME). My issue is that Slackware complains and forces an fsck and a reboot because it's very picky about booting into a non-clean filesystem. This means I can't have Slackware (my main OS) and EasyOS co-exist in the same partition.

I might try shrinking the Primary sda3 partition and creating an Extended journaled ext4 partition in the now empty space.

[BarryK]

@rudyt
I did study that issue with cheap flash sticks, and decided that ext4 journal would be ok. I think that I set something somewhere to minimize journal writes.

A couple of my usb flash sticks are SanDisk Extreme, that do, apparently, have a SSD chip.

But I think that even the cheap flash sticks have a "bad bit" recovery mechanism. When a bit goes bad, it is marked as unusable, and the flash stick carries on as though nothing has happened -- except you have less available storage.

However, I will take another look at it. I can reinstate ext4-without-journal in the .img file.
Or, go over to f2fs -- I did try f2fs many years ago and had file corruption problems, but they were the early days of f2fs, it needs reconsidering.

[hundido]

EasyOS 3.4.1 had the same problem with the screen going black.

This time I filmed my attempt at using it on my new computer. I speak Esperanto, but the words aren't really needed to see what happens. Here's my film from selecting EasyOS in the boot menu to black screen:

https://odysee.com/@Malfermitkodo:9/EasyOS-3.4.1:c

Edit: Now that the black screen problem is fixed, I took down the video. Hopefully someday soon I'll get to making a new film of Easy OS working.

[BarryK]

EasyOS 3.4.1 had the same problem with the screen going black.

This time I filmed my attempt at using it on my new computer. I speak Esperanto, but the words aren't really needed to see what happens. Here's my film from selecting EasyOS in the boot menu to black screen:

https://odysee.com/@Malfermitkodo:9/EasyOS-3.4.1:c

Esperanto, wow! I did a search to find out how many people speak it, and where:

https://www.yayesperanto.com/where-is-esperanto-spoken/

...fascinating about the free "aibnb"

Everyone who gets the black screen, it happens just after the kernel KMS GPU module loads. It seems that mostly those with recent AMD GPUs are afflicted with this problem.

[rudyt]

@rudyt
I did study that issue with cheap flash sticks, and decided that ext4 journal would be ok. I think that I set something somewhere to minimize journal writes.

A couple of my usb flash sticks are SanDisk Extreme, that do, apparently, have a SSD chip.

But I think that even the cheap flash sticks have a "bad bit" recovery mechanism. When a bit goes bad, it is marked as unusable, and the flash stick carries on as though nothing has happened -- except you have less available storage.

However, I will take another look at it. I can reinstate ext4-without-journal in the .img file.
Or, go over to f2fs -- I did try f2fs many years ago and had file corruption problems, but they were the early days of f2fs, it needs reconsidering.

@BarryK
I love this geek stuff and talking tech, but I feel we've diverged from my original issue, and the last thing I want is for you to waste your time looking into stuff that I won't use. I don't plan on running EasyOS on a USB flash drive, so I don't need you to look into ext4 without a journal or f2fs.

My original issue is with EasyOS not doing a clean unmount when run from an ext2 filesystem, and you've answered that by saying EasyOS is designed for ext4 with a journal. I'm looking into converting my ext2 to an ext4 so I can continue to run EasyOS in my shared partition. Cheers!

[BarryK]

EasyOS 3.4.1 had the same problem with the screen going black.

This time I filmed my attempt at using it on my new computer. I speak Esperanto, but the words aren't really needed to see what happens. Here's my film from selecting EasyOS in the boot menu to black screen:

https://odysee.com/@Malfermitkodo:9/EasyOS-3.4.1:c

An observation: that is an incredibly slow drive you are booting from!

I just watched your video again, and copy of easy.sfs to the working partition at first bootup, took about 3 minutes -- 180 seconds!

For comparison, today I booted a new build of Easy on a SanDisk Ultra 32GB usb3 stick (plugged into a usb2 socket), and copying easy.sfs to the working partition took 14 seconds.

The SanDisk Ultra is a middle of the range usb stick, readily available in major stores. An example of top-of-the-range is the SanDisk Extreme, which is 2-3 times faster than the Ultra.

[BarryK]

@rudyt
I did study that issue with cheap flash sticks, and decided that ext4 journal would be ok. I think that I set something somewhere to minimize journal writes.

A couple of my usb flash sticks are SanDisk Extreme, that do, apparently, have a SSD chip.

But I think that even the cheap flash sticks have a "bad bit" recovery mechanism. When a bit goes bad, it is marked as unusable, and the flash stick carries on as though nothing has happened -- except you have less available storage.

However, I will take another look at it. I can reinstate ext4-without-journal in the .img file.
Or, go over to f2fs -- I did try f2fs many years ago and had file corruption problems, but they were the early days of f2fs, it needs reconsidering.

@BarryK
I love this geek stuff and talking tech, but I feel we've diverged from my original issue, and the last thing I want is for you to waste your time looking into stuff that I won't use. I don't plan on running EasyOS on a USB flash drive, so I don't need you to look into ext4 without a journal or f2fs.

My original issue is with EasyOS not doing a clean unmount when run from an ext2 filesystem, and you've answered that by saying EasyOS is designed for ext4 with a journal. I'm looking into converting my ext2 to an ext4 so I can continue to run EasyOS in my shared partition. Cheers!

Ha ha, but now you've got me thinking about it....

https://bkhome.org/news/202203/ext4-wit ... stick.html

I have kept the journal, and changed "commit=30" to "commit=1800" -- every 30 minutes.
Could even make it a longer duration. It would be almost like not having a journal, but the f.s. still has a journal so will have clean unmount. Or so I think.

[hundido]

An observation: that is an incredibly slow drive you are booting from!

I'm not sure what to say. It's a Micro Center USB 3.2. 3.2 should be fast, right?

[oafunv]

one big con to EOS is it's meant to run from a usb stick and those tend to fail

[BarryK]

one big con to EOS is it's meant to run from a usb stick and those tend to fail

Right now I'm running Easy on my baby laptop, which has eMMC memory. As far as I know, that has wear leveling.
As does an SSD.

Regarding USB sticks, for the last couple of years I have only used SanDisk Ultra and SanDisk Extreme.
Have 4 of the Ultra, 2 Extreme, and no failure yet.
SanDisk Extreme is the best as it has a proper SSD chip with wear leveling. Don't know about the Ultra.

On my main PC, Easy is installed to a HDD partition.
I use SSDs for development work, like OpenEmbedded compiling which runs for 18 hours, so have really flogged those, no failures.

Yes, probably it is not a good idea to rely long-term on running off a cheap USB stick. If you do want the portability, buy a premium USB stick with wear leveling. The added bonus is they are very fast.

[foxy1]

I`m running easy.2.8.3 on a raspberrypi 4b card.
Is it possible to have an update to the EasyOs.3.4 series.
Thanks

[BarryK]

I`m running easy.2.8.3 on a raspberrypi 4b card.
Is it possible to have an update to the EasyOs.3.4 series.
Thanks

It is possible, it is a matter of me getting around to doing it.

Right now, doing a complete x86_64 recompile in OpenEmbedded, updated lots of packages. In particular updated mesa, llvm and libdrm for improved AMD support.

I will have to squeeze in the time to also do an aarch64 build in OE. As the build takes 18 hours and is on my main workhorse PC, that is a big chunk of time that I won't be able to do anything else. But, I can let it run overnight.

But it isn't just that, there is a lot of other stuff that has to be done to update Easy for the pi, like compile latest kernel, latest firmware. Probably another few days work.

I'll probably get around to it.

[foxy1]

I like using easy OS in my pi because its fast and efficient- great to load quickly and sort out files for copying and transfer. Just a click on the icon and files and you're there no sudo this or password that. Great OS thanks.
A problem I sometimes get, is that if I click to quickly over a partition icon it disappears and have to reboot to get it on the screen again. The screen occasionally locks up and script not functioning comes up on some websites
prompting 2 or 3 clicks to load. Its a great Operating system and Id love the upgrade but don't stress yourself.
Thanks.

[don570]

foxy1 wrote: ↑Mon Mar 07, 2022 9:31 am
I`m running easy.2.8.3 on a raspberrypi 4b card.
Is it possible to have an update to the EasyOs.3.4 series.
Thanks

Note to BarryK ...

MX Linux is doing a good job of supporting Raspberry pi
They just posted a new image 3 hours ago.

https://mxlinux.org/blog/mx-linux-raspb ... out2-beta/

https://sourceforge.net/projects/mx-lin ... erry%20Pi/

It's fast and well supported so it doesn't make sense for you to spend time on the raspberry pi.
_______________________________________________________________

[foxy1]

ive downloaded it 3 times and been unable to run it. It either doesnt boot or ends in a kernel panic.Have you actualy used it??.

[don570]

I use the earlier version that was released a year ago. It installed easily.
There's something wrong if a SD card doesn't boot up after being burnt.

I always use this command first to make sure that my card is clean...

Code: Select all

dd if=/dev/zero of=/dev/<flash-drive-device-name> bs=1M count=1

so if the device is c I use....

dd if=/dev/zero of=/dev/sdc bs=1M count=1

then I burn the image with dd command.
_____________________________________________________________________

I've read the instructions and it says it is sluggish with a raspberry pi 3.
I didn't find the previous version sluggish on a pi3+

The problem is that old models are limited to 1 GB of RAM

Technical
◦ RAM usage after login using default Tasks app: about 200 for both WMs after login, 350 after web browser (without additional extensions) has settled down
◦ Tested compatible with Pi 3b (sluggish), 4 and 400
◦ GPIO ports remain available to program through Scratch and Python
◦ Camera port works

_____________________________

[BarryK]

I was reading recently that cheap microsd cards don't have wear leveling. However, apparently the SanDisk Extreme do:

https://reprage.com/post/what-are-the-b ... spberry-pi

Wear leveling is known as "advanced Error Correction Code technology":

https://www.camerapro.com.au/6534-sandi ... -card.html

Though one wonders what that error correction code actually is. The acronym is "ECC", which in traditional ram just means each storage location has an extra bit.