Auto-build a Puppy iso; single script with optional gui

[ally]

ok, still struggling

I've created a huge-kernel using stemsee's SUKK and placed it in local repositories/huge-kernel folder

running the script it does not pick up my kernel but downloads selection 29

what am I doing wrong?

[peebee]

ok, still struggling

I've created a huge-kernel using stemsee's SUKK and placed it in local repositories/huge-kernel folder

running the script it does not pick up my kernel but downloads selection 29

what am I doing wrong?

Is local repositories/huge-kernel linked back to woof_out****/huge_kernel ?

It needs to be....

Similar to packages-pet and packages-*** which are links

[davids45]

G'day wiak,

Confirming ally's result, I also tried the idea of having just one huge-kernel in the local repositories/huge-kernels directory (trying a Xenial kernel) but still only made a StretchPup with its 'in-built' one kernel option, this after editing the _00build.conf file found deeply buried in the woof-CE-testing directory as suggested earlier in this thread. No guarantee I did things correctly .

Can extra kernels in my huge-kernels directory be added to the --KERNEL list (with extra numbers, 30, 31, etc) with any effect? I'm impressed with peebee's ArtfulPup so would like to try this latest Ubuntu option if possible in makepup.

Thanks again for your continued input.

David S.

[musher0]

Hi ally.

Nothing, probably.

As for me, I didn't fight it.

In my xenial32 incarnation, I replaced the default vmlinuz and zdrv with
-- stemsee's kernel 4.1.2
-- manually
-- in the iso (with isomaster)
-- after wiak's automaton had finished creating the Pup.

The only thing you have to do is rename stemsee's
-- modules-something.sfs which in his kernel archive with
-- a valid zdrv name corresponding to the name of the main sfs,
-- for example: zdrv_xenial_7.0.6.sfs.

IHTH.

If that's the only thing that's left to do, IMO wiak doesn't need to alter his script!
To do so would be encouraging laziness in people!!!

BFN.

[ally]

I've just created a dedicated huge-kernel repo

http://archive.org/download/Puppy_Linux_Huge-Kernels

I'm going to try altering the script URL and give it another whirl

sorry peebee, I don't understand what you've written

I'll report back if it works

[ally]

ok, the script doesn't like the repo format so no joy

if anybody understands how to run the add kernel button let me know or can build xenial64 with 4.4.35

[stemsee]

Hey everyone! Thanks for the mentions.

I am going to check this out! SUKK is evolving and now comprises one single script 'nubuild.sh' which at the end offers to install the new kernel ... it should be easy to modify the script to work from within the build environment and/or copy/link to kernels directory. And/or adjust the pup build script to download from ally's repo.

Please feel free to alter my build scripts and configs as your project needs, taking care to rename the script with some personalised prefix ... such as in the case of peebee 'pbuild.sh' etc!

I'll report back when successful.

[wiak]

Is local repositories/huge-kernel linked back to woof_out****/huge_kernel ?

It needs to be....

Similar to packages-pet and packages-*** which are links

Sorry, I'm pretty sure the above suggestion that woof-out_*/huge_kernel should symlink back to local-repositories/huge_kernel isn't correct, but I'll have to check all that again to be sure. Rather, there is code in support/huge_kernels.sh that I believe is designed to copy any huge kernel in local-repositories/huge_kernels over into woof-out_*/huge_kernel/.

I'm busy working on something else (and still am), so sorry, I haven't tried this out yet (was also waiting on further reports). I'll try to make time in next day or two and hopefully find out what is going on. As for using ally's huge kernel repo instead of the ibiblio one, that will be a different matter that will need looked into.

In the meantime, the following is the relevant code section in the official woof-CE support/huge_kernels.sh (testing branch) script - as you should see, symlinking does not apply for this:

Code: Select all

download_kernel() {
	local URL="$1" TARBALL="${1##*/}"
	if [ -f ../../local-repositories/huge_kernels/${TARBALL} ] ; then
		echo "Verifying ../../local-repositories/huge_kernels/${TARBALL}"
		if tar -taf ../../local-repositories/huge_kernels/${TARBALL} &>/dev/null ; then
			cp -fv ../../local-repositories/huge_kernels/${TARBALL} ../huge_kernel/
			return
		fi
	elif [ -f ../huge_kernel/${TARBALL} ] ; then
		echo "Verifying ../huge_kernel/${TARBALL}"
		if tar -taf ../huge_kernel/${TARBALL} &>/dev/null ; then
			cp -fv ../huge_kernel/${TARBALL} ../../local-repositories/huge_kernels/
			return
		fi
fi

It is possible I have made an error in makepup function huge_kernel_mod (I no longer remember my test of it so have to recheck). I had to modify that function a while back because of a change made at woof-CE. I need to reinstall a few things before I can test it again though so may take a couple of days.

By the way, I remember BIlltoo using his own huge kernels all the time so maybe he could chip in again and explain what he does exactly. As far as I remember he simply copied the huge kernel he wanted into woof-out_*/huge_kernel in manual woof-CE script runs (with makepup the pause option would stop the script at the appropriate time to do the same - however, putting the kernel into the kernels2add folder, being local-repositories/huge_kernels, should be working but apparetly from your reports isn't... Maybe find time to resolve the issue tomorrow - I don't think it will be difficult to fix (just need to shelve the other project I'm otherwise too focussed on for a while...).

Suggested test would be to download a known good huge kernel (such as the one ttuuxxx has stored at smokey01 site for use in his Stretch build). Then try getting that to be used via storing it in local-repositories/huge_kernels (the folder opened with kernels2add button). If that doesn't work (which will have to be fixed then), try storing it in woof-out_*/huge_kernel instead. That's what I will test with to find out what exactly is going on. Make sure of course that kernel used not being forced in _00build.conf.

wiak

[wiak]

Okay, just put Slacko64 back on my machine (I had to take that and woof-CE off temporarily last week cos my laptop is very low on hard drive space at the moment and I needed to free space my other current project). Anyway, put it all back on again (except running makepup on a usb stick to have sufficient test space for that). Alas, it is late night here but rest assured I will definitely now look into the kernels2add situation tomorrow when I wake up.

Unfortunately that ttuuxxx Stretch kernel is just 32bits so I'll download one of the ibiblio ones but try getting it to be used (in makepup build of XenialDog64) from local-repositories/huge_kernels instead of via drop down menu list.

http://distro.ibiblio.org/puppylinux/huge_kernels

wiak

[wiak]

Been looking at the woof-CE support/huge_kernels.sh code again, and I think I see the issue. Will have to fix makepup it seems... Thanks for pointing out the problem ally.

It would appear that if you use the -p (pause) switch with makepup, and during that pause you copy the kernel you want used into woof-out_*/huge_kernel, that should work (that kernel will be used in the build I think).

The key line in support/huge_kernels.sh is:

Code: Select all

IS_KERNEL=`ls ../huge_kernel/*.tar.* 2>/dev/null | wc -l`

As long as IS_KERNEL becomes equal to 1 that means a kernel is already available and it woof-CE will use it. If it's more then one in woof-out_*/huge_kernel that will cos a problem I'll have to fix in makepup though.

The kernels2add local-repositories method won't work at the moment. But, I won't know if all this is true till tomorrow when I have time to try it out.

wiak

[wiak]

My goodness. I left makepup running overnight to build xenialpup64 but it's still running hours later! woof-CE really slow with my current set up - presumably because I'll building to a usb2 flash stick (I normally use my harddrive - looks like I'll have to free up space on there afterall because this is too painfully slow and testing/debugging kernel loading would take forever with this arrangement...).

wiak

[wiak]

Testing makepup 0.1.3 at the moment, with modified kernel2add code, which will hopefully work now. Will publish in a few hours once tested, if all working...

wiak

EDIT: my first test of 0.1.3 seems to be working. I had put a slacko 64bit kernel in my new local-repositories/kernel2add (no longer named kernels2add) and seems to have been correctly picked up during the makepup xenialdog64 build (i.e. the new makepup 0.1.3 correctly ignoring the dropdown huge-kernel list selection in this case where kernel2add folder contains a huge_kernel tarball. More testing required though before I upload this.

EDIT2: All went well and the new xenialpup64 booted successfully with the kernel2add slacko 64bit huge_kernel I put in there. I'm now testing the new makepup 0.1.3 version with two different huge_kernels put into local-repositories/kernel2add/ folder. If my other makepup fix works, then woof-CE will then automatically stop makepup and ask the user to select which of the two huge kernels they want to use before proceeding (that is a woof-CE feature I had disabled in makepup but hopefully works fine re-enabled). We will see...

[wiak]

makepup version 0.1.3 uploaded.

Changes ver 0.1.3:

Modified kernels2add to kernel2add routines so huge_kernel tarball placed in local-repositories/kernel2add/ will be automatically used in preference to any other selected. (Note folder name changed from kernels2add into kernel2add (singular).
If more than one huge kernel tarball in local-repositories/kernel2add then script will automatically pause during 3builddistro-Z process and ask user to choose from these kernels.

wiak

[wiak]

Sorry to the one downloader. I made an error - will re-upload makepup ver 0.1.3 shortly.

[ally]

thanks, I was just running it....

[wiak]

Re-uploaded hopefully fixed makepup ver 0.1.3. kernel2add tested as working on this one.

Changes ver 0.1.3:

Modified kernels2add to kernel2add routines so huge_kernel tarball placed in local-repositories/kernel2add/ will be automatically used in preference to any other selected. (Note folder name changed from kernels2add into kernel2add (singular).
If more than one huge kernel tarball in local-repositories/kernel2add then script will automatically pause during 3builddistro-Z process and ask user to choose from these kernels.

wiak

[ally]

hi wiak

_13 ran with huge kernel in >local repositories?huge kernel

the script worked correctly and picked up the kernel (4.4.35) for the build

unable to test the ISO yet as running an upload to archive.org, will test later today

cheers!

[ally]

well my experiment failed, although the ISO built correctly boot failed with xz compression not supported

appreciate the effort wiak, thanks for sorting the add kernel

[davids45]

G'day wiak,

I've done a quick try of makepup-0.1.3, setting the default Pup as StretchPup (7.0.0.2a) but with a Xenial kernel.
I made the singular kernel2add directory and copied the Xenial huge kernel (4.9.56-lxpup-32-pae) to that then ran ./makepup.

After a few prompted inputs during the build, I got a new makepup directory, including in the usual place, a StretchPup iso and then used the /build files for a manual Frugal.

This booted and ran, and once I'd loaded up my regular application sfs and pets, and made a few fixes for printing, it all seems to be working despite the mixed build+kernel.

Next, I'll more slowly try something, with the right added pets to fix certain problems and perhaps use a slacko kernel in a Xenial Pup.

Thanks for your continued clever adaptions.

David S.

[mistfire]

Hi is it possible to add default desktop environment selection? So we can build puppy without gui, xfce, lxde, or kde build