pUPnGO - 6Mb ISO - Basic Building Block Puplet
Package Installer and Package Remover for pUPnGO
Attached package installer and package-remover for pUPnGO. As resources in pUPnGO are limited installing packages needs to be done differently from org. P412. The installer/remover is based on a database-file keeping track of every package and its files. Packages for pUPnGO should containg everything needed to make the contained application run on a bare pUPnGO. This removes the need for a package manager and moves the overhead from the OS to the packages. This will eventually leed to more shared files belong installed packages than is the case in org. P412. And therefore this different approach preventing removal of one package breaking another packages dependencies...
As pUPnGO was meant to be for "embedded" or single application systems the above approach make sense - if you want a more feature rich OS you would probably not start from the level of pUPnGO...
The installer/remover is dialog/Xdialog based and by default will not interfere with the org. P412 pet-installer - but a compatibility mode can be activated by removing out-commented tag in top of the installer-script.
The installer/remover only take .pets as package-formate, it needs only BusyBox applications to run. It does not handle menu-update, dependency checking, if space is available or other special features found in the original P412 installer. Most of those special tasks should be handled by using pinstall.sh and punstall.sh inside packages - which is supported...
I have tested the programs intensively in my running P412 - but might not be aware of all the features in the advanced org. P412 installer. I would appreciate any feedback on bugs, things missing etc.
As pUPnGO was meant to be for "embedded" or single application systems the above approach make sense - if you want a more feature rich OS you would probably not start from the level of pUPnGO...
The installer/remover is dialog/Xdialog based and by default will not interfere with the org. P412 pet-installer - but a compatibility mode can be activated by removing out-commented tag in top of the installer-script.
The installer/remover only take .pets as package-formate, it needs only BusyBox applications to run. It does not handle menu-update, dependency checking, if space is available or other special features found in the original P412 installer. Most of those special tasks should be handled by using pinstall.sh and punstall.sh inside packages - which is supported...
I have tested the programs intensively in my running P412 - but might not be aware of all the features in the advanced org. P412 installer. I would appreciate any feedback on bugs, things missing etc.
- Attachments
-
- pupngo_pkg_inst_rmv.pet
- Package Installer and Package Remover for pUPnGO - experimental!
- (3.96 KiB) Downloaded 453 times
-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
hv3 isn't quite as good as Opera, but it is half the size and better than dillo/netsurf and does reasonably well with rendering css and some javascript (it at least displays the puppy web desktop)
http://tkhtml.tcl.tk/hv3-linux-nightly-08_0203.gz
http://tkhtml.tcl.tk/hv3-linux-nightly-08_0203.gz
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
I have been looking at the different browsers - installed size added when introduced in pUPnGo:
Lynx will add approx. 1Mb - but no graphics...
Dillo-static build will add approx. 2Mb - some graphics
Links2 will add 4Mb - some graphics
hv3 will add 4Mb - most graphics but also render pages very nice.
The used pUPnGO-build is approx 17Mb unpacked - so when will they run reasonably in X (and no swap)?
Lynx: 24Mb (20Mb extremely slow)
Dillo: 24Mb (20Mb starts swift but freeze)
Links2: 24Mb (20Mb freeze)
hv3: 36Mb
All tested in qemu which might give readings approx. 4Mb too high...and test done with load of all qemu hw-drivers.
hv3 has superior quality, Dillo has the smallest size of the graphic browsers, links2 works both in GUI and text mode and lynx2 text mode only.
Additional comment 040510: Tried to reproduce the above and could suddenly not get pass the "loading modules..." during boot unless I had 64Mb RAM...
Reason was I had been playing with recompile of depmod as BusyBox depmod seemed very slow at boot (1,5min versus 30 sec for org. P412 depmod in qemu). But that was if RAM was higher or equal to 64Mb. So BB depmod works below 64Mb RAM but is slow where org. depmod works above 64Mb RAM and is fast...
Lynx will add approx. 1Mb - but no graphics...
Dillo-static build will add approx. 2Mb - some graphics
Links2 will add 4Mb - some graphics
hv3 will add 4Mb - most graphics but also render pages very nice.
The used pUPnGO-build is approx 17Mb unpacked - so when will they run reasonably in X (and no swap)?
Lynx: 24Mb (20Mb extremely slow)
Dillo: 24Mb (20Mb starts swift but freeze)
Links2: 24Mb (20Mb freeze)
hv3: 36Mb
All tested in qemu which might give readings approx. 4Mb too high...and test done with load of all qemu hw-drivers.
hv3 has superior quality, Dillo has the smallest size of the graphic browsers, links2 works both in GUI and text mode and lynx2 text mode only.
Additional comment 040510: Tried to reproduce the above and could suddenly not get pass the "loading modules..." during boot unless I had 64Mb RAM...
Reason was I had been playing with recompile of depmod as BusyBox depmod seemed very slow at boot (1,5min versus 30 sec for org. P412 depmod in qemu). But that was if RAM was higher or equal to 64Mb. So BB depmod works below 64Mb RAM but is slow where org. depmod works above 64Mb RAM and is fast...
-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
a little info about modutils from busybox:
(the default option even with allyesconfig is modprobe small - I usually compile the fuller version by manually selecting it in menuconfig - it adds about 17kb if I recall)
from http://git.busybox.net/busybox/tree/modutils/Config.in
(the default option even with allyesconfig is modprobe small - I usually compile the fuller version by manually selecting it in menuconfig - it adds about 17kb if I recall)
from http://git.busybox.net/busybox/tree/modutils/Config.in
- config MODPROBE_SMALL
bool "Simplified modutils"
default n
help
Simplified modutils.
With this option modprobe does not require modules.dep file
and does not use /etc/modules.conf file.
It scans module files in /lib/modules/`uname -r` and
determines dependencies and module alias names on the fly.
This may make module loading slower, most notably
when one needs to load module by alias (this requires
scanning through module _bodies_).
At the first attempt to load a module by alias modprobe
will try to generate modules.dep.bb file in order to speed up
future loads by alias. Failure to do so (read-only /lib/modules,
etc) is not reported, and future modprobes will be slow too.
NB: modules.dep.bb file format is not compatible
with modules.dep file as created/used by standard module tools.
Additional module parameters can be stored in
/etc/modules/$module_name files.
Apart from modprobe, other utilities are also provided:
- insmod is an alias to modprobe
- rmmod is an alias to modprobe -r
- depmod generates modules.dep.bb
As of 2008-07, this code is experimental. It is 14kb smaller
than "non-small" modutils.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
P412 zdrv hack
Earlier in this post I claimed that P412 would not mount a zdrv if main P412.sfs was present on HD-drive. Different approaches have been made to maintain the access to zdrv-content after a save:
Finally think I found a way to hack init in initrd - just took code from P430 init and replaced in P412 init (view attached file).
Not that I understand why the org. code doesn't work and the new code does
A new ISO-build available with modified kernel (ipv6 & fb support), hacked initrd/init so zdrv-412.sfs will mount at every boot, ALSA, various custumscripts (DISPLAY;SFS-MANAGER; GRUB HD INSTALL; TIME AND DATE MANAGER - type CONTROLPANEL at prompt or via menu in GUI) and X with JWM.
Full P412 drivers in zdrv_412.sfs - reduce at power off by using zdrvctr - potential reduction from 21MB to approx. 2MB giving a total size of installed pUPnGO of approx. 10MB on disk...
- Copy into personal save file at power off
Create a normal SFS-file with zdrv-content at power off/mount at next boot
Finally think I found a way to hack init in initrd - just took code from P430 init and replaced in P412 init (view attached file).
Not that I understand why the org. code doesn't work and the new code does
A new ISO-build available with modified kernel (ipv6 & fb support), hacked initrd/init so zdrv-412.sfs will mount at every boot, ALSA, various custumscripts (DISPLAY;SFS-MANAGER; GRUB HD INSTALL; TIME AND DATE MANAGER - type CONTROLPANEL at prompt or via menu in GUI) and X with JWM.
Full P412 drivers in zdrv_412.sfs - reduce at power off by using zdrvctr - potential reduction from 21MB to approx. 2MB giving a total size of installed pUPnGO of approx. 10MB on disk...
- Attachments
-
- zdrvhackP412.gz
- (788 Bytes) Downloaded 428 times
@technosaurus
I'd like to say thank you for your help in my issues with Classic Pup 2.14. I think 2.14 kernel is not supporting my internal ATA flahs disk. I tried pUPnGO and wow, it is super fast and sees my disk. I need to turn on my small WYSE terminal into download center. So I need only: network support, xwin autostart, dhcp config, keyboard layout selection, disk auto mount, file browser(rox??) to install samba, transmission and java by myself. Can you help me out with pUPnGO to adapt it to my needs? thanks' Andrew
I'd like to say thank you for your help in my issues with Classic Pup 2.14. I think 2.14 kernel is not supporting my internal ATA flahs disk. I tried pUPnGO and wow, it is super fast and sees my disk. I need to turn on my small WYSE terminal into download center. So I need only: network support, xwin autostart, dhcp config, keyboard layout selection, disk auto mount, file browser(rox??) to install samba, transmission and java by myself. Can you help me out with pUPnGO to adapt it to my needs? thanks' Andrew
New build with full glibc-2.6.1-1. This seems a must as mounted additional SFS-files do not update /lib/-content.
Attached create_pkg_gtkdialog130610.sh.gz - a script to build directory with most gtk-stuff. Convert to pet, sfs or build directly into pUPnGO.
Also attached 3 sfs packages containing patched versions of net-setup, pet-get and other of the original wizards to run in pUPnGO with BusyBox only. You can unpack, merge, convert to pet or build into pUPnGO.
Only useful together with above gtk-package. ISO is now close to 30Mb - but again you can cut away approx. 20Mb of drivers when saving to disk using zdrvctr.
Update 170610: Save to cd/dvd not working - working on a fix for this...
Attached create_pkg_gtkdialog130610.sh.gz - a script to build directory with most gtk-stuff. Convert to pet, sfs or build directly into pUPnGO.
Also attached 3 sfs packages containing patched versions of net-setup, pet-get and other of the original wizards to run in pUPnGO with BusyBox only. You can unpack, merge, convert to pet or build into pUPnGO.
Only useful together with above gtk-package. ISO is now close to 30Mb - but again you can cut away approx. 20Mb of drivers when saving to disk using zdrvctr.
Update 170610: Save to cd/dvd not working - working on a fix for this...
- Attachments
-
- petget_411_BB_412.sfs.gz
- patched petget for pUPnGO
- (110.12 KiB) Downloaded 414 times
-
- create_pkg_gtkdialog130610.sh.gz
- Script to fetch org. p412 packages and create directory with most gtk-stuff
- (833 Bytes) Downloaded 424 times
Last edited by goingnuts on Thu 17 Jun 2010, 19:56, edited 1 time in total.
-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
here's a really small mp3 player to test out petget
to play all files in a directory:
for x in `ls *.mp3`; do mp3 $x; done
to play all files in a directory:
for x in `ls *.mp3`; do mp3 $x; done
- Attachments
-
- minimp3-0.1.pet
- usage
mp3 /path/to/file.mp3 - (17.79 KiB) Downloaded 429 times
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Sage virtual machine
Hello goingnuts and all,
thank you for this interesting project. I instantly had the idea to use it to build a virtual machine of the sage mathematic software to run under windows.
short project outline:
1) use pUPnGO as base (without X is fine)
2) add a sage.sfs package at boot and autorun sager server (even at first boot )
3) add a virtual machine (qemu?) with open port 8000 to comunicate with webbrowser interface (from windows)
4) smooth startup and shutdown (maybe no safefile required)
5) Goal would be a reasonable fast running sage with a 1-click installation / 1-click start up from windows.
since sage.sfs is about 400 MB I am confident that this package can be much smaller than the current Ubuntu/VMware package (zipped around 990 MB, without virtual player)
Any help would be warmly apprechiated to realise this project.
Some specific questions:
How can I modify it that sage*.sfs is loaded during boot (somewhere in initrd.gz?)?
How can I make it that it communicates with windows browser over port 8000 (configuration of qemu?)?
some links
Homepage http://www.sagemath.org
sage431.sfs http://boxen.math.washington.edu/home/emil - this was made for puppy 431, so maybe wrong sfs version
current vmimage for windows http://www.sagemath.org/download-windows.html
kind regards
emil
thank you for this interesting project. I instantly had the idea to use it to build a virtual machine of the sage mathematic software to run under windows.
short project outline:
1) use pUPnGO as base (without X is fine)
2) add a sage.sfs package at boot and autorun sager server (even at first boot )
3) add a virtual machine (qemu?) with open port 8000 to comunicate with webbrowser interface (from windows)
4) smooth startup and shutdown (maybe no safefile required)
5) Goal would be a reasonable fast running sage with a 1-click installation / 1-click start up from windows.
since sage.sfs is about 400 MB I am confident that this package can be much smaller than the current Ubuntu/VMware package (zipped around 990 MB, without virtual player)
Any help would be warmly apprechiated to realise this project.
Some specific questions:
How can I modify it that sage*.sfs is loaded during boot (somewhere in initrd.gz?)?
How can I make it that it communicates with windows browser over port 8000 (configuration of qemu?)?
some links
Homepage http://www.sagemath.org
sage431.sfs http://boxen.math.washington.edu/home/emil - this was made for puppy 431, so maybe wrong sfs version
current vmimage for windows http://www.sagemath.org/download-windows.html
kind regards
emil
Re: Sage virtual machine
Hi emil
I have no clue about the application you plan to use but maybe some generel ideas:
Another way is to create a personal savefile and use SFSMANAGER (inside pUPnGO) to auto mount sage*.sfs at boot...
Third way is to convert your sage*.sfs to a pet-package, include it in the ISO and install it after boot of pUPnGO (use INSTALPACKAGE - also inside pUPnGO) ...
qemu -m 128 -boot d -hda qemu/test.img -cdrom output/output.iso -std-vga -usb -no-kqemu -net nic -net user -redir tcp:5556:10.0.2.15:8000 -soundhw sb16,es1370,adlib
and connect via windows browser: http://localhost:8000/
Good luck with you project.
I have no clue about the application you plan to use but maybe some generel ideas:
Why not merge the content of the sfs with pUPnGO? Unpack the sage*.sfs and pup_412pUPnGO.sfs, merge the content and rebuild pup_412pUPnGO.sfs and afterwards the iso...emil wrote: How can I modify it that sage*.sfs is loaded during boot (somewhere in initrd.gz?)?
Another way is to create a personal savefile and use SFSMANAGER (inside pUPnGO) to auto mount sage*.sfs at boot...
Third way is to convert your sage*.sfs to a pet-package, include it in the ISO and install it after boot of pUPnGO (use INSTALPACKAGE - also inside pUPnGO) ...
I do not know about qemu in windows but in Linux it would be starting qemu with the command like (if your application runs as a server...):emil wrote: How can I make it that it communicates with windows browser over port 8000 (configuration of qemu?)?
qemu -m 128 -boot d -hda qemu/test.img -cdrom output/output.iso -std-vga -usb -no-kqemu -net nic -net user -redir tcp:5556:10.0.2.15:8000 -soundhw sb16,es1370,adlib
and connect via windows browser: http://localhost:8000/
Good luck with you project.
sage virtual machine
hi,
thanks for your quick answer
. I will try to make it work.
cheers
thanks for your quick answer
. I will try to make it work.cheers
Embedded web server 3,3MB ISO
This is not really related to pUPnGO but shows other possibilities using building stones from Puppy...
This file contain build-script for a small embedded server using P412 modified kernel. Included in compressed file: Kernel, static BusyBox, isolinux.bin and thttpd. Only tested in a running P412. Extract the content - readme included - but most code should explain itself. Result is a webserver booting in a few seconds in qemu with examples of creating dynamic content using ash-scripting language as cgi-scripts. Iso-image approx. 3,3MB.
This file contain build-script for a small embedded server using P412 modified kernel. Included in compressed file: Kernel, static BusyBox, isolinux.bin and thttpd. Only tested in a running P412. Extract the content - readme included - but most code should explain itself. Result is a webserver booting in a few seconds in qemu with examples of creating dynamic content using ash-scripting language as cgi-scripts. Iso-image approx. 3,3MB.
using other puppies
Hi goingnuts,
I played with pUPnGO and it is very interesting. For my project I have the problem that the Sage Software is not compiling on 412. I had a look on your build script. I guess *in principle
* it could be reworked so that other puppies could be used as base. In that case I could just take my existing sfs for puppy 431 and use it.
What would be the procedure to generalize your script (i.e. taking variables for directories and sfs names). What obvious pitfalls are to be avoided?
In any case thanks in advance for any helpfull comments or suggestion.
Has anything like that beeing tried?
regards
emil
I played with pUPnGO and it is very interesting. For my project I have the problem that the Sage Software is not compiling on 412. I had a look on your build script. I guess *in principle
* it could be reworked so that other puppies could be used as base. In that case I could just take my existing sfs for puppy 431 and use it.What would be the procedure to generalize your script (i.e. taking variables for directories and sfs names). What obvious pitfalls are to be avoided?
In any case thanks in advance for any helpfull comments or suggestion.
Has anything like that beeing tried?
regards
emil
emil:
I do not think you have to compile your application. If it runs in P431 it probably also runs in P412 - try to unpack your sfs-file and copy all the content on top of an unpacked pUPnGO.sfs. Repack and try to boot and run your application. You might need some libs or other services though...
I have made pUPnGO build scripts based on P431 - and you are right: it is only a few modifications to the build script for the P412 based pUPnGo that is needed.
Also pUPnGO´s with major content from TinyCore, Slitaz or GEEXBOX can be done more or less with the same method.
I do not think you have to compile your application. If it runs in P431 it probably also runs in P412 - try to unpack your sfs-file and copy all the content on top of an unpacked pUPnGO.sfs. Repack and try to boot and run your application. You might need some libs or other services though...
I have made pUPnGO build scripts based on P431 - and you are right: it is only a few modifications to the build script for the P412 based pUPnGo that is needed.
Also pUPnGO´s with major content from TinyCore, Slitaz or GEEXBOX can be done more or less with the same method.
Xorg - setting resolution from command line
I am trying to build pUPnGO with Xorg only but I am unable to control Xorg resolution from command line...
Xvesa and rxvt (rxvt just to run killall Xvesa to exit) can be started from command line by:
or
Xorg and rxvt can be started as well by command:
but how to control resolution to ex. 800x600x24?
Xvesa and rxvt (rxvt just to run killall Xvesa to exit) can be started from command line by:
Code: Select all
Xvesa -screen 1024x768x24 & rxvt &Code: Select all
Xvesa -mode 0x0144 & rxvt &Code: Select all
Xorg -depth 24 & rxvt &-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
here is something kinda neat
Xorg & rxvt +sb -e jwm
but if you leave it like that, then closing rxvt closes jwm
I added this to the .jwmrc:
<Group>
<Name>rxvt</Name>
<Option>notitle</Option>
<Option>nolist</Option>
<Option>noborder</Option>
<Option>maximized</Option>
<Option>desktop:2</Option>
</Group>
which makes the background of the second desktop act as sort of an error log (changing it to minimized will just make rxvt disappear) ...perhaps the rxvt started like this should be a symlink so that the group name is different (in case someone wants to do a killall rxvt for their own terminals)
Edit: I made a symlink called backlog and modified above - pretty cool, but the restart, prompt, shutdown scripts will need a minor rewrite to use killall Xorg
I think (not 100% sure) you can just echo the resolution section of the xorg.conf to /etc/X11/xorg.conf ... but it seems to detect mine fine with xorg.conf deleted and no parameters passed
Xorg & rxvt +sb -e jwm
but if you leave it like that, then closing rxvt closes jwm
I added this to the .jwmrc:
<Group>
<Name>rxvt</Name>
<Option>notitle</Option>
<Option>nolist</Option>
<Option>noborder</Option>
<Option>maximized</Option>
<Option>desktop:2</Option>
</Group>
which makes the background of the second desktop act as sort of an error log (changing it to minimized will just make rxvt disappear) ...perhaps the rxvt started like this should be a symlink so that the group name is different (in case someone wants to do a killall rxvt for their own terminals)
Edit: I made a symlink called backlog and modified above - pretty cool, but the restart, prompt, shutdown scripts will need a minor rewrite to use killall Xorg
I think (not 100% sure) you can just echo the resolution section of the xorg.conf to /etc/X11/xorg.conf ... but it seems to detect mine fine with xorg.conf deleted and no parameters passed
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
technosaurus: Nice coding and workaround!
I have been stuck in the assumption that there was a command for setting resolution but I guess there is not.
The purpose was to let Xorg create xorg.conf (to skip the Xorgwizard and all the external probing stuff) - by starting Xorg without having any xorg.conf. After Xorg had created his xorg.conf, extract the resolutions found and create a very small setup-script.
Using "Xorg -configure" leaves me in a black screen (in qemu) and do not return to prompt. Using the code "Xorg -depth 24 & rxvt &" seems to always start up in max resolution found which is not always ok for jwm started via rxvt...
Maybe a script running "Xorg -configure" on a different terminal (I dont know how to do this?), kill it and if xorg.conf was created, generate the small resolution-setup-wizard ?
Or script could use your approach above: "Xorg & rxvt -e killall Xorg" or something, if returned to prompt and xorg.conf is created, the resolution-setup wizard can be generated.
I will test the last approach to see if it is a way out.
Moving Xorg to zdrv opens up for additional size-reduction using same approach as your zdrvctr removing unused Xorg drivers...
I have been stuck in the assumption that there was a command for setting resolution but I guess there is not.
The purpose was to let Xorg create xorg.conf (to skip the Xorgwizard and all the external probing stuff) - by starting Xorg without having any xorg.conf. After Xorg had created his xorg.conf, extract the resolutions found and create a very small setup-script.
Using "Xorg -configure" leaves me in a black screen (in qemu) and do not return to prompt. Using the code "Xorg -depth 24 & rxvt &" seems to always start up in max resolution found which is not always ok for jwm started via rxvt...
Maybe a script running "Xorg -configure" on a different terminal (I dont know how to do this?), kill it and if xorg.conf was created, generate the small resolution-setup-wizard ?
Or script could use your approach above: "Xorg & rxvt -e killall Xorg" or something, if returned to prompt and xorg.conf is created, the resolution-setup wizard can be generated.
I will test the last approach to see if it is a way out.
Moving Xorg to zdrv opens up for additional size-reduction using same approach as your zdrvctr removing unused Xorg drivers...
-
technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
My script used the xorg.conf to remove most of the larger unneeded drivers. Do you know a way to tell what xorg driver is loading without using the xorg.conf file?
Also I kind of wonder how GL, GLU and dri work - they must be called using dlopen or something because I couldn't find anything that had them as a dependency. If you are on a low spec machine that can utilize hardware acceleration, they may be worth including, if they can be used. Perhaps (my best guess) Xorg -configure tests this and maybe we can grep xorg.conf for those also for inclusion in the zdrv.
Also I kind of wonder how GL, GLU and dri work - they must be called using dlopen or something because I couldn't find anything that had them as a dependency. If you are on a low spec machine that can utilize hardware acceleration, they may be worth including, if they can be used. Perhaps (my best guess) Xorg -configure tests this and maybe we can grep xorg.conf for those also for inclusion in the zdrv.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].