TazPuppy 5.0 rc2

[darry19662018]

Still enjoying this version of Puppy lovely and small makes for a nice system - worth persevering with.

[mistfire]

@hamoudoudou TazPup is just a plaything. This will prove that combining two distros is possible (one must on seated on top while the other was on the bottom) without total modification of a target distro you want to puppify.

Combining puppy with other distro is a necessary in order to survive because the development team was not fully formally organized unlike debian, ubuntu, red hat, etc. And most of the puppy developers were hobbyist which has a uncertain time to maintain packages up-to-date.

@Marv the menu problem about Wifi Configuration is now fixed.

[peebee]

Hi mistfire

I tried using the tazbuilder to make a tazpup with upupbb as the puppy .iso

Sadly the resulting .iso would not boot - got kernel panic.....

I've uploaded it to:
https://my.pcloud.com/publink/show?code ... QWcSfCWJH7

in case you want to see what might have gone wrong....

Cheers
peebee

[mistfire]

@Peebee kernel panic triggers if init fails to execute. Here is what need to do to test if initrd fails

1. Extract initrd.xz from and get DISTRO_SPECS
2. Get a pristine puppy. Extract it and place DISTRO_SPECS of tazpup
3. Rebuild the initrd
4. configure the isolinux
5. Run the builder again

I hope it works

[rg66]

I tried using the tazbuilder to make a tazpup with upupbb as the puppy .iso

Sadly the resulting .iso would not boot - got kernel panic.....

I get the same thing with X-slacko-4.4 and Slacko-6.9.9.9.

[mistfire]

@rg66 thanks for feedback. Does isolinux shown on boot. And does initrd and vmlinuz sucessfully loaded?

There is one clear on the builder. Not all puppy kernels supports XZ decompression. I will switch initrd compression from xz to gz for the mean time

I think I found the persistence problem occured on @smokey and @ Marv. When I carefully studied the init script on initrd. If the filesystem of the drive was Linux filesystem, it searches for save directories only. I fix now the bug. It will now both search for save folder and save file in the linux filesystem.

[Marv]

@Marv does the savefile able to find and loaded?

The savefile is found and loaded correctly. If I add a configuration, program, or testfile into the savefile while running another pup (If in Tux, setting permissions correctly), those changes show up correctly when booting tazpup. The problem is in writing to the savefile on reboots after the first. I suspected the -u and timestamp but I both carefully set the date & time before creating and testing the savefile, disabled it in snapmergepuppy, and used a very simple non -u usbsave from an old alphaOS with no change. I also thought that snapmergepuppy might be exiting if X is running (line 174 IIRC), but either disabling that or using the old usbsave gave no change also.

[rg66]

@rg66 thanks for feedback. Does isolinux shown on boot. And does initrd and vmlinuz sucessfully loaded?

It panics at switch root.

[mistfire]

@rg66 I will try to figure out want went wrong

[mistfire]

@rg66 and @peebee may I know what kind of slitaz livecd did you use on tazbuilder?

[peebee]

I used:
http://mirror.slitaz.org/iso/rolling/slitaz-rolling.iso of 13-may-2018
from:
http://www.slitaz.org/en/get/

[rg66]

I used:
http://mirror.slitaz.org/iso/rolling/slitaz-rolling.iso of 13-may-2018
from:
http://www.slitaz.org/en/get/

Same for me.

[mistfire]

@peebee and @rg66

Try to use the slitaz-rolling-core.iso to see if the output iso triggers kernel panic on switch root.

[mistfire]

@Marv maybe your right about time stamp issue on saving session. I noticed that initrd uses localtime, when slitaz run, its uses UTC. So I put a script temporarily which sets the clock to localtime before slitaz environment run. But I need a permanent solution

[Marv]

Savefile working! snapmergepuppy requires a full find, not the busybox find as it doesn't support -mount. I had a heck of a time coming up with a full find old enough to run under glibc 2.14 which is in tazpup but finally dredged one up from a carolina light. Minimal tests as yet but it did save and preserve a test file in/home/Tux/Documents through a boot. I haven't tested more than that but I think that's progress.

Edit: Further configuration changes, panel setup, wifi setup, touchpad setup, Midori setup all saved and survive a reboot using 256Mb EXT2 savefile on the boot partition. Makes use MUCH easier. No tests to savefolder yet. Note: I do have date, timezone, and time set correctly.

[8Geee]

I popped Slitaz into my Asus eeePC-900a. Booted right up no problems. I see that the UTC clock "feature" has already been noted, but I can confirm. My guess is that might cause problems with time-stamp for sfs/saves.

At 81Mb quite the potent little pup. Programming Languages quite substantial. Desktop OK, nothing fancy, and I note scalable icons (?). Tossing in even my FF27-configured would substantially raise the iso over 100Mb.

For those who code this is quite nice.

Regards
8Geee

[darry19662018]

I found installing ntp seemed to solve the issue for me?

[darry19662018]

I have had more real fun this morning getting some Debian and Pup packages working they are Dejan's Simple GTKradio, gtkam from debian and old Gimp from Puppy(an sfs) tried to get dogradio working but it wouldn't run.

So sorry Hammy/Pelo this distro is a very usuable fun system to use and explore.

[mistfire]

@Marv thanks for reporting the solution on broken snapmergepuppy. I will try to look for a full version of find command. It seems were heading to beta stage. I need to fix the system time issue and the tazpup builder.

[darry19662018]

@Marv maybe your right about time stamp issue on saving session. I noticed that initrd uses localtime, when slitaz run, its uses UTC. So I put a script temporarily which sets the clock to localtime before slitaz environment run. But I need a permanent solution

Hi Mistfire.

Is it possible to put psync from puppy in the next revision as long as gtkdialog is installed this program can be used to alter the time to the correct one?