kernel compiling in woof-ce
Noob/unfamiliar - how do you know/how can you tell if zram is being used?
I've modprobe'd zram to activate the zram module as the first line in init, and then exec sbin/init and pup boots to desktop and works ok, but I've no idea how to see if its using zram or not.
System information and selecting kernel modules indicates that zram and lz4 compression are both installed.
Summary shows 210MB used and I know that the puppy uncompressed size is around twice that (399MB)
I've used non-layered file system, initrd and pupsfs files all dumped in together and just lz4 compressed those when creating the initrd.lz4, which comes out at around 200MB, but presumably when booted extracts/uncompresses into memory and without zram would presumably take up 399MB of ram, but with zram would presumably come out at around half that - which seems to be the case (210 MB indicated).
So my guess is that I'm running with zram active and working - but lack the knowledge of how to confirm such.
TIA.,
I've modprobe'd zram to activate the zram module as the first line in init, and then exec sbin/init and pup boots to desktop and works ok, but I've no idea how to see if its using zram or not.
System information and selecting kernel modules indicates that zram and lz4 compression are both installed.
Summary shows 210MB used and I know that the puppy uncompressed size is around twice that (399MB)
I've used non-layered file system, initrd and pupsfs files all dumped in together and just lz4 compressed those when creating the initrd.lz4, which comes out at around 200MB, but presumably when booted extracts/uncompresses into memory and without zram would presumably take up 399MB of ram, but with zram would presumably come out at around half that - which seems to be the case (210 MB indicated).
So my guess is that I'm running with zram active and working - but lack the knowledge of how to confirm such.
TIA.,
I just compiled 3.18.7 32 pae and 64 bit kernels with lzo and lz4, natively supported by this kernel. Actually I thought that I had compiled in (not module) lz4 for previous kernel.
As for testing zram
http://wiki.gentoo.org/wiki/Zram
As for testing zram
Code: Select all
dmesg | grep zram
cleaning is performed by typing
or to run as is reusing resources unpacked kernel sources etc.
Code: Select all
./ubuild.sh clean
Code: Select all
./ubuild.sh
I was able to get it to compile 3.18.7 tonight without any errors. What error did you get? That'll help someone diagnose the problem.Ghost Dog wrote:Did you have to do anything special to get 3.18.7 to compile? Because I'm trying to do that with the normal kernel kit and it's stopping with errors...
I will add another feature to update configs from manually configured .config files 'make menuconfig' updates. It will unpack the kernel apply patches then run 'make menuconfig' three times one for each DOTconfig file and save it to the relevant DOTconfig: 64, pae, nopae.
Also I tend to supply feature rich configs with too much firmware and too many drivers/modules which will not likely get used. I am going to look into making minimal compiles for those who like smaller packages. With a line of code to switch between sets of DOTconfig files.
Also I tend to supply feature rich configs with too much firmware and too many drivers/modules which will not likely get used. I am going to look into making minimal compiles for those who like smaller packages. With a line of code to switch between sets of DOTconfig files.
StemsUnKernKit-0.8
DOTconfigs have no kernel version info in their names.
Update DOTconfigs (64,pae,nopae) in series. At the first menu option input 888, then at configure kernel menu select option 2. Manual config for 64, then for pae, then for nopae, each successive .config will be copied from and back to the relevant DOTconfig in ../configs_extra/ . After all three have been updated the script will continue to compile 64bit kernel or enter 'Ctrl+c' to exit.
DOTconfigs have no kernel version info in their names.
Update DOTconfigs (64,pae,nopae) in series. At the first menu option input 888, then at configure kernel menu select option 2. Manual config for 64, then for pae, then for nopae, each successive .config will be copied from and back to the relevant DOTconfig in ../configs_extra/ . After all three have been updated the script will continue to compile 64bit kernel or enter 'Ctrl+c' to exit.
- Attachments
-
- sukk-0.8.tar.gz
- (114.72 KiB) Downloaded 345 times
There is the original script by Iguleder and then 01micko, which I have altered. I added my own time stamp, there was already $TODAY, I didn't add it to modules.sfs because at the end of the script they are moved to a dir with $timestamp which goes to the minute and takes care of multiple compiles in one day without overwriting. If the kernel source.tar.bz2 or .sfs package is overwritten it doesn't matter, only the kernel version is important.
Has anyone else noticed the strange events at www.kernel.org ???
Having completed the unattended kernel kit - the latest kernels are labelled thusly 3.19 and 4.0-rc1 ... The script can be tricked to accommodate then naming for kernel and aufs. But now it needs an update! Funny that! Sods law!
Having completed the unattended kernel kit - the latest kernels are labelled thusly 3.19 and 4.0-rc1 ... The script can be tricked to accommodate then naming for kernel and aufs. But now it needs an update! Funny that! Sods law!
Here is 4.0-rc1 kernel and modules. But no aufs. And I haven't tested yet because I don't have a full install to test it on. It should be ale to load a rufwuuf style virtual full install in initrd for boot to ram. Oh it is 64bit.
https://mega.nz/#!lBp3EJQR!521FnLuB1Cju ... LjuR3aVejA
https://mega.nz/#!lBp3EJQR!521FnLuB1Cju ... LjuR3aVejA
here is 3.19 with aufs, 64bit, tested. Verbose boot.
https://mega.nz/#!wUwVSJiI!SssrKaNw-sqX ... nhFhoyYEmY
https://mega.nz/#!wUwVSJiI!SssrKaNw-sqX ... nhFhoyYEmY
Hi Stemsee
I notice when I look inside your kernel-modules.sfs for 3.18.6-pae and 3.19 that they only have the /lib directory whereas the kernel packs produced by 666philb have lots of other directories.
Can I drop your kernels into woof-ce puppies like tahpup and slacko6beta just by renaming the kernel-modules.sfs appropriately - or is there more to do?
Grateful for any guidance you can supply.
Thanks
peebee
I notice when I look inside your kernel-modules.sfs for 3.18.6-pae and 3.19 that they only have the /lib directory whereas the kernel packs produced by 666philb have lots of other directories.
Can I drop your kernels into woof-ce puppies like tahpup and slacko6beta just by renaming the kernel-modules.sfs appropriately - or is there more to do?
Grateful for any guidance you can supply.
Thanks
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
Hi peebee
the /etc dir holds DOTconfig-kernel-version
the /boot dir holds system.map
/usr/include for headers
and /lib holds firmware and modules
/usr/sbin /bin for aufs related components.
I compiled them manually... I just dropped them in place, and they are running. I haven't tried compiling with them or running apps which depend specifically on those kernel headers. I can supply the patched sources.
the /etc dir holds DOTconfig-kernel-version
the /boot dir holds system.map
/usr/include for headers
and /lib holds firmware and modules
/usr/sbin /bin for aufs related components.
I compiled them manually... I just dropped them in place, and they are running. I haven't tried compiling with them or running apps which depend specifically on those kernel headers. I can supply the patched sources.
Linux founder, Linus Torvalds, explains the sudden move to 4.0
http://www.zdnet.com/article/linux-kern ... er-to-4-0/
http://www.zdnet.com/article/linux-kern ... er-to-4-0/
Yes. k3.18.7 identifies itself as 'Unicorn' which tells me kernel.org has partnered with redhat. In Lighthouse, k3.18.7 misses the hardware clock altogether at bootup, and when the desktop appears, it goes immediately into screen-saver mode. Then it starts to get interesting. This may not be your experience, but it's how it plays out on my machine. It's almost like the kernel expects a full installation and gets confused by the puppy layered architecture -- looking in the base file for something in the save file and vice versa.stemsee wrote:Has anyone else noticed the strange events at www.kernel.org ???
Another illustrative read is who's writing linux today? from the same source.
df