kernel compiling in woof-ce

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#21 Post by rufwoof »

PXE booted (RAM) a slacko 5.3.3 variant, downloaded the tar file and extracted. Created a /DV directory and copied devx sfs to that and loaded that sfs. Ran the ubuild.sh script and around 1 minute later after pages and pages of text.

No idea what I'm doing and appreciate that you should be running using a full installed version of puppy etc - but may be of some interest/purpose (some feedback better than nowt).
Attachments
dt.jpg
(72.11 KiB) Downloaded 953 times

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#22 Post by rufwoof »

You uploaded another as I was posting. For info: downloaded that latest version and ran and similar sort of thing, downloads sources, cofigures ok, headers, pages of stuff and same error/fail point.

Quad with 4GB ram.

Redirected output to file and error messages shown (starting from around half way down)
Attachments
dt2.jpg
(80.75 KiB) Downloaded 948 times
Last edited by rufwoof on Sun 25 Jan 2015, 16:43, edited 1 time in total.

stemsee

#23 Post by stemsee »

hi rufwoof

I think the problem is that in order to build a 64bit kernel (the first third of the script is for building a 64bit kernel) you need to be running on a 64bit distro/machine!

To get around this create the file '/tmp/64' and directory distro/packages64 then the script will build the next two kernels 32bit-pae and 32bit-nopae. If that doesn't work it will take me some time to research the errors.

regards
stemsee

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#24 Post by rufwoof »

stemsee wrote:hi rufwoof

I think the problem is that in order to build a 64bit kernel (the first third of the script is for building a 64bit kernel) you need to be running on a 64bit distro/machine!

To get around this create the file '/tmp/64' and directory distro/packages64 then the script will build the next two kernels 32bit-pae and 32bit-nopae. If that doesn't work it will take me some time to research the errors.

regards
stemsee
Using a 64 bit machine, but running a 32 bit puppy (slacko 5.3.3) and its corresponding devx sfs. I'll give your suggestion a go.......

Nope.

Deleted, clean reinstalled your tar, created those directories and
Attachments
dt3.jpg
(49.71 KiB) Downloaded 935 times

Gobbi
Posts: 255
Joined: Fri 09 Mar 2012, 14:01

#25 Post by Gobbi »

stemsee wrote: Make sure /tmp/64 and /tmp/32-pae and /tmp/32-nopae are deleted if you didn't restart your machine first.
I did not see these /tmp/64 and /tmp/32-pae and /tmp/32-nopae in the end ...
Anyway I got to go ( I work out of town ...), I'' be back home next saturday . Thank you .

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#26 Post by rufwoof »

Gobbi wrote:
stemsee wrote: Make sure /tmp/64 and /tmp/32-pae and /tmp/32-nopae are deleted if you didn't restart your machine first.
I did not see these /tmp/64 and /tmp/32-pae and /tmp/32-nopae in the end ...
Anyway I got to go....
Me also (got to go)

BFN and thanks.

stemsee

#27 Post by stemsee »

I see ... so it downloaded the kernel source to dist/sources/vanilla/*.tar.xz is there already an aufs package there? Delete it. Or in build32-pae.conf line 32-33 comment out 32 and uncomment 33 for a different server for aufs.

I cannot so far replicate your error, it may be a connection or server related error. However I did find another bug after running the last script!

So here is yet another update.
Attachments
unattended-kernel-kit.zip
(120.13 KiB) Downloaded 666 times

stemsee

#28 Post by stemsee »

This latest has just worked perfectly for me. So I will add a test for 64bit cpu, if not found only 32bit pae and non-pae kernels will be built.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#29 Post by rufwoof »

Still seeing the same on a different machine, with that most recent copy of the tar file, and with your suggested changes. Otherwise not changing anything - just running the extracted files as-is.

Running with sh -x ./ubuild.sh - see attached image

I suspect its because I'm running in ram (frugal) rather than against a full install - but that's just a pure guess.
Attachments
s1.jpg
(113.4 KiB) Downloaded 910 times

stemsee

#30 Post by stemsee »

You are running in ram? Where was the kernel kit extracted to?? Mine is on a roomy usb drive. Extracted sources use about 700mb of disk space, plus the 105mb compressed kernel source download, plus aufs tools, etc, I am guessing you will need about 1.2GB dis/ram space (conservatively) on top of other usage.

However to check this kit I will boot without a savefile and leave it on compiling overnight to see if any problems arise in a pristine environment.
Attachments
capture24759.jpg
(21.75 KiB) Downloaded 881 times
capture22851.jpg
(35.61 KiB) Downloaded 908 times
capture22860.jpg
(22.65 KiB) Downloaded 902 times
capture22083.jpg
(16.58 KiB) Downloaded 907 times

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#31 Post by rufwoof »

You are running in ram? Where was the kernel kit extracted to??
Oooerr - not sure, I just installed/ran it all in/from / (ram space) with no HDD's mounted (frugal boot not full installed). I created a /DV directory and dropped the DEVX sfs into that and sfs_loaded with no copy. Downloaded your tar file to / and also extracted it to there.

The space available icon in my tray indicates 148GB - so enough space there as being a frugal boot that indicates ram space not disk space.

I did swap out the slacko 5.3.3 kernel 3.01 for a 3.10 one as the former was non-PAE whilst the latter is PAE

50Mbit internet connect speed so usually there's no problems with downloading larger files, often I run puppy from the cloud (download a 500MB 'office' sfs from my google drive that supplements a PXE booted 100MB basic/core puppy).

I guess I should do a full install of FatDog or 64 Lighthouse and test using that as that's the more formal/usual/correct way as I understand it.
Attachments
free.jpg
(9.12 KiB) Downloaded 1121 times
tree.jpg
(69.77 KiB) Downloaded 1138 times

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#32 Post by rufwoof »

Downloaded FatDog 7beta2 to my old dog, extracted out of the iso the initrd and vmlinuz files and dropped them into my tftpboot (PXE) directory and fired up the PXE server.

On another more powerful PC (my son's Windows box), booted, F12 to net boot and PXE booted fatdog. Used that session to download fatdog's devx and your tar files. Copied devx to a new /DV directory and sfs loaded that. Extracted your tar file and terminal, #./ubuild.sh ..... and its whirring away ... pages of stuff whizzing by - that looks something like a lot of CC'ing and pruning. All four cores running at 100%.

Started that off at 10pm, so probably wont see it run all the way through but looking promising.

EDIT: 10:25pm, still whirring away. Off to bed for a early morning start, powered down the PC's - my guess is that it would have run through to completion OK.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#33 Post by rufwoof »

Extracted Fatdog vmlinuz and initrd from its ISO, dropped those into a PXE server and booted that FatDog on a 4 core, 4GB ram Windows PC. Downloaded and sfs_loaded FatDog's DEVX sfs

Copied the unattended build tar file from this posing http://www.murga-linux.com/puppy/viewto ... 783#823783 to / and extracted. i.e. fatdog running in ram with no HD drives mounted

Plugged in a USB HDD and dragged the / copy of the unattended directory over to that (moved) and then dragged back again and created a symbolic link

Opened a terminal, cd to that /unattended.. directory and ran
#./ubuild.sh

All whirring away. Will progress update later.

This is all new to me so I've no idea what to expect or what/where the final output/files from a successful run might be. No changes were made to configs/scripts - all just run as-is. Guessing that they'll be some vmlinuz files for the three (64, 32-PAE, 32-nonPAE) builds, my intent is to drop one of those into a PXE server, boot to command prompt and see if that works.

stemsee

#34 Post by stemsee »

Glad to see you took the initiative to troubleshoot.

You can see how devs use a lot of time trying to figure out what a remote system's problem is ... so I often say the script is working for me.

Ther is a bug ...'conf' is missing from one place which means kernel number 3 -nopae will be pae.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#35 Post by rufwoof »

You can see how devs use a lot of time trying to figure out what a remote system's problem is ... so I often say the script is working for me.
Your leading the blind in my case. For instance I've no idea what you were saying in http://murga-linux.com/puppy/viewtopic. ... 914#812914 and whether I should have downloaded something (DOT) or whether its ok to just run everything as is - as I'm doing.

Nor do I have a clue where any of the final file(s) might be i.e
There is a bug ...'conf' is missing from one place which means kernel number 3 -nopae will be pae.
Just hope that whatever I do/highlight is of some help/use to you. Don't want to be a burden so if you feel the noob is getting in the way just say so - I wouldn't be offended.

After around a hour of running (and still going) I'm seeing a dist directory filling up with some directories/files as per the attached, which to me implies that its running ok
Attachments
1hr.jpg
(30.6 KiB) Downloaded 1067 times

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#36 Post by rufwoof »

1hr15m and started mksquashfs'ing, with some files suggested errors of files/directories missing ... shortly after it did another mksquashfs, and then reported DONE.
Attachments
xscreenshot00002.png
(111.63 KiB) Downloaded 1046 times

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#37 Post by rufwoof »

Yet more noob stuff :

Now that its all run through apparently OK and taking the 32PAE version as a example, in uattended-kernel-kit sub directory packages32-pae I have vmlinuz, aufs....,kernel_headers... and linux_kernel-3.18.3-EmSee.

In my case to boot a frugal version I assume I need that vmlinuz together with the etc and lib folders content from that linux_kernel3.18.3-EmSee folder. i.e. drop that vmlinuz into my PXE server directory, take my existing pup initrd and replace the existing /etc/modules, lib/firmware and lib/modules folders with those new ones, reform the initrd and drop that new initrd into my PXE server directory.

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#38 Post by rufwoof »

I added to my existing pup's /etc/modules the newly build one out of Stemsee's script (32PAE version) - so now that directory has DOTconfig-3.10.32.030314 firmware.dep.3.10.32, firmware.dep.inst.3.10.32 i.e. existing/original stuff and the DOTconfig-3.18.3- i.e. new one

I replaced my pup's /lib/modules and /lib/firmware with the new one

I also extracted initrd.gz (zcat initrd.gz piped through cpio -id) and edited that to add /lib/modules to also include 3.18.3-EmSee-64), reformed the initrd.gz (find | cpio -o -H newc | gzip >../initrd.gz)

.. and then remastered and booted ... to encounter a boot up failure of something like :

Loading drivers to access disk.....
Searching...
Found main puppy file...
Setting up layered file system
Dumping last lines of /tmp/bootinit.log.
FATAL: module unionfs not found
FATAL: module fuse not found
mount: mounting none on /proc/bus/usb failed - no such file or directory

i.e. PXE boot grabbed vmlinuz and initrd ok and appears to have booted through vmlinuz ok and into initrd booting ... but failing later in the boot process due to my lacking understanding of what needs to be set up/where. Perhaps due to something like booting a unionfs based newly built kernel against a existing aufs based puppy.

All told I'd say a success for my own testing of Stemsee's unattended build script - as far as I am able to test/take it. On my system assuming just one kernel was being built (rather than all three, 64 bit, 32 PAE, 32 NonPAE), looks like it would have taken around 25 minutes to run through (based on it took 75 minutes to do all three)
Last edited by rufwoof on Mon 26 Jan 2015, 09:24, edited 1 time in total.

stemsee

#39 Post by stemsee »

Thanks for your test and report.

I may will check the DOTconfig file again. I wonder if the init in your distro requires the id number appended. I may have reconfigured hastily or copied to wrong DOTconfig.

Sorry about that!

I encountered a similar problem with 64bit kernel which booted the os but the modules didn't load so mouse etc wasn't working; my 32-pae kernel boots fine though.

I will go over it thoroughly in the next few days.

EDIT: And i will write a Readme/how to for it as well, seeing as people can't read my mind!! lol

User avatar
rufwoof
Posts: 3690
Joined: Mon 24 Feb 2014, 17:47

#40 Post by rufwoof »

Its looking good as far as I understand it stemsee, great stuff in being able to get a complete novice as far as you got me. Some ironing out still looks to be done, but getting there

Cant help with whether a id string is needed or not other than a search for id in init has one extract of

Code: Select all

##130612 detect CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y...
DEVTMPFSFLG=0 #130618 set it from 3builddistro.

#100911 simple filenames specified in DISTRO_SPECS: DISTRO_ZDRVSFS, DISTRO_PUPPYSFS...
ZDRVSFS="$DISTRO_ZDRVSFS"
ADRVSFS="$DISTRO_ADRVSFS"
YDRVSFS="$DISTRO_YDRVSFS"
PUPXXXSFS="$DISTRO_PUPPYSFS"
IDSTRING="$DISTRO_IDSTRING" #from DISTRO_SPECS, string appended to kernel.qky, vmlinuz, puppy.sfs, zdrv.sfs, devx.sfs (see 3builddistro).
[ "`echo "$PUPXXXSFS" | grep '[0-9]\.sfs'`" != "" ] && NAMETYPE='traditional' #110422 has version info.

[ $layerfs ] && LAYERFS=$layerfs
[ ! $LAYERFS ] && LAYERFS=aufs #aufs or unionfs
[ "`modinfo aufs 2>/dev/null`" = "" ] && LAYERFS=unionfs #precaution..
So my completely wild guess as that seems to coincide with the boot up error is that yes it does.

Hope that's of some help. Sorry I can't help further than that.

my DISTRO_SPEC is likely wrong, currently containing

Code: Select all

#One or more words that identify this distribution:
DISTRO_NAME='Slacko Puppy'
#version number of this distribution:
DISTRO_VERSION=5.7.0
#The distro whose binary packages were used to build this distribution:
DISTRO_BINARY_COMPAT='slackware'
#Prefix for some filenames: exs: slackosave.2fs, slacko-5.7.0.sfs
DISTRO_FILE_PREFIX='slacko'
#The version of the distro whose binary packages were used to build this distro:
DISTRO_COMPAT_VERSION='14.0'
#the kernel pet package used:
DISTRO_KERNEL_PET='linux_kernel-3.10.32-slacko_PAE.pet'
DISTRO_TARGETARCH='x86'
DISTRO_XORG_AUTO='yes'
DISTRO_DB_SUBNAME='slacko14'
#32-byte alpha-numeric ID-string appended to vmlinuz, puppy_slacko_5.7.0.sfs, zdrv_slacko_5.7.0.sfs and devx.sfs:
DISTRO_IDSTRING='s140309082357ZZZZ5.7.0XXXXXXXXXX'
#Puppy default filenames...
#Note, the 'SFS' files below are what the 'init' script in initrd.gz searches for,
#for the partition, path and actual files loaded, see PUPSFS and ZDRV in /etc/rc.d/PUPSTATE
DISTRO_PUPPYSFS='puppy_slacko_5.3.3t.sfs'
DISTRO_ZDRVSFS='zdrv_slacko_5.3.3t.sfs'
DISTRO_PUPPYDATE='Mar 2014'
Which was tweaked by me from the original 5.3.3 slack version (3.01 kernel) to cater for me dropping in a later slack kernel (frojm 5.7 slacko).

Post Reply