Discussion, talk and tips
https://forum.puppylinux.com/
I don't have a problem with that. In most cases, a module would not contain files that are part of your base system. If there is duplication, the base files get priority.
If you want to increase your base system, you should do it before loading modules.
Maybe for you and me it's not a problem, but it will be for a user who tries to install a package and gets dpkg errors, e.g. because of some dependencies that are also part of the loaded module, he/she doesn't know what to do and probably thinks that the system is broken.
But anyway, as I said above, I'm very close to fixing this issue.
Fred
New loadmodule and rmbrokenlinks.sh scripts, download and changes info, see: viewtopic.php?p=11354#p11354
Fixes the problem described here: viewtopic.php?p=11666#p11666
Fred
Hi Fred! Your work is becoming a reference. Following your example, we will likely have other overlayf puppys.
I am very satisfied with my position as a user! Good luck! 
Fred: I didn't test the loadmodule and rmbrokenlinks scripts, because I didn't have to load other modules. The applications I need (LibreOffice, Gimp and others), are of the ROXapps type of FatDog and also work in DebianDog. I can do without aufs, overlayfs is a luxury for me, I adapt to any situation. Once again, congratulations on your work.
"Making difficulty an opportunity"
Hi Fred:
I don't think that this version is working as well as the previous. The "cp -s" appears to only symlink files, not directories. So the directory structure in the module gets copied into the filesystem and is left behind after deactivation.
I don't think that's how the previous version worked. The "find" command found files AND directories, so everything got symlinked and removed.
rcrsn51 wrote: ↑Mon Dec 07, 2020 1:18 amHi Fred:
I don't think that this version is working as well as the previous. The "cp -s" appears to only symlink files, not directories. So the directory structure in the module gets copied into the filesystem and is left behind after deactivation.
I don't think that's how the previous version worked. The "find" command found files AND directories, so everything got symlinked and removed.
Yes, I know, that it leaves some (or more) empty folders in the system after unloading (I mentioned in changes info), I don't really like that, could let the unload function remove empty folders, but there may be a danger in doing that, what do you think ?
With the way how the previous version worked, I cannot live, as I said, because of files created in the system that can not be overwritten.
Fred
OK, hopefully last update (became obsession for me 
), on second thought I didn't like that (empty) directories are left behind after unloading, fixed now.
viewtopic.php?p=11354#p11354
Loading and unloading seems to me a little slower, probably because of a bit more complex code.
Together with addition of a small code to the shutdown scripts to unload modules (in case forgotten to unload), I think it's a solid way now to load SFS modules under the "overlay" based system.
Fred
To have a full working SFS-load with new method using symlinks, install new versions of packages sfsload and porteusbootscripts
sfsload v1.0.8: EDIT changed to v 1.0.8
https://github.com/doglinux/sidog/raw/m ... _amd64.deb
Includes new "loadmodule" script and SFS-Load GUI (Menu > System > SFS-Load GUI).
Right-click entries Activate/Deactivate module in pcmanfm, restart pcmanfm to apply.
porteusbootscripts v0.0.9:
https://github.com/doglinux/sidog/raw/m ... .9_all.deb
Added unload function to the shutdown scripts and save2flash, to make sure any manually loaded module will be unloaded at shutdown/reboot.
Here's a "gimp" squashfs module, should work on Sid (64-bit), to try:
https://github.com/doglinux/sidog/raw/m ... 4.squashfs
Fred
Hi Fred! I compiled Kernel 5.10.0 (latest release, 2020.12.13, kernel.org) for DebianDog, this time without firmware. I'm using it now. It works well, working with all the mitigations of processor vulnerabilities. I noticed a slight delay in the 1st loading of Vivaldi (based on chromium) but, after loading, it works. However, on the 2nd loading, it locks everything.
I had noticed this behavior before with the 5.9 kernel and now the 5.10 kernel using FatDog64, except that in this case, any browser based on chromium crashes the system.
If you want to test, feel free. But it is good to inform that I run the system in RAM and do not use savefile. Firefox works normally.
Kernel Release: 5.10.0 overlayfs (latest release, 2020.12.13, kernel.org)
Build Date: 14 Dec 2020
Compiler: gcc 7.3.0
OS Support: DebianDog64 Sid - GNU / Linux
Architecture: x86_64
SMP Enabled: Yes
Low Latency, PREEMPT
Available under: It is no longer available!
Hi Duprate, I tried booting with your kernel and it works well for me, thanks.
However I'd prefer to use Debian stock kernel, to be able to install linux-headers corresponding version, dkms support etc..
I'm curious, what is your reason (advantage?) to use own compiled kernel ?
Fred
fredx181 wrote: ↑Wed Dec 09, 2020 6:21 pmHi Duprate, I tried booting with your kernel and it works well for me, thanks.
However I'd prefer to use Debian stock kernel, to be able to install linux-headers corresponding version, dkms support etc..
I'm curious, what is your reason (advantage?) to use own compiled kernel ?Fred
Hi! I like to learn new things. In the FatDog repository the kernel options are almost always out of date (adding spider webs). It is not a criticism of the system, FatDog for me is the best! Based on Linux From Scratch, it does not inherit defects and addictions from other distros. Very stable, it feels so good, so good! ... but I can't stand still! It is a necessity of mine. In addition, Kernel 5.10 is the next LTS, mitigating all vulnerabilities and I like being at the forefront! In the case of DebianDog, I found myself in new territory, where I can compile the kernel directly from the official source, without relying on third party patches! It is the search for freedom!
But when the 5.10 kernel is available in the Debian repository, I may change my mind.
Duprate wrote: ↑Wed Dec 09, 2020 9:05 pmfredx181 wrote: ↑Wed Dec 09, 2020 6:21 pmHi Duprate, I tried booting with your kernel and it works well for me, thanks.
However I'd prefer to use Debian stock kernel, to be able to install linux-headers corresponding version, dkms support etc..
I'm curious, what is your reason (advantage?) to use own compiled kernel ?Fred
Hi! I like to learn new things. In the FatDog repository the kernel options are almost always out of date (adding spider webs). It is not a criticism of the system, FatDog for me is the best! Based on Linux From Scratch, it does not inherit defects and addictions from other distros. Very stable, it feels so good, so good! ... but I can't stand still! It is a necessity of mine. In addition, Kernel 5.10 is the next LTS, mitigating all vulnerabilities and I like being at the forefront! In the case of DebianDog, I found myself in new territory, where I can compile the kernel directly from the official source, without relying on third party patches! It is the search for freedom!
But when the 5.10 kernel is available in the Debian repository, I may change my mind.
Fred
I have this installed on my laptop and I am posting from it now.
All seems to be working fine so far.
I will try to do some of the usual testing...
Hi! The 5.10.0 kernel for me is only for testing. The system sometimes crashes when I use anything based on chrome. If someone tests and works perfectly, run Chromium, Vivaldi or Google Chome, without delay and without crashing, please inform! Only test it if DebianDog is not the only system installed on the PC! In case of any problem ...
For my daily use, I am now using the 5.4.83 kernel.
Corrected, according to the recent release of version 5.10.1:
New build of Kernel 5.10.1 overlayfs, latest release, 2020.12.14. I'm testing it now, everything is working fine, there is still a delay of approximately 18 seconds with each Vivaldi load. However, there are no more crashes, even after reloading the Vivaldi about 6 times. LibreOffice, Gimp, Firefox ESR and other programs working well.
Chances of I use it daily ...
Available under: https://drive.google.com/drive/folders/ ... sp=sharing
One of the advantages of the "overlay" system is that it's possible rather easy to try out different kernels (as overlay is included by default), no need to apply aufs patches or/and build aufs module.
Here are (64-bit) liquorix kernel 5.9.0-14.1 and kernel from Debian Experimental 5.10.0-rc6 "packages", to extract in "live":
https://github.com/DebianDog/Sid/releas ... d64.tar.gz
https://github.com/DebianDog/Sid/releas ... d64.tar.gz
How I did (very basically):
- Installed liquorix kernel from here:
https://liquorix.net/debian/pool/main/l ... _amd64.deb
Info liquorix: https://liquorix.net/
- And kernel from "Experimental" here:
https://packages.debian.org/en/experime ... 4-unsigned
- Made a squashfs module from /lib/modules/<kernel>, e.g. /lib/modules/5.9.0-14.1-liquorix-amd64
- Created initrd1.xz and initrd.img (e.g. for 5.10.0-rc6-amd64) by running '/usr/local/cr-initrd/mkinitrd':
- And copied from /boot vmlinuz-<kernel> to vmlinuz1
@Duprate
Forgot to mention earlier that the script '/usr/local/cr-initrd/mkinitrd' is easy way to generate initrd1.xz and initrd.img (in /tmp)
EDIT: and question:
Duprate wrote:New build of Kernel 5.10.1 overlayfs, latest release, 2020.12.14. I'm testing it now, everything is working fine, there is still a delay of approximately 18 seconds with each Vivaldi load
Is that Vivaldi slow start also with the stock Debian kernel ?
Fred
Hello, Fred! These delays in loading the Vivaldi, are brief freezes of the system, where it is possible to notice the clock stops at the conky. It only occurs with kernel versions above 5.8. In Debian, it still works. In FatDog64, when trying to load chromium-based browsers, the system crashes completely. However, this may be a mistake of mine that has been repeated with each compilation. I will try this version of Debian, which you sent and then inform the result. Thanks!
For a long time I followed the work of "peebee" and the kernel updates he makes regularly.
Always changed the kernel, according to its releases. However, the latest releases (5.8 to 5.10), all had the same problem with the chromium, google chrome and vivaldi browsers. My only interest in the 5.10 kernel, is why it is the next LTS. While there are no other 5.10 options, for comparison, I am happy with the 5.4 series, with support until Dec 2025, which works very well! In DebianDog, I also use 5.4.83.
By the way: in the test I did with Debian 5.10.0-rc6-amd64, the keyboard and mouse did not work and the screen resolution was low.
The truth: The DebianDog, which you manage, is better than Debian itself with its huge team of maintainers with its purist philosophy, its restrictions on this and that.
Imagine: If you can do a great job on a bad base, where would you go to work on a great base? 
Why Vivaldi? It doesn't have built-in VDPAU yet.
Duprate wrote:By the way: in the test I did with Debian 5.10.0-rc6-amd64, the keyboard and mouse did not work and the screen resolution was low.
Often that is because of kernel version not matching, vmlinuz1 <> initrd1.xz <> k-5.10.0-rc6-amd64.squashfs, it could be that you have done something wrong (mixing files), can you check and try again ? Works OK for me.
EDIT:
Imagine: If you can do a great job on a bad base, where would you go to work on a great base?
Why you see Debian as a bad base ?
Fred
Duprate wrote: ↑Wed Dec 16, 2020 9:28 pmHello, Fred! These delays in loading the Vivaldi, are brief freezes of the system, where it is possible to notice the clock stops at the conky. It only occurs with kernel versions above 5.8. In Debian, it still works. In FatDog64, when trying to load chromium-based browsers, the system crashes completely. However, this may be a mistake of mine that has been repeated with each compilation.
I use Vivaldi with Fatdog64's 5.4.60 kernel without freezes or crashes. Are you saying that kernels above 5.8 compiled by you crash when a chromium-based browser (Vivaldi?) starts?
Duprate wrote: ↑Wed Dec 16, 2020 9:28 pmHello, Fred! These delays in loading the Vivaldi, are brief freezes of the system, where it is possible to notice the clock stops at the conky. It only occurs with kernel versions above 5.8. In Debian, it still works. In FatDog64, when trying to load chromium-based browsers, the system crashes completely. However, this may be a mistake of mine that has been repeated with each compilation.
I use Vivaldi with Fatdog64's 5.4.60 kernel without freezes or crashes. Are you saying that kernels above 5.8 compiled by you crash when a chromium-based browser (Vivaldi?) starts?
FWIW, I threw together a system with the 01filesystem.squashfs from Buster, the k-5.9.1-dd-amd64 kernel components from Fred and a Vivaldi squashfs module made from the vendor download package.
It all works fine.
Good afternoon! I will answer the questions that were asked to me:
"fredx181 asked": Why do you see Debian as a bad foundation?
Answer: "Full of restrictions. You can use this, you cannot use that. Example: I installed seamonkey 2.53.5.1. No sound! I installed the apulse from https://doglinux.github.io/sidog/amd64/. No sound! Okay, it was just a test, I use seamonkey a little. That's what I mean, sometimes to save a few kilobites, the user is prevented from using a certain program. However, Debian was not small because of that. Now, reiterating what I said earlier, DebianDog was great, because you did it (influenced a little, by the PuppyLinux philosophy?).
Linux From Scratch (LFS) is a good foundation!
I have used or tested many of the existing linux operating systems, but I have only identified myself with the versions of puppy linux and in recent years, FatDog64!
As for the kernel, if necessary, I can live until 2025 using the 5.4.x LTS series and still, receiving updates to come, and everything will work perfectly! The 5.10 series will only be supported until 2022! "
"step" asked: "Are you saying that the kernels above 5.8 compiled by you crash when a chrome-based browser (Vivaldi?) is started?"
Answer: "On my computer, the most recent versions (5.8 to 5.10) compiled by" peebee "and me, all had the same problem with the chromium, google chrome and vivaldi browsers. Although, on DebianDog, vivaldi when it finishes charging, it works well! I'm using it now. "
Finally, I do not want to occupy a space in this forum, which does not belong to me! Here, I am a user and will continue to follow the promising work of fredx181 and his collaborators. Thanks!
Hi Fred:
Now that I've got a Buster setup with the k-5.9.1-dd-amd64 kernel, I wanted a mini-devx for it. This one was easy because your linux-headers-5.9.1-dd_5.9.1-dd-1_amd64.deb does not require the additional "common" and "kbuild" packages that are the usual dependencies of a linux-headers package.
Bill
Duprate wrote: ↑Thu Dec 17, 2020 7:19 pmI installed seamonkey 2.53.5.1. No sound! I installed the apulse from https://doglinux.github.io/sidog/amd64/. No sound!
This works for me. I extracted the Seamonkey tarball to /opt and ran it with "apulse /opt/seamonkey/seamonkey".
Merry Christmas for everyone!
mklive-buster64 script; FossaDog64, the sound works well using dogradio.
BusterDog64; DebianDog Sid, there is no sound when starting dogradio, only if I run mplayer or some video in the browser before starting dogradio.
fredx181 wrote: ↑Wed Dec 16, 2020 6:19 pm- Made a squashfs module from /lib/modules/<kernel>, e.g. /lib/modules/5.9.0-14.1-liquorix-amd64
- Created initrd1.xz and initrd.img (e.g. for 5.10.0-rc6-amd64) by running '/usr/local/cr-initrd/mkinitrd':
2020-12-16-175305_651x91_scrot.png
- And copied from /boot vmlinuz-<kernel> to vmlinuz1
Hi Fred: I am trying to duplicate this with the 5.10.0-trunk-amd64 kernel from Debian Experimental.
Using upgrade-kernel_0.0.9_all.deb, I removed all references to aufs from the mkinitrd script, then did the same in initramfs/linuxrc.
But the new initrd1.xz won't boot. I get a red "something went wrong" message.
Any ideas? Is there a "non-aufs" version of the upgrade-kernel package that I could try?
Bill
rcrsn51 wrote: ↑Sun Dec 27, 2020 3:44 pmfredx181 wrote: ↑Wed Dec 16, 2020 6:19 pm- Made a squashfs module from /lib/modules/<kernel>, e.g. /lib/modules/5.9.0-14.1-liquorix-amd64
- Created initrd1.xz and initrd.img (e.g. for 5.10.0-rc6-amd64) by running '/usr/local/cr-initrd/mkinitrd':
2020-12-16-175305_651x91_scrot.png
- And copied from /boot vmlinuz-<kernel> to vmlinuz1Hi Fred: I am trying to duplicate this with the 5.10.0-trunk-amd64 kernel from Debian Experimental.
Using upgrade-kernel_0.0.9_all.deb, I removed all references to aufs from the mkinitrd script, then did the same in initramfs/linuxrc.
But the new initrd1.xz won't boot. I get a red "something went wrong" message.
Any ideas? Is there a "non-aufs" version of the upgrade-kernel package that I could try?
Bill
Yes, v1.0.4 from Sid Dog repo:
https://github.com/doglinux/sidog/raw/m ... .4_all.deb
Note that you cannot use the mkinitrd script seperately, it depends on the /usr/local/cr-initrd/initramfs dir in v1.0.4, including new linuxrc with added overlay in the list of modprobe modules. I think that's why you got the red message, overlay not "modprobe'd".
Fred