EasyOS version 2.3.2, June 22, 2020

[BarryK]

I have created a new firmware PET for the 5.4.1 kernel. In current release of EasyOS, Pyro and Buster, the firmware PET used in the build is 49MB. It is now 55MB, as I have found more firmware from here and there.

[BarryK]

Hi Barry,

If you have a tarball that you want to install in a new container, the Create button could be expanded to handle that. Or, an SFS.
But then, Easy Containers will still need to be expanded to recognise it. I have added this to the to-do list.

"Expanded" as used above must mean a work in progress? Is there any way I could help?

Note that SFSs need to be created by the 'dir2sfs' script. So, if you exoand the tarball to a folder named in format packagename_version_amd64, then you can run dir2sfs to convert it to a SFS.

Expanded in this case means extracted? dir2sfs seems to run and create a palemoon sfs, but can that sfs be loaded and run in buster 2.1.7 at its present state of development? (if I create it correctly)

Thanks

dir2sfs will have created a .sfs, .specs and .png files. Copy them to /mnt/wkg/sfs/easyos/debian/buster

Then click "sfsget" on the desktop and you will be able to install it as a container.

If it doesn't work, like nothing happens when you click on the desktop icon, try launching it from a terminal. You will find /usr/sbin/ec-chroot-<name of app>, for example ec-chroot-chromium which has this in it:

Code: Select all

empty -f ec-chroot chromium

Just run this in a terminal:

Code: Select all

# ec-chroot chromium

and you should see an error message if it fails.

Also, if it did start then aborted, you can find error messages in /mnt/wkg/containers/chromium/.session/tmp/xerrors-chromium.log

[BarryK]

To Barry,

Re Pyro 1.2.8.

Sea Monkey in container STILL crashes when "Preferences"
is clicked, as previously reported in 1.2.7.
Regards.

I just now tested in Easy Buster 2.1.8, it does not crash.

EDIT:
Booted Pyro 1.2.7 from a USB stick, ran SM in a container, Edit -> Preferences works, no crash.

My PC has Intel graphics.

[scsijon]

1- Just wondering why if I startup the buster containers, that they are starting in / and not their own /home as could be expected?

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

[BarryK]

1- Just wondering why if I startup the buster containers, that they are starting in / and not their own /home as could be expected?

I don't understand what you are asking.

A container is a chroot environment, with security features. So for /mnt/wkg/containers/chromium/container for example, that is the chroot path, and after executing the chroot it is seen inside the container as "/"

[BarryK]

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

Are you compiling inside a container, or on the main desktop?

[BarryK]

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

I have just now compiled binutils 2.33.1 in Easy Pyro 1.2.8 (because that is what I am running with right now).

Pyro has the linux_headers-4.14.1.pet in the devx. These are the headers that were used in OpenEmbedded when all the source packages were compiled, including glibc, and it is best to stay with these headers, unless there is a very good reason to use later version. I think that you may get conflicts with glibc if you use later headers version.

binutils compiled, no problem.

Note, same applies to Easy Buster, it has 4.19.x headers in the devx, and that should not be changed.

[scsijon]

2- It seems the kernel-headers package has the same problem as we had with the old pyro and xenial headers packages. Missing lines in .h files. I wonder what's breaking them during building, file /usr/include/x86_64-linux-gnu/sys/sysctl.h has again after # include features.h, on line 21 # include <sys.cdefs.h> missing as line 22. It's breaking some package builds that use a chroot in their build 'jailing' processes as well as core packages binutils, etc. built after the chroot, not sure what we can do except to manually add it at present as i'm doing. Not sure what else is broken yet as i'm working through as a step by step fix, but everything is pointing as kernel-headers problems, i'm wondering if it should be rebuilt a second time after the rest has been built, and the second one used instead. Thoughts please?

I have just now compiled binutils 2.33.1 in Easy Pyro 1.2.8 (because that is what I am running with right now).

Pyro has the linux_headers-4.14.1.pet in the devx. These are the headers that were used in OpenEmbedded when all the source packages were compiled, including glibc, and it is best to stay with these headers, unless there is a very good reason to use later version. I think that you may get conflicts with glibc if you use later headers version.

binutils compiled, no problem.

Note, same applies to Easy Buster, it has 4.19.x headers in the devx, and that should not be changed.

Strange. In your buster container with devx enabled (yes, I rebooted in case) I can't! Something is strange here, and trying sabotage stage0 gives the same result, which is why I was trying. I wonder if it's because they are trying to use 2.27.

Back in Xenial and (old) Pyro the fix was to add the extra line in in the sysctl.h file, then stage0 and onwards built. I'm now beginning to wonder what else is wrong in their system from our end view. It fails in a direct (non-container) build also.

Anyway, thanks for your testing, I believe you've proved it's not EasyOS, Their problem I think, and I shall add the note to the git error message and end thinking of doing a quirky sabotage build as this is the second time i've tried and both have now ended in more problems than before.

Oh, and i've just been pointed at https://github.com/tpimh/nenuzhnix and it's non-gnu toolchain https://github.com/tpimh/ngtc, and there is a non-docker branch. Maybe i'll 'play' with them next while awaiting T2 to sort itself out in things I can't help with. I did play with wayland/etc, but even that uses gnu packages so it's not what I want for my Quirky end system.

[scsijon]

1- Just wondering why if I startup the buster containers, that they are starting in / and not their own /home as could be expected?

I don't understand what you are asking.

A container is a chroot environment, with security features. So for /mnt/wkg/containers/chromium/container for example, that is the chroot path, and after executing the chroot it is seen inside the container as "/"

AH, that explains it, I was thinking it would open in it's own containerized /home, thanks..

[ras]

Then click "sfsget" on the desktop and you will be able to install it as a container.

Hi Barry,

finding the created sfs's in sfsget is easy enough, getting them to install properly is another thing. My sfses work in buster if I call the executable, so I have come to the conclusion that getting dir2sfs to create a proper .specs needs more of my attention.
Did I mention I was a bit of a noob with all this yet?

I have used Puppy for years without looking under the hood too much, but recently accepted a challenge from a friend that dropped quite a bit of coin on a librem 15 to see what I could do with EasyOS, (and his old laptop) The qfix=cap2 option used with a preconfigured browser has been an eye opener around here.

The version control and snapshots features work without a hitch on every machine tried, and we are looking forward to your next release to see debs run in their own container.

For those that have not had a look at Freecad, it is much more than a drawing program. It has FEM capabilities that allow the viewing of a part or assembly reacting under simulated loads.

[ras]

Hi Barry
Got it working as an individual container on the main desktop finally. When I looked inside my sfs at /usr/sbin/ec-chroot-<name of app>. I found

Code: Select all

empty -f ec-chroot palemoon  ec-chroot palemoon

not sure how that snuck in there as I had never edited the file before, but I had run dir2sfs on the build directory with some dubious settings prior. I also noticed the absence of a link to the executable in /usr/bin, and added it for good measure. Not sure which did the trick, and am not even sure that a link in /usr/bin is necessary. ( I peeked into your firefox.sfs for guidance).

Just a small observation:
I guess it is obvious to most users of sfsget, that once you down load a sfs, and then click on a sfs in the window, the sfsget package installer morphs into the install mode and offers you the button to install.
In the case of a sfs manually placed into /mnt/wkg/sfs/easyos/debian/buster, a broken sfs can be seen in the window, but a click on it can give no response. Seems that once the sfs is constructed better, the morphing of the gui and appearance of the install button happens. In the paragraph Install Mode, an instruction to click on your sfs in the window and some information as to what is supposed to happen next would be useful, as I was not aware sfsget was supposed to morph and not sure how to proceed.

Thanks for your help

[blgs]

Please include also the appropriate kernel-headers as a pet or sfs file in Easy os.
Currently only kernel-headers version 4.19.06 is available (as a pet)

[BarryK]

Please include also the appropriate kernel-headers as a pet or sfs file in Easy os.
Currently only kernel-headers version 4.19.06 is available (as a pet)

It is correct to have the 4.19.x kernel headers in the devx, as that is the kernel version that Debian 10 Buster was compiled for.

So, Easy Buster should really only be built with a 4.19.x kernel, as I think BusterPup and other Puppy Busters are doing.

But I want later kernels, for their new features. This does create a potential problem, as if use a matching headers pet, it may conflict with glibc, as scsijon has found.

Usually, the 4.19.x headers are fine when compiling in Easy with a later kernel.

Anyway, I plan to release next Easy with 5.4.2 kernel, and will include the headers pet in the repo.

[BarryK]

Just a small observation:
I guess it is obvious to most users of sfsget, that once you down load a sfs, and then click on a sfs in the window, the sfsget package installer morphs into the install mode and offers you the button to install.
In the case of a sfs manually placed into /mnt/wkg/sfs/easyos/debian/buster, a broken sfs can be seen in the window, but a click on it can give no response. Seems that once the sfs is constructed better, the morphing of the gui and appearance of the install button happens. In the paragraph Install Mode, an instruction to click on your sfs in the window and some information as to what is supposed to happen next would be useful, as I was not aware sfsget was supposed to morph and not sure how to proceed.

Yes, I know, there is a need to make this more logical. But, might target this for release-after-next.

[BarryK]

Bit of a quandary what to do about the 5.4.x kernel. I want the "lockdown" feaure, but audio is broken on my Apollo Lake CPU laptop, but does work on my Intel i5 CPU PC.

I don't know how many people are going to be affected.

Want to move ahead, get out the next releases. So maybe will do two builds, with 5.4.2 kernel and with an older kernel. People can try the build with 5.4.2 kernel, if no sound, they can use the other one.

Not very satisfactory though.

Blog post:

https://bkhome.org/news/201912/audio-fi ... ernel.html

[BarryK]

Easy Pyro 1.2.9 and 1.2.9.1 released:

https://bkhome.org/news/201912/easy-pyr ... eased.html

Easy Buster 2.1.9 and 2.1.9.1 released:

https://bkhome.org/news/201912/easy-bus ... eased.html

[rerwin]

Testing EasyOS 2.1.9.1 on SanDisk Ultra USB3.0, with wired ethernet connection.

1. Xerrs.log repeatedly appends:
/usr/local/pup_event/netchg: script entered
[Appears to be a debug leftover.]

2. Although xerrs.log contains:
Playing Sparc Audio '/usr/share/audio/2barks.au' : Mu-Law, Rate 8000 Hz, Mono
and no error messages, when I run 2barks it shows an error:
# /usr/share/audio/2barks.au
bash: /usr/share/audio/2barks.au: cannot execute binary file: Exec format error

From PupSysInfo:
Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 02)
• Kernel Driver: snd_hda_intel
• Memory Used: 32.00 KB
• Path: /lib/modules/5.4.2/kernel/sound/pci/hda/snd-hda-intel.ko
• Description: Intel HDA driver
and:
!!Sound Servers on this system
!!----------------------------
No sound servers found.
!!Soundcards recognised by ALSA
!!-----------------------------
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xdffdc000 irq 29

3. In PupControl panel, I selected Hardware > Sound Setup > Single card, which logged:
sh: alsawizard: command not found

HTH


My PC:
PC Manufacturer: Dell Inc.
Product Name: Dell DXP061

Motherboard Vendor: Dell Inc.
Product Name: 0WG855

BIOS Vendor: Dell Inc.
Version: 2.1.2
Release Date: 12/01/2006

Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz

[scsijon]

Downloading Pyro 1.2.9.1 now to try,

However the reason for the message is that I came across 'proot' the other day https://proot-me.github.io/, ?interesting, get a copy of the current and compile it yourself, that's what everone seems to be doing, the prebuilt are years out of date. Also if you scroll down to the Rootfs tag on the page, it has a link to containers.org's multi bases images, I wonder if they would work with your EasyOS System using a proot container of course to switch with?

EDIT: and I wonder if there is the possability of having Permanent and separate Temporary Containers. Permanent exist in their own savefile and don't loose parts until deliberately deleted, Temporary are 'cleaned out' when closed.

[rwishlaw]

Ha ha, two weeks is long enough, new versions Pyro 1.2.8 and Buster 2.1.8:

https://bkhome.org/news/201911/easy-pyr ... eased.html

The same changes in both of these releases, see release notes.

The next release? I'm hanging out for the 5.4 kernel, to make use of the new "lockdown" security feature. Will probably aim for the next releases of Pyro and Buster when the 5.4.1 kernel is available.

Radeon 580 Video card.

USB Buster 2.1.8 O.K.

USB and ISO Pyro 1.2.8 will not start X.

Same kernel? vmlinuz are different sizes on Buster and Pyro.

This problem is way above my pay scale.

USB install Pyro (EasyOS 1.2.9.1) has eliminated the above problem. I am assuming that the ISO will work as well.

Thank you.

[BarryK]

I found why sound was not working on my laptop with 5.4 kernel:

https://bkhome.org/news/201912/sound-fi ... -lake.html

If you are running 2.1.9.1 or 1.2.9.1, with 5.4.2 or 5.4.1 kernels, and sound doesn't work, and it is Intel audio, then run "lspci -nnk" to see what kernel module has claimed control of the audio.

In my case, it was 'snd_soc_skl', and I went to /lib/modules/5.4.2/kernel/sound/soc/intel/skylake, and renamed snd-soc-skl.ko to HIDEsnd-soc-skl.koHIDE -- renamed the other one also, but don't think that is really the cause.

Note, blacklisting snd_soc_skl doesn't work. Don't know why.

Then ran "depmod" and rebooted, and sound works. Let me know if that fix works for you.

Note, I am planning to upload major releases, Buster 2.2 and Pyro 1.3, either by xmas or the new year, for announcement on distrowatch. It will use the 5.4.3, or later kernel.

Between now and then, plan to write some more docs, and of course fix any bugs discovered, and there are some things that need improving.