kernel compiling in woof-ce
kernel-4.1.6-pae
http://tinyurl.com/pe8zok4
sources
http://tinyurl.com/ogft7ly
x64
https://mega.nz/#!1RIgSSzD!RgXoXH7K6_JR ... BOH13LoSbg
sources
https://mega.nz/#!4I4SUC5L!cVM9Hn-Sbsvf ... YwkuTjCQt8
i486
https://mega.nz/#!VIJhCRCI!ybDnwSEgGJ1A ... WtJMpkWuUI
sources
https://mega.nz/#!BAI0WSTD!HKl4DKkZpMM7 ... 8TNGO-jkXw
http://tinyurl.com/pe8zok4
sources
http://tinyurl.com/ogft7ly
x64
https://mega.nz/#!1RIgSSzD!RgXoXH7K6_JR ... BOH13LoSbg
sources
https://mega.nz/#!4I4SUC5L!cVM9Hn-Sbsvf ... YwkuTjCQt8
i486
https://mega.nz/#!VIJhCRCI!ybDnwSEgGJ1A ... WtJMpkWuUI
sources
https://mega.nz/#!BAI0WSTD!HKl4DKkZpMM7 ... 8TNGO-jkXw
Thanks Stemsee
Tested with LxPup-15.06.
Confirmed - can now select from list of savefiles/folders on boot with usb keyboard - thanks
Drivers succesfully compiled: Nvidia-304.128, Broadcom wl-223.248, Ralink mt7601u and ndiswrapper-1.59.
Looking good here.
Cheers
peebee
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
Hey Stemsee, I know you've compiled working 4-series kernels, but have you managed to build a working 4-series initrd? Because mine keeps trying to find something at boot, giving me "-iname" errors.
Maybe there's some module or folder the init script is looking for that doesn't exist in the 4-series kernel modules?
All I know is - it's really frustrating.
Maybe there's some module or folder the init script is looking for that doesn't exist in the 4-series kernel modules?
All I know is - it's really frustrating.
@Chilli Dog
If you have edited your initrd maybe something (init script, DISTRO_SPECS) got corrupted. Did you keep backup? Which pup are you trying to use it with? I can only imagine that you have maybe tried to change the kernel version in the DISTRO_SPECS or your initrd might be looking for the DISTRO_IDSTRING on the initrd or modules sfs or the initrd. I am not sure which files get the idstring appended, but maybe an older init script will need it. I am only guessing.
If you have edited your initrd maybe something (init script, DISTRO_SPECS) got corrupted. Did you keep backup? Which pup are you trying to use it with? I can only imagine that you have maybe tried to change the kernel version in the DISTRO_SPECS or your initrd might be looking for the DISTRO_IDSTRING on the initrd or modules sfs or the initrd. I am not sure which files get the idstring appended, but maybe an older init script will need it. I am only guessing.
Stemsee, I've been playing with k4.1.6-EmSee-64 in lxpup64 and JL64 and noticed about 20 extra processes going on at booting X in either. It tapers off in lxpup64 but stays up there in jl64. Then I re-compiled it with the big module package (and your dotconfig64 for k4.1.6) but makes no difference. Still using suuk-universal since SUKK_Universal_GM (and GooMega) wouldn't patch aufs. Any idea where these extra processes are coming from? As near as I can tell, it's more instances of dbus daemon, but why?
Other than that, I like this kernel. It seems (x-ing fingers) to have cured my problem with rox crashing and losing the usb keyboard + monitor.
df
Other than that, I like this kernel. It seems (x-ing fingers) to have cured my problem with rox crashing and losing the usb keyboard + monitor.
df
@Dry Falls
Interesting!
I will go through the configs thoroughly when i build 4.2.x, as i do not see the point in working on that kernel anymore. More instances of dbus kernel might derive from the fact that more features for passing hardware to a virtual machine have been enabled. I will research this a little before compiling the next batch.
Interesting!
I will go through the configs thoroughly when i build 4.2.x, as i do not see the point in working on that kernel anymore. More instances of dbus kernel might derive from the fact that more features for passing hardware to a virtual machine have been enabled. I will research this a little before compiling the next batch.
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
I just updated kernel-kit to add support for deblobbed and longterm kernels.
stemsee - feel free to add your kernel configuration to woof-CE, so others can use it more easily.
stemsee - feel free to add your kernel configuration to woof-CE, so others can use it more easily.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
I did a remaster with this k4.1.6 and for some reason, that settled down the persistent processes. Still more at boot (your explanation makes sense!), but now they taper off.stemsee wrote:More instances of dbus kernel might derive from the fact that more features for passing hardware to a virtual machine have been enabled. I will research this a little before compiling the next batch.
df
Update to SUKK-Universal with new deblobbing by Iguleder added.
https://mega.nz/#!EVxEDCCL!zjznzKKYgFAM ... N6EubBjDcM
https://mega.nz/#!EVxEDCCL!zjznzKKYgFAM ... N6EubBjDcM
For anyone who downloaded yesterday's SUKK and found the deblob failing here is the replacement ubuild.sh script with all corrections and offers to upgrade your kernel and modules.sfs on running system (not fd LH or Quirky, only regular frugal pups at the moment). This feature will be extended to upgrade kernel and modules.sfs on other installs and full installs too at some point.
ubuild.sh
ubuild.sh
- Attachments
-
- ubuild.sh.gz
- fake .gz
- (58.25 KiB) Downloaded 253 times
There was an unused variable floating around so aufs-utils build failed.
- Attachments
-
- ubuild.sh.gz
- (58.24 KiB) Downloaded 271 times
Hi stemsee
It would be great if your kernel builds could be used in woof-ce system builds....
They need to have a specific naming format as shown in the attachment - the archive needs to be: huge-kname.tar.bz2
and the internal components need to be: kernel-modules.sfs-kname and vmlinuz-kname
where kname is the kernel name
Any plans for new kernel builds? Perhaps they could be woof-ce compatible?
Thanks
peebee
It would be great if your kernel builds could be used in woof-ce system builds....
They need to have a specific naming format as shown in the attachment - the archive needs to be: huge-kname.tar.bz2
and the internal components need to be: kernel-modules.sfs-kname and vmlinuz-kname
where kname is the kernel name
Any plans for new kernel builds? Perhaps they could be woof-ce compatible?
Thanks
peebee
- Attachments
-
- Screenshot.png
- (23.44 KiB) Downloaded 806 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
This line went missing
building k4.2.5 64, pae and nopae
Code: Select all
CONFIG=`find $CWD/dist/sources -type f -name 'DOTconfig*'`
building k4.2.5 64, pae and nopae