Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 15 Nov 2019, 17:47
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
FirstRib default WeeDog Linux build system
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 18 of 48 [709 Posts]   Goto page: Previous 1, 2, 3, ..., 16, 17, 18, 19, 20, ..., 46, 47, 48 Next
Author Message
westwest

Joined: 10 Apr 2015
Posts: 71

PostPosted: Sat 10 Aug 2019, 13:01    Post subject: firstrib  

Having followed instructions on this thread, i've managed to get a frugal Void install booting to X with Openbox. The technicalities of the procedure fly largely over my head, but i can appreciate the accessibility and flexibility of the system as is, and will continue to tinker with Firstrib in my modest way, learning from it and hoping for further developments.

The Firstrib-rootfs-chroot is also a very worthwhile project, i've been using it accross various distros to run common programs.
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sat 10 Aug 2019, 14:36    Post subject:  

wiak wrote:
As far as I'm aware you won't be able to use runit in chroot version? or am I mistaken - as far as I remember runit must run as the very first process ID

Working fine for me, /usr/bin/init showing sym link to runit-init - that is with the initrd init chroot'ing to /sbin/init (that in the main system also sym links to runit-init). So it is running as PID 0 initially. If I break out of the chroot back to initrd then to restart it I chroot with /bin/sh

In my case with the folders set up under /CHR in the initrd ...

chroot /CHR/merged /sbin/init ... as the last line in initrd's init

chroot /CHR/merged /bin/sh .... if I've exited back into initrd and want to resume the main Void system.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sat 10 Aug 2019, 18:41    Post subject:  

4.19.65 kernel compiled with localyesconfig (i.e. firmware built into kernel), 13MB filesize

base void with squashfs-tools (so can run firstrib scripts within Void) + chromium and pulseaudio (and pavucontrol) compressed with xz high compression 375MB initrd filesize). With /lib modules and firmware removed (as they're already in the kernel).

Running chromium playing youtube video, and 410MB ram used.



Pretty much a pure Voidlinux, but where that's chrooted so booted from usb and all running in ram.

wiak's scripts (my adapted versions) all run fine under Voidlinux (originally used Fatdog). i.e. my current kernel and initrd were build within a running voidlinux boot.

Smile Smile Smile ... Thanks wiak.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Sat 10 Aug 2019, 19:03    Post subject:  

Just in case my last post was misunderstood, it is not that FirstRib WeeDog project is being abandoned or not developed further. Rather, I want to consolidate what is already created now, so working on docs and website (once current model04 revision satisfactory tested by me prior to its release in a day or two).

As you should realise there are three different useful build_firstrib_initramfs script models now:

Model 01: which used chroot inside humongous initramfs to access the embedded firstrib_rootfs, which all runs in RAM. The last that model was worked on was Revision 008pre (I think). I will update that with the new stuff in model 04 (for changes location selection: readonly, RAM, or some other partition/dir than bootpartition) - I will similarly update model 02. @rufwoof: good to hear that runit can also work inside chroot-model-01 arrangements (sv didn't work for me when I tried it and though the PID of runit was the issue, but I didn't investigate further since was busy on switch_root implementation. In this model 01 testing I was also exiting out of the chroot back to a cttyhack-type shell in the initramfs and then restarting the chroot when required).

Model 02: which uses an alternative method of mounting a hybrid firstrib_modules_firmware sfs (model 02 purposes prevents installation/mixing of modules/firmware from Void Linux so won't, for example, install template base-system).

Model 04 (which includes the slightly earlier model 03 code as well): This is the current switch_root model (identified with the s in Revision s005 name), which allows the firstrib_rootfs to not have to be loaded into RAM since it is kept out of the initramfs in this model. This model allows both a hybrid system to be build (e.g. using BionicPup kernel/modules/firmware) or Void Linux only. Unlike model 02 (or earlier model 03) it also allows runit to function (as Process ID 1) so full Void Linux compatibility. The only thing I've added to currently under test (at home) version is the ability to also run this model fully in RAM (EDIT: [not doing this part for now too complicated:] with possible option to only include selected components in the RAM running part).

Archives of these models will all become available at the firstrib github site (008pre will become c009 for model chroot Revision 009, once I include in it the extra changes options I recently added to Model 04 switch_root model).

I will also eventually get round to upgrading the model 01 (chroot) and model 02 (alternative hybrid) to include the flexible ability of model 04 to load NNsfs or NNuncompressed_dirs into any chosen layer (such that rollback is easy with NNupper_changes arrangements.

It is certainly good to also know some others are actively reading about or using the system in some shape or form. Thanks for your encouraging comments westwest! Since Void Linux itself is a 'rolling distro' (and FirstRib builds via xbps from upstream Void repositories), you will always get the benefit of their upstream developments anyway, so FirstRib WeeDog, in that sense, need never lose its usefulness. To be honest, one of the good things for me about FirstRib build system is that, being short and simple scripts it is pretty easy to maintain and modify, by anyone so inclined - and future-proofed via use of Void Linux's superb xbps package management.

rufwoof wrote:
wiak's scripts (my adapted versions) all run fine under Voidlinux (originally used Fatdog). i.e. my current kernel and initrd were build within a running voidlinux boot.


That's good to hear. I've been relying on such feedback since I haven't yet had much time at all to play with WeeDog FirstRib builds beyond the default commandline builds. Only checked X builds were working but really been wanting to have some time to build up a desktop version for myself (though realised from feedback, rockedge, fredx181 and your own, and my own quick builds, that all was now ready for full desktop configuration). Better documentation becomes important since, though system designed to allow easy-hacking, it is also designed with a view to allow anyone to simply one or two-click build complete system (with the help, perhaps, of firstrib00.plug, and/or simple wrapper scripts, or even later supply a small utility to create downloadable iso of pre-built frugal-installable system and another for pre-build pruning purposes).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130

Last edited by wiak on Sun 11 Aug 2019, 03:53; edited 1 time in total
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Sat 10 Aug 2019, 20:22    Post subject:  

wiak wrote:
rufwoof wrote:
wiak's scripts (my adapted versions) all run fine under Voidlinux (originally used Fatdog). i.e. my current kernel and initrd were build within a running voidlinux boot.

That's good to hear. I've been relying on such feedback since I haven't yet had much time at all to play with WeeDog FirstRib builds beyond the default commandline builds. Only checked X builds were working but really been wanting to have some time to build up a desktop version for myself (though realised from feedback, rockedge, fredx181 and your own, and my own quick builds, that all was now ready for full desktop configuration). Better documentation becomes important since, though system designed to allow easy-hacking, it is also designed with a view to allow anyone to simply one or two-click build complete system (with the help, perhaps, of firstrib00.plug, and/or simple wrapper scripts, or even later supply a small utility to create downloadable iso of pre-built frugal-installable system and another for pre-build pruning purposes).

The kernel localyesconfig to avoid modules/firmware in the main system was just a test on my behalf (to check that with xbps-install squashfs-tools make gcc it all built ok). More generally I'd just use the pre-built kernel (simpler/quicker binary download) for updating. Nice that your scripts all run through as-is under Voidlinux though, as that 10 minute job (that also pulls down the kernel) is the way I'd more generally 'update'. Larger (slower to boot from usb), but still quick enough and pretty much lost in my 4GB of available ram. Self sustaining (once the initial build version is up and running, can update (rebuild new vmlinuz/initrd), test that new vmlinuz/initrd and rollback if there are issues).

Perfection is the enemy of good. The scripts as-is are great. I suspect the tendency might be towards each individual merging/editing those to their own purposes. My intent for instance is to merge them into a single script, extended to do the tweaks/customisations as desired/needed (wifi ssid/password, .ssh keys, .Xdefaults/.Xresources/.xinitrc ...etc.).

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Mon 12 Aug 2019, 09:50    Post subject:  

wiak wrote:
As you should realise there are three different useful build_firstrib_initramfs script models now:

Model 01: which used chroot inside humongous initramfs to access the embedded firstrib_rootfs, which all runs in RAM. The last that model was worked on was Revision 008pre (I think). I will update that with the new stuff in model 04 (for changes location selection: readonly, RAM, or some other partition/dir than bootpartition) - I will similarly update model 02. @rufwoof: good to hear that runit can also work inside chroot-model-01 arrangements (sv didn't work for me when I tried it and though the PID of runit was the issue, but I didn't investigate further since was busy on switch_root implementation. In this model 01 testing I was also exiting out of the chroot back to a cttyhack-type shell in the initramfs and then restarting the chroot when required).

I've been letting that boot into void (chroot into 'merged' running Void kernel/installation) and then exit-chroot out of that to make or restore a tar of the upper-changes folder content (changes).

cd /
tar cf uc.tar /CHR/upper-changes
or
cd /
tar xf uc.tar

A form of save/restore. And chroot /CHR/merged /bin/bash .. back into void. I'm storing uc.tar on hdd which I mount within Void mkdir /mnt/hdd;mount /dev/sda1 /mnt/hdd ... and then access that within initrd once I've exit-chroot
cp /CHR/merged/mnt/hdd/uc.tar /.
Would be better however to just directly use the tar file

cd /
tar xf /CHR/merged/mnt/hdd/uc.tar

Note that /CHR is just my own choice of folder within initrd where lower/upper_changes/merged ...etc. are created/mounted/used.

My changes are generally little, so the tar file is small and quick to create/restore. Instead of hdd the saves could be stored elsewhere, on usb, even remote (retrieve/store using scp or whatever).

That's storing/restoring from/to a live running system. i.e. when I chroot back into void the changes immediately are visible. So far I've not encountered any problems from that, in some cases even having exit-chroot from within X with chrome running and after restoring and chroot back into Void the browser is still running OK on its prior content. If the browser isn't running then when started it usually prompts for 'restore session' to get back to where it was at the time of making the 'save'.

Desktop environment is pretty light installation wise, but highly functional. I like tilda (terminal) as I set that to F1 to show/hide and have it full screen when showing (i.e. I'm inclined to <F1> mtp <tab> <enter> ... to launch mtpaint than I am to use the touchpad to locate/click on mtpaint). mc as file manager and text editor (alongside busybox vi), alsa/pulseaudio/pavucontrol for sound, chromium browser (that I use to listen/watch multi-media, office docs (googledocs), pdf viewer ...etc.), xcalc for calculator (requires xbitmaps to be installed otherwise xcalc crashes and also crashes xorg!), jwm window manager, ccrypt for encrypting my ssh keys, mtpaint for image editing, and gcc/make/squashfs so I can run wiak's scripts and compile kernels if I so desire. void base also includes ssh so I can ssh into the server I use for email, irc, bbs's ...etc.

xbps-install -y linux4.19 base-system squashfs-tools xorg xinit xbitmaps alsa-utils pulseaudio pavucontrol jwm chromium tilda mc gcc make mtpaint ccrypt

Not bothering to compile my own kernel versions now, just using what Void provide (quicker/easier updates), and with the above the initrd weighs in at around 560MB (using xz high compression). Nice to be able to have the kernel and entire system fresh/new to the latest version in around a 20 minute script run time. I'm tending to kick that off in the background on a daily basis so it builds whilst doing other things. I'm also pulling down Steven Blacks host list as part of start up (as good as ad-block). Haven't bothered setting up auto suspend on closing the laptop lid, instead I run that manually by running echo -n mem >/sys/power/state ... inside a suspend.sh script. As that way I can have the system suspended (low power consumption) when the lid is up, or more typically not having it suspend when the lid is closed and I have something running such that I don't want that suspending just because the lid is closed.

The AMD/Radoen 4GB Acer Aspire ES 15 that I'm using does encounter slow HDD spin-up delays, that pretty much make it useless for the likes of Windows. However for booting from usb, running in ram with usb disconnected once booted and only using the HDD for storage its a great little system. I could even disconnect/remove the HDD and just store data/saves on my ssh server. I don't think that the extra battery charge/life doing that would add would be that much different however and having some laptop storage space can at times be handy, or even setting it up as swap.

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh

Last edited by rufwoof on Tue 13 Aug 2019, 04:54; edited 1 time in total
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1281
Location: Connecticut, United States

PostPosted: Mon 12 Aug 2019, 11:12    Post subject:  

I just built a WeeDog model 4.005 on a DELL PowerEdge R210 II blade server
4 core 4 thread 8 gigs of RAM

base-minimal base-devel xorg jwm rox xterm bash geany mc mtpaint adwaita-icon-theme python cmake git ffmpeg ffmpeg-devel hiawatha mariadb php-cgi

now starting to add more PHP modules and PERL modules plus libraries needed for an eventual build of ZoneMinder from source

have of course network connection on eth0 and eth1..no wlan no audio...this is a server....

I have a model 2 and model 4.004 that both run very nicely...and as noted before, cpu's run cool and the machine is fast and responsive.

I have pmcputemp from Puppy linux running on both a 32 bit and 64 bit machines but on the R210 it never changes the temp output image.
Back to top
View user's profile Send private message Visit poster's website 
rockedge


Joined: 11 Apr 2012
Posts: 1281
Location: Connecticut, United States

PostPosted: Mon 12 Aug 2019, 11:16    Post subject:  

once I have the initial build of weedog I chroot the root_fs and change the password for root, exit and umount......then build the initramfs which is really small and finishes quickly. Then boot and add all the components via xbps-install

then I rename /upper_changes to something like /50upper_changes.....reboot
and go from there, so if I break it while adding the neural network stuff and opencv - darknet-yolo I can roll back to the original setup
Back to top
View user's profile Send private message Visit poster's website 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Mon 12 Aug 2019, 15:37    Post subject:  

For a 1366x768 laptop, just over 27 lines of console font is nice IMO
Code:
xbps-install terminus-font

edit/add-to /etc/rc.conf
Code:
FONT="ter-i28b"

i.e. bold 28 size (768 / 28 = 27.4 lines)

_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Mon 12 Aug 2019, 19:02    Post subject:  

@rufwoof and rockedge:

You guys are doing great and many thanks for the information and details/ideas you are posting. They are certainly very helpful for me, but I'm sure also giving important ideas/techniques/inspirations to others who may try WeeDog builds of their own.

Unfortunately, I'm currently sick just now, a bit feverish with it so my coding of build initramfs04 Revision 006 has slowed down to stop for a day (or two). Should hopefully be recovered in a few days time and the only extra I'm working on in 006 is copy2ram option so usb sticks can be unplugged with these model 04 switch_root versions too (I have basically completed the coding - it's only about 12 extra lines of code - but needing to tidy it all up and check it out a bit yet).

Thereafter, I'm also wanting to experiment with (plugin/optional maybe) saving changes in tar files, which, as I mentioned, tinycore linux does in its own quite interesting way - and I have also been very impressed by how small and fast to save such compressed tar saves often tend to be once main system already built. I might actually study exactly how tinycore linux does it, because it allows selection of which parts of filesystem to bother saving (filetool.list) as well as having an additional exclude file (xfiletool.list). Using compressed tar like that does seem to generally result in smaller save-files/save-times than merging filesystems/dealing-with-whiteouts etc. Other mechanisms used in TinyCore Linux, however, are probably not so useful or relevant because that system uses symlinks to bolt everything together rather than layered filesystems.

http://tinycorelinux.net/concepts.html

Well, what I'm really wanting to do is play with the system for a while before adding anything at all further! I'm resisting doing that till I have Revision 006 out of thet way (or I'll lose focus on that). Generally speaking, the builds seem to work sufficiently well now (and/or are simple-enough-in-form/easy enough to understand/modify, as is, by users), so I plan not change much at all now (if it works... don't break it...).

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Tue 13 Aug 2019, 10:19    Post subject:  

Progress report:

The init for build_firstrib_initramfs04 Revision 0.0.6 has now been completed and passed all my tests thus far. Only major change in this new revision of the build script is support for copy2ram grub kernel line option, which causes WeeDog to copy all NNfilename.sfs files, all NNuncompressed_dirs to a RAM tmpfs prior to them being mounted from there (rdsh plugins also copied to RAM at same time). Following some related code changes in the initramfs/init, it is then possible to unmount and eject the boot device if one of the following additional conditions are met:

grub kernel line also has:

1. changes=RAM specified (upper_changes then stored only in RAM: non-persistent)

or

2. changes=readonly specified (also only using RAM and writes not allowed)

or

3. changes=<path to changes directory> specified, where changes_partition is different from initial bootpartition (since bootpartition then not being used it can be unmounted).

For all of the above possibilities, it is then left up to the user to do the umount /mnt/bootpartion if they so wish. However, for each of the above cases, WeeDog prints a message to tell the user they can unmount bootdevice if they so wish.

I still have to assemble the tested initramfs/init revision 006 into the buildscript, and double check all is well. Late now, so build_firstrib_initramfs04_s006.sh should be available for download sometime tomorrow, all going well.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Wed 14 Aug 2019, 07:35    Post subject: build_firstrib_initramfs04 Revision 1.0.0 uploaded  

build_firstrib_initramfs04 Revision 1.0.0 uploaded to thread first post: Bumped to Revision 1.0.0 since feature freeze planned for this one for the time being (aside from maintenance/bug-fixes).

http://www.murga-linux.com/puppy/viewtopic.php?t=116212

build_firstram_initramfs04_s100_README, which is also provided for download from thread first post.

****NEW (in Revision 1.0.0):

Code:
grub kernel-line copy2ram option, which causes all NNsfs, NNdirs, and rdshN.plug files to be copied to RAM tmpfs and mounts the NNsfs and/or NNdirs from there.

One result of that is that when either of the following grub kernel-line option combinations is used, the bootdevice (e.g. usb stick) can be umounted and ejected:

1. changes=RAM at same time as copy2ram
   (upper_changes then stored only in RAM: non-persistent)
2. changes=readonly at same time as copy2ram
   (also only using RAM and writes not allowed)
3. changes=<path to changes directory> specified, where
   changes_partition is different from initial bootpartition
   (since bootdevice then not being used it can be unmounted)


I mainly tested this in combination with two previous upper_changes sessions, which I renamed to 50upper_changes and 51upper_changes prior to rebooting with changes=RAM copy2ram on grub kernel line. Note that if you are booting from usb using these options, after booting you should be able to remove it but only after relevant umount command.

There remains lot to test. I've tested as best I can for now, but, yet again, more testing is required. Though most of the code remains the same as before, I did quite a lot of re-organization to facilitate putting in the copy2ram code; hopefully it will all work, but the alterations were significant so I can't be sure until better tested.

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rockedge


Joined: 11 Apr 2012
Posts: 1281
Location: Connecticut, United States

PostPosted: Wed 14 Aug 2019, 15:10    Post subject:  

I will give the latest a try out from a usb stick and from a HDD connected by usb SATA adaptor
Back to top
View user's profile Send private message Visit poster's website 
wiak

Joined: 11 Dec 2007
Posts: 1828
Location: not Bulgaria

PostPosted: Thu 15 Aug 2019, 03:13    Post subject:  

Whilst I take time out for testing and for improving the documentation including WeeDog website, in the first post of thread,

http://www.murga-linux.com/puppy/viewtopic.php?p=1028956

I've included

QUICK BUILD/TEST INSTRUCTIONS

in addition to a firstrib00.plug that installs the needed Void kernel components for those wishing to use Void Linux kernel/modules etc. It's contents are as follows:

Code:
xbps-install -y ncurses-base linux4.19 linux-firmware-network wifi-firmware shadow
pwconv # set up passwd system
grpconv
echo -e "root\nroot" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"

# you can add as many valid commandlines as you want in here


Note that the plugin also sets up default root passwd to simply "root", which you can change later of course.

I've tested above in usb stick install, ran it with grub options changes=RAM and copy2ram and was able to then umount my usb stick (on my system that was: umount /mnt/sdb1) and then unplug the usb stick.

You can later install bash, and say, base-minimal; e.g. after booted, or via mount_chrootXX.sh (or simply by adding to above firstrib00.plug prior to running ./build_firstrib_rootfsXXX.sh).

I'm looking forwards to someone producing a firstrib00.plug (or othername.plug) that contains packages and config code to build a nice polished X desktop... Wink

I would suggest to anyone who has been reading this thread not to be put off by the technical nature of some of the discussions here. The system is extremely simply to build and use (really just the matter of running the two small build scripts, per the quick instructions in the first post of this thread) and most anyone on this forum should find it very simple to do and you may well even find working with WeeDog/Void useful and help you better understand/quickly-learn Linux distro/system operation more generally. For full X-desktop-build help it becomes simply a matter of asking/checking info and questions on this thread once you have WeeDog booting successfully to the commandline.

I'm sure the current testers could confirm that Void Linux xbps use provides WeeDog with an extremely powerful package manager with excellent and continually up-to-date package repositories, and WeeDog FirstRib initramfs provides some flexible frugal install options including easy rollback and use of either sfs files or uncompressed directories (including copy2ram capability) in but a couple of short and simple easy to read and modify scripts.

EDIT: If you are late to the party and want to search this thread, then MochiMoppel's post regarding viewing thread as one html page might prove useful to you:

http://www.murga-linux.com/puppy/viewtopic.php?t=111347

wiak

_________________
Tiny Linux Blog: http://www.tinylinux.info/
Check Firmware: www.murga-linux.com/puppy/viewtopic.php?p=1022797
tinycore/slitaz: http://www.murga-linux.com/puppy/viewtopic.php?p=990130#990130
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3617

PostPosted: Thu 15 Aug 2019, 12:35    Post subject:  

Reported my test of the more recent scripts here http://murga-linux.com/puppy/viewtopic.php?p=1034419#1034419
_________________
( ͡° ͜ʖ ͡°) :wq
Fatdog multi-session usb

echo url|sed -e 's/^/(c/' -e 's/$/ hashbang.sh)/'|sh
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 18 of 48 [709 Posts]   Goto page: Previous 1, 2, 3, ..., 16, 17, 18, 19, 20, ..., 46, 47, 48 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0826s ][ Queries: 13 (0.0087s) ][ GZIP on ]