kernel compiling in woof-ce
4.16.5 ok for me.....Dry Falls wrote:Peebee used k4.16.2 but I haven't tried it. k4.16.1 worked for me whether I used his configuration or my own. The problem started with k4.16.3, which I tested inside and out and just plain can't get to work. k4.16.5 is behaving the same.
- Attachments
-
- Screenshot.png
- (11.51 KiB) Downloaded 566 times
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Thanks Peebee. Just downloaded 18.04 with B3 delia and it ships with k4.15.15 (very nice, by the way). Put in Stemsee's k4.16.5 and as you observed, runs well, as it does in Lighthouse --except powerdown which has the same 'lockup' (for lack of a better word) issue. If you compiled a k4.16.5-lxpup64 for your trial, I'd sure like to see your .config file.
Of course, lxpup doesn't use full pulseaudio or consolekit2 so so won't experience the same 'other' issues. I'm going over your .xinitrd now to see if I can change the startup proceedure in JL64.
Again,
thanks!
df
Of course, lxpup doesn't use full pulseaudio or consolekit2 so so won't experience the same 'other' issues. I'm going over your .xinitrd now to see if I can change the startup proceedure in JL64.
Again,
thanks!
df
Basically from Fatdog....remove -false.gz
- Attachments
-
- DOTconfig-4.16.5-lxpup64-false.gz
- (169.3 KiB) Downloaded 229 times
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Ok, Peebee. That fixed the console-keyboard issue and powerdown works correctly. Still the problem with dbus:Use alsa mixer which calls up retrovol icon tray and everything looks right.
There are umpteen new variables added building the kernel than your (or my) Dotconfig accommadates. My usuall practice is to accept all defaults. I hate to do it, but will have to track down the unusable features and start over if I'm to use this, and it would seem, any future kernels in JL64.
df
Code: Select all
dbus-daemon[7465]: Cannot setup inotify for '/usr/share/dbus-1/system.d'; error 'Permission denied'
There are umpteen new variables added building the kernel than your (or my) Dotconfig accommadates. My usuall practice is to accept all defaults. I hate to do it, but will have to track down the unusable features and start over if I'm to use this, and it would seem, any future kernels in JL64.
df
Recompiled k4.16.5. All working in both JL64 and lxpup64:
- Attachments
-
- config.gz
- real gz file
- (44.1 KiB) Downloaded 225 times
-
- Screenshot.png
- (36.3 KiB) Downloaded 463 times
-
- capture874.png
- (217.95 KiB) Downloaded 469 times
I got this working, and I have tested it out building x86_64 kernels, 4.16.8. All packages faithfully created. Sources with /lib/modules/(build,source) links; and /usr/include (headers). kernel-modules/lib/modules/ free from build and source links...finally!
aufs-util builds immediately after configuring kernel and creating headers package, recoded and working; when internet connection is likely to be alive.
aufs-util builds immediately after configuring kernel and creating headers package, recoded and working; when internet connection is likely to be alive.
- Attachments
-
- SUKK-2018.tar.gz
- genuine archive
- (185.27 KiB) Downloaded 223 times
This kernel package contains 4.16.13 - x86_64 sources and huge
Based on easy config.
https://drive.google.com/drive/folders/ ... AP9-sQ1Wre
Based on easy config.
https://drive.google.com/drive/folders/ ... AP9-sQ1Wre
With a new kernel version it is usually best to use the 4.x-rcN aufs branch until the specific branch for the new kernel becomes available.....I've done a 64-bit kernel-kit build in that way.rockedge wrote:I have compiled a 4.17 pae enabled kernel but I had to use the aufs=4.16 as the kernel-kit script could not find a version for 4.17
I am about to test it out with a 32bit Bionic build from woof-CE..just waiting for the ISO to finish writing...
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
I discovered the same problem and did the same as you.rockedge wrote:I have compiled a 4.17 pae enabled kernel but I had to use the aufs=4.16 as the kernel-kit script could not find a version for 4.17
I am about to test it out with a 32bit Bionic build from woof-CE..just waiting for the ISO to finish writing...
Maybe next time I will try peebee's suggestion and use the 4.x-rcN aufs branch.
I will also try a version with peebee's suggestion...meanwhile I have the finished pup running the 4.17 kernel
- Attachments
-
- bb1805k417.png
- (55.65 KiB) Downloaded 733 times
Now available:
https://github.com/sfjro/aufs4-standalone/tree/aufs4.17
https://github.com/sfjro/aufs4-standalone/tree/aufs4.17
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
I tried compiling 4.14.49 in slacko64 with the easy config too and it's working. Thanks for the tipstemsee wrote:This kernel package contains 4.16.13 - x86_64 sources and huge
Based on easy config.
https://drive.google.com/drive/folders/ ... AP9-sQ1Wre
https://www.mediafire.com/folder/6y6wbo ... 434mu7g3yk
Welcome Sailor Enceladus
I added some code to use the next aufs version down if latest not found ... so for 4.17 it will try 4.16 automatically.
Also with single . kernels 4.16 or 4.17 the kernel gets expanded to 4.17.0, got that sorted.
I also found two typos in the nubuild.sh script from my latest sukk download.
I compiled 4.17 and 4.17.1 no probs.
I added some code to use the next aufs version down if latest not found ... so for 4.17 it will try 4.16 automatically.
Also with single . kernels 4.16 or 4.17 the kernel gets expanded to 4.17.0, got that sorted.
I also found two typos in the nubuild.sh script from my latest sukk download.
I compiled 4.17 and 4.17.1 no probs.
Hi All,
Inherently, a more modular approach might be advantageous: an independent aufs --easier to compile and test-- which might be usable with (in?) other than one puppy vmlinuz, perhaps enabling the use of kernels published by Linux.org without having to 'start from scratch'. Does any of the foregoing make sense? And is that what peebee has done?
If so, could the aufs be used like other sfses --zdrv.sfs, fdrv.sfs-- or is the aufs still an intermediate component later to be combined into the vmlinuz?
mikesLr
As someone who has put to use several of the kernel packages (vmlinuz & associated modules/drivers) but has limited knowledge of what's actually involved, it had been my impression that in compiling a kernel for use with Puppies, aufs was necessarily incorporated into the vmlinuz as part of the compile process initiated by the script. Of course, I may have gotten the foregoing assumption partly or entirely wrong.peebee wrote:Now available:
https://github.com/sfjro/aufs4-standalone/tree/aufs4.17
Inherently, a more modular approach might be advantageous: an independent aufs --easier to compile and test-- which might be usable with (in?) other than one puppy vmlinuz, perhaps enabling the use of kernels published by Linux.org without having to 'start from scratch'. Does any of the foregoing make sense? And is that what peebee has done?
If so, could the aufs be used like other sfses --zdrv.sfs, fdrv.sfs-- or is the aufs still an intermediate component later to be combined into the vmlinuz?
mikesLr
The kernel sources are patched with patches from aufs sources. Then the kernel source is compiled with aufs capability. Aufs can be built as modules, but for most puppes it is built into the kernel at compile time, for booting purposes loading and layering the main.sfs and kernel-modules.sfs before performing a switchroot into the mounted layered filesystem. The aufs-utils are built from source and added to the kernel-modules.sfs.
Peebee has built the latest kernel 4.17, for which the aufs sources on github did not yet have a branch for. They are maintained by a Japanese person. Aufs has not been accepted into the mainline kernel by Torvalds (linux kernel king), but overlayfs has been accepted.
So Peebee compiled the 4.17 kernel using the aufs.x-rcN branch; while others used the 4.16 branch with the 4.17 kernel as there is not too much difference.
Using modules compiled with one kernel on another kernel is usually problematic, though there is some limited portability, but usually doesn't work!
Peebee has built the latest kernel 4.17, for which the aufs sources on github did not yet have a branch for. They are maintained by a Japanese person. Aufs has not been accepted into the mainline kernel by Torvalds (linux kernel king), but overlayfs has been accepted.
So Peebee compiled the 4.17 kernel using the aufs.x-rcN branch; while others used the 4.16 branch with the 4.17 kernel as there is not too much difference.
Using modules compiled with one kernel on another kernel is usually problematic, though there is some limited portability, but usually doesn't work!