EasyOS 4.2.7 Dunfell-series released

[BarryK]

Release notes:

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

Download link for English, French and German builds:

https://distro.ibiblio.org/easyos/amd64 ... 022/4.2.7/

Blog announcement:

https://bkhome.org/news/202207/easyos-d ... eased.html

This release contains the Limine Installer version 1.0.
You are invited to test it, though probably best to do so on a computer that can be sacrificed, just in case, not your daily workhorse.
Maybe also, run "limine-installer" from a teminal, to see if any error messages get output.

I will be releasing Limine Installer 1.0 and Limine bootloader as PETs soon, will upload them to this forum. Perhaps this evening or tomorrow.

For installing Limine to a 32-bit x86 PC, the 'limine-deploy' binary will need to be 32-bit. So I will release 64-bit and 32-bit Limine PETs.

[williwaw]

upated and the new features look good, (except I have not had a chance to replace limine with the latest, or test the installer)

the update process always re-downloads the latest .img.

I take care to keep the previous .img in the frugal directory, and for the last two updates, a manual check of the md5sum of the easy.img prior to updating, and the checking done by the script both seem to agree the easy.img is uncorrupted. The script progresses to completion of a successful update and does not error.
I am on a connection where the delta, this last time, downloaded almost instantaneously and was in plain sight while the new easy.img takes a half hour or so to download.

Often in the past, the new easy.img download failed, so I never tried to use the update feature much, and just did manual frugals. This time though and last time also, my 4.2.3 and 4.2.7.img's md5sums were good, the deltas look good, but seem unused.

With the new working partition scheme, I should never have to move any easy.img to use the update feature?

capture5999.png (43.14 KiB) Viewed 1820 times

[BarryK]

williwaw,
I'm not sure what you are asking.

If you are running 4.2.3, for example, and have /mnt/wkg/easy-4.2.3-amd64.img, then when click "update", it will just download the .delta file, and create easy-4.2.7-amd64.img, then the script will install, and you reboot.

I just tested, works great. Alfons also, sent me an email, confirming it works.

The .delta file isn't needed after the update. I will modify the update script to delete it.

Yes, leave easy-4.2.7-amd64.img where it is. It will be used for the next update.

[BarryK]

Looking through dozens of pieces of paper on my desk, some things that are in the to-do list but didn't make it for 4.2.7:

1. JWMdesk, change colour theme, didn't survive a reboot.

2. L18L (Lutz) sent me an updated momanager script.

3. philh sent me a pupRadio with the pupTelly part removed.

[BarryK]

Don't forget, if you don't like session-saving and want to go back to how it was before, direct writes to the drive, there is now that option -- click on "save" icon.

[williwaw]

Not asking much really, just reporting for that some reason, update down loads the delta but does not recreate, rather it re-download the entire easy.sfs. everything woks fine after that.

with earlier versions, one had to make a point of relocating the easy.img, but not any more? It should just work the way my wkg directory appears in the screenshot?

I use rollback on most every boot, and will have to make sure to test in a more consistent manner in the future, (a few reboots without using rollback before updating)

[BarryK]

williwaw,
That is very odd. For me and Alfons, only the .delta file was downloaded, and the 4.2.7 img file created.
With my Internet connection, downloading the 800MB full img file would take a long time, so I would know if it happened!

I will need to study the easy-update script, see why it would do what you experienced.
I'm on a different computer right now, running Easy 3.4, so cannot check the script.

Perhaps, if the merging of the .delta file fails, it then downloads the full img file.
Don't recall.

[rudyt]

williwaw,
That is very odd. For me and Alfons, only the .delta file was downloaded, and the 4.2.7 img file created.
With my Internet connection, downloading the 800MB full img file would take a long time, so I would know if it happened!

I will need to study the easy-update script, see why it would do what you experienced.
I'm on a different computer right now, running Easy 3.4, so cannot check the script.

Perhaps, if the merging of the .delta file fails, it then downloads the full img file.

I had the same issue as @williwaw - I had the 4.2.3 full image file in my WKG_DIR. The 4.2.3 file was downloaded whole and not built from a delta. Checksum was OK when I downloaded it, but when I clicked the easy Update icon earlier today, it said the checksum on 4.2.3 did not match and it downloaded the whole 4.2.7 image.

In my case, there was no delta file merging. Sorry but I deleted the 4.2.3 image, so I can't do some forensic testing

[TerryH]

Upgraded from 4.2.3 to 4.2.7. The existing easy-4.2.3-amd64.img was successfully updated with the .delta file. Upgrade went smoothly without issue.
With the recent changes to EasyOS, upgrading now is the smoothest and quickest of any upgrade process. Once again thank you for this continued development.

[TerryH]

The change to have the hwclock profiling has not fixed the issue of the hwclock being set 27 hours in forward of the actual time when hwclock is set to localtime. I was hoping that this change may correct the discrepancy. As the hwclock was correct prior to booting EasyOS, the time displayed in tray is correct.

For a while now I have had a script in /root/Startup to run hwclock --systohc to set it back to the correct localtime after a sleep. After upgrading to 4.2.7 I disabled the script and on reboot the time is still being incorrectly set forward 27 hours. This incorrect time is occurring about 15-20 seconds after start up. This occurred on 3 laptops I have run EasyOS on.

I have re-enabled the script to reset the time to correct local time.

[williwaw]

rudy, my situation is not quite the same as yours. the checksum test performed by the script was OK in my case.

Barry,
some further testing this morning, and I can report update is working fine. the following comments are not a complaint but just some small suggestions to help the user through the update process.

my internet connection to ibiblio is quite slow sometimes, but never the less, I downloaded a new 4.2.3 and made a new frugal of it in a different subfolder.
a few reboots later to set up some stuff, and, when updating....

1. the update downloaded the delta. I see now that the delta is around 50 mb, so 10 minutes or so to download is reasonable. There is just about no way a delta of that size could have been downloaded "almost instantaneously" as reported earlier, and the download I presumed to be a new easy.img was actually the delta. I also presumed the delta to be much smaller that it is, so a mistake on my part.

2. the rox window during the most recent test, along with some of the language returned by the script may have reinforced my erroneous presumptions.

Screen3.png (59.14 KiB) Viewed 1789 times

the image above was taken midway through the successful update. The rox window shows both the new and the old easy.img's, and the returned language in the update script informs
"This file has been dowloaded:
my/path/to/easy-4.2.7-amd64.img

A small different issue, should you find the time to address it, would make testing easier.
With such slow download speeds, could the orange xterm that monitors downloads could be configured different?
For me, the xterm is fixed in place on my desktop, effectively preventing me from doing anything else with my desktop when downloading. If I could access the titlebar and borders, and have a way to minimize, move it, or adjust its size, it would be nice, and if it did not terminate automatically, I might even be able to roll back through the output to see exactly was being downloaded.

Sometimes when down loading a full easy.img, it takes hours and needs multiple restarts. If this is related to ibiblio server loads, thats fine, as I am still appreciative for what they do for the linux community. My download speeds from ibiblio vary from 100 kb/sec or less, to 400 kb/sec on a good day. Other servers often deliver at 1-3 mb/sec.

post edited a day later to remove another incorrect assumption

[fanlessFREAK]

I agree that Limine has come in leaps & bounds! Posted to their discord
'New install of easyos 4.2, upgraded to 4.2.3 to 4.2.7 no problem as expected. The GREAT news is, the previous borking of an old install from 4.1 to 4.2.3, upgraded from 4.1 to 4.2.7 with Limine on a 512GB USB stick! All I had to do was change the uuid in limine.cfg. Thanks! Looking forward to my next boot of a internal m.2 nvme SSD, when I'll do the same manual upgrade from EO4.1'
With manual, I mounted the new image for the new Limine. EasyOS threw a fstab error with the example uuid in my first *change nothing* experiment
Thanks for your work
On v4.1, I was able to upgrade a EOL Android from v11 stock, to custom v12, by downloading platform-tools, extracting it to a folder in /easyos/ then replacing the older adb & fastboot in /usr/bin/ with a 'Link (absolute)' back to newer ones in the platform-tools folder
When I plumb a OnePlus 6 (A6003) with Android 10 in, PupMTP populates it as a OnePlusONE_A2001

[Airdale]

Updated two different laptops using the update script. I used the difference files for the first time.
The update process was great! Worked seamlessly. It was really nice not to have to download 800MB+ for each update.

As far as the problem with auto saving....
one laptop is fixed
one laptop does not.

Strange... they both have the same settings. I have reproduced it multiples times. One will not save changes automatically.... in fact, I keep on getting the new hardware profiling screen about the hardware clock because it doesn't remember anything.

I solved it by checking the new box that restores the legacy behavior of instant saves on the computer that will not auto save. That worked great.... and now no more problems with saving. Its installed to a hard drive so benefits of using the zram top level layer probably aren't that great in my use case anyway.

All in all seems like a great update!

[williwaw]

@Airdale

could it be rolling back each time rather than failing to keep changes?

[Flash]

So,e of the keys of the keyboqrd hqve been trqnsposed: the q qnd a keys; for instqnce: I chose the azerty keyboqrd qt first; then the us keyboqrd; then tried choosing q pqrticulqr ,odel but ,y keyboqrd; the BTC sixty one hundred C; is not listed:

Sa,e with Easy four point two point three:

[Airdale]

@Airdale

could it be rolling back each time rather than failing to keep changes?

No.... that's a good idea though. But the version stays 4.2.7 - it doesn't roll back. It just doesn't save.
I guess if it had rolled back to a previous version somehow I wouldn't have had the tick box which restored the legacy instant save type.

Thanks!

[williwaw]

@Airdale

not version, but perhaps a snapshot of a saved session? if pfix=bak was in effect you would see it briefly when it boots as it loads the sfs.

I keep on getting the new hardware profiling screen about the hardware clock because it doesn't remember anything.

I have updated and have the same thing happening.
I also have pfix=ram in the kernel line. I need to make a new snapshot soon.

[Flash]

I got the keyboard problem partially sorted. Somehow Puppy thought it was a French keyboard. Now the arrow keys don't work but all the rest seem to.

ID 046e:5500 Behavior Tech. Computer Corp. Portable Keyboard 86+9 keys (Model 6100C US)

[Airdale]

@Airdale

not version, but perhaps a snapshot of a saved session? if pfix=bak was in effect you would see it briefly when it boots as it loads the sfs.

I keep on getting the new hardware profiling screen about the hardware clock because it doesn't remember anything.

I have updated and have the same thing happening.
I also have pfix=ram in the kernel line. I need to make a new snapshot soon.

Oh, I'm sorry.... I misunderstood you. I see what you are saying now. That could be possible.
I just tried unticking the checkbox for "save as you go" type saving.... and you know what - auto save on shutdown works now.
Somehow flipping it back and forth between the modes must have reset something somewhere that was messing it up.
So all good now... just never did figure out the root cause.
But no big deal.
Thanks for the help.

[DanielSong39]

I just downloaded it today and it's working great so far, but there are a couple programs I'm trying to install

- gnumeric
- abiword

Has anyone had luck in installing these programs? If so, any help would be greatly appreciated.