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 Wed 13 Nov 2019, 14:42
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 47 of 48 [709 Posts]   Goto page: Previous 1, 2, 3, ..., 45, 46, 47, 48 Next
Author Message
wiak

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

PostPosted: Sat 12 Oct 2019, 06:50    Post subject:  

Came across an interesting vkpurge-related link:

vkpurge is a shell script. Below is a modified version.

https://sysdfree.wordpress.com/2019/05/11/263/

NOTE that I haven't tested any of this (hardly looked at it yet); just saving it for later perusal. Also, I'm not suggesting this modified version is useful - just keeping it for interest at this stage.

EDIT: remove copy of modified script since not sure it is useful. Better to simply check script /usr/bin/vkpurge which contains the line:

Code:
installed=$(xbps-query -o "/boot/vmlinu[xz]-*
" 2>/dev/null | awk '{print $2}')


That line is used to determine kernels that were explicity installed (via xbps-install) that vkpurge script then ignores during list or rm command.

I'll use this info to modify my kernel update script later.
EDIT2: Actually vkpurge probably best as it is. We don't want to remove explicity installed kernel (since that could include the current one) - I'm still thinking/experimenting with this.

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: Sat 12 Oct 2019, 10:06    Post subject:  

Success!

I was able to upgrade the WeeDog kernel via xbps-install -Suy and rebuild the vmlinuz-XX.XX, 01firstrib_rootfs.sfs and initramfs05.gz that booted cleanly and runs with a /70upper_changes, / 60upper_changes and /upper_changes. Unknown is the effects of updating with the changes occurring in the /upper_changes that occurred before mounting the uncompressed firstrib_rootfs
using the mount_chrootver007.sh script and running the command xbps-install -Suy. So far no conflicts have jumped out that I notice.

the firstrib_rootfs directory / filesystem must be present.
I used another WeeDog-s205 as the Host system for the upgrade process. Also tested using Puppy Linux Bionic 32 & 64 as the host.


The process was surprisingly easy!
(the paths may differ in your case)
Code:

cd /mnt/sdb1/firstrib05-s103u-E
mv 01firstrib_rootfs.sfs 01firstrib_rootfs.sfs.bak
mv initramfs05.gz  initramfs05.gz.bak
./mount_chrootver007.sh


in the terminal inside the chroot'ed firstrib._rootfs :

Code:
xbps-install -Suy
vkpurge list
vkpurge rm all
exit


Exit from firstrib_rootfs
and run:
Code:
./umount_chrootver007.sh


now in the terminal run

Code:
./build_weedog_initramfs05_s205.sh void


Open the Grub4Dos menu.lst and I use the entire vmlinuz name so the change went from vmlinuz-5.2.14_1 to vmlinuz-5.2.21_1
This could be simplified bly changing the name to vmlinuz after each upgrade. Also the usbwait= can be left off which is auto-detected in the lastest version of build_weedog_initramfs05

Code:
title firstrib05-s103u-E (Void Linux)
  uuid 1ef03b67-ebf1-447a-808c-eaa32169e89a
  kernel /firstrib05-s103u-E/vmlinuz-5.2.21_1  net.ifnames=0 usbwait=6 bootfrom=/mnt/sdb1/firstrib05-s103u-E
  initrd /firstrib05-s103u-E/initramfs05.gz


after a successful reboot remove the .bak files

Code:
rm /mnt/sdb1/firstrib05-s103u-E/initramfs05.gz.bak
rm /mnt/sdb1/firstrib05-s103u-E/01firstrib_rootfs.sfs.bak


In my case I then remove :
Code:
rm  /mnt/sdb1/firstrib05-s103u-E/vmlinuz-5.2.14_1


this process updated WeeDog's initramfs05.gz and vmlinuz


_
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: Sat 12 Oct 2019, 18:54    Post subject:  

rockedge wrote:
Also tested using Puppy Linux Bionic 32 & 64 as the host.
...
Code:

cd /mnt/sdb1/firstrib05-s103u-E
mv 01firstrib_rootfs.sfs 01firstrib_rootfs.sfs.bak
mv initramfs05.gz  initramfs05.gz.bak
./mount_chrootver007.sh


in the terminal inside the chroot'ed firstrib._rootfs :

Code:
xbps-install -Suy
vkpurge list
vkpurge rm all
exit



Thanks rockedge. I think using a second WeeDog (that has the same running kernel) is a great idea. However, I'm surprised vkpurge lines worked correctly when different running kernel (e.g. when you used Bionic). I'll have to give it a try.

I'm out today and tomorrow but will get back to taking a further look at this (and vkpurge script) again thereafter.

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: Sat 12 Oct 2019, 19:14    Post subject:  

In theory I think if one boots a WeeDog into RAM, the update via mounting the firstrib_rootfs then umount and running the build_initramfs script it might work to update the running system without crashing the system.

for best results so far I did the update process from a host system, after I booted into the WeeDog and ran xbps-install -Suy in there, I rebooted into a host system and ran the mount script and did the xbps-install -Su and ran the vkpurge commands and exited with umount script, after that ran build_initramfs script in the host OS

One case I needed to delete the /upper_changes to get firefox to work again but all the other tests did not break firefox.
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: Sun 13 Oct 2019, 01:24    Post subject:  

rockedge wrote:
In theory I think if one boots a WeeDog into RAM, the update via mounting the firstrib_rootfs


Yes, for many reasons doing the update of kernel/modules via a WeeDog booted into RAM would be good. Will need to reboot to get new kernel running, but WeeDog boots fast so not much downtime there. I'm also still looking into this update kernel via simple script possibilty - I'm particularly looking at the vkpurge code since a modified version of that could also be used to remove old kernel/modules that were explicity installed (rather than just being the result of upgrades, which standard vkpurge takes care of).

To illustrate the more general issue (that isn't an issue if generally only upgrading kernels. I have a firstrib_rootfs that has four kernel/modules installed. Two of these were installed manually and the other two are upgrades to these (as far as I remember...). When I run vkpurge list command only the original two get seen as ready for removal. However, both of the upgrades then remain... That, I believe (but still have to check), is because the following vkpurge code marks them as upgrades of what were explicity installed kernels and thus 'vkpurge rm all' is coded to not delete any explicitly installed (rather than upgraded) kernels:

From inside chroot of ./mount_chrootver007.sh:

Code:
xbps-query -o "/boot/vmlinu[xz]-*" 2>/dev/null | awk '{print $2}'

reports:
Code:
/boot/vmlinuz-4.19.79_1
/boot/vmlinuz-5.2.21_1


whereas:

Code:
vkpurge list

reports:
Code:
4.19.69_1
5.2.20_1


What I want to arrange to happen for this more general case is that all of the above except for vmlinuz-5.2.21_1 get removed (which is not the case with current vkpurge rm all; so I'm planning to make a 'modified/special' weedog_vkpurge script to only leave most recent kernel/modules.

EDIT: Changed my mind. Better, is to allow more than one kernel to be installed in firstrib_rootfs and get build_weedog_initramfs to either (most simply) just use the latest of these, or give build script user choice.

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: Sun 13 Oct 2019, 07:20    Post subject: build_weedog_initramfs05_s207.sh uploaded
Subject description: allows firstrib_rootfs to contain multiple kernel/modules
 

build_weedog_initramfs05_s207.sh uploaded to usual downloads location:

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

Changes:

Per official Void, firstrib_rootfs is now allowed to contain multiple versions of kernels/modules. The build_weedog_initramfs script will now give you a pause (via shell 'read' command) to allow you to (optionally) manually remove some kernels if you wish (via, for example, mount_chrootXXX.sh and then vkpurge or xbps-remove, and umount_chrootXXX.sh), and once you continue the script presents you with a number list menu of kernels that remain in firstrib_rootfs/boot. You then enter the number of the kernel you want to use or if you just press Enter at that stage the most recent kernel (according to alphanumeric order) in the list will be used during the initramfs build.

Also fixed the usbwait loop so correctly now has timeout of 30 seconds.

Has only had a little testing, so I am not as yet removing version s205. Using odd numbers (s207 in this case) to simply indicate not tested much as yet...

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 Mon 14 Oct 2019, 05:11; edited 3 times in total
Back to top
View user's profile Send private message 
rockedge


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

PostPosted: Sun 13 Oct 2019, 19:19    Post subject:  

Quote:
or give build script user choice


maybe add another parameter to the command line that will specify the available kernel to use and if not used, defaults to the latest version.

I had a system built that was using kernel 5.2.14 that I upgraded to kernel 5.2.21 by doing a system update then mounting the firstrib_rootfs and running the system update in there to hopefully insure all the dependencies and lib's are the same versions so /upper_changes is not layering in older versions and causing system breakage when initramfs05.gz and vmlinuz the 01firstrib_rootfs.sfsare rebuilt after the update.

Does it make sense to be able to merge /xxupper_changes into the firstrib_rootfs file system before squashing it or before running the build script?
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: Sun 13 Oct 2019, 22:48    Post subject:  

rockedge wrote:
Quote:
or give build script user choice
maybe add another parameter to the command line that will specify the available kernel to use and if not used, defaults to the latest version


EDIT: See my post below.

rockedge wrote:
Does it make sense to be able to merge /xxupper_changes into the firstrib_rootfs file system before squashing it or before running the build script?


Anything to do with merging is, I feel, best left as a separate utility (a user may anyway not always want to merge...). There are different ways of merging and different likely user needs and overall flexibility therefore, such merging should IMO be a separate extra-script/process. The core build scripts cover core needs, but no more than that. If however any separate utility needed something already provided for in the core scripts of course should look into adding that. I doubt that's the case here though - I think merging can be arranged by a separate utility (perhaps sometimes one that can be executed from inside a running WeeDog). I'm still looking into a more definite separate weedog_vkpurge utility for cleaning out kernels, but again that will be an optional utility. But by all means if you have some specific code lines that add to overall WeeDog core flexibility/functionality which couldn't be conveniently simply used in separate utility we should consider that.

One definite good thing is that WeeDog, one way or another, is pretty much future-proof so could well be still around 10 or 15 or more years from now (Puppy itself been around for 15 years now, though been alot of dev work needed over time to keep that presence). It remains relatively easy to modify WeeDog (and I hope to keep it that way) and as long as upstream Void, Debian, Ubuntu, or Devuan (and later Arch) are still alive, so is WeeDog... and since build initramfs doesn't really care what the upstream distro is, could also be used with others.

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 Mon 14 Oct 2019, 05:10; edited 5 times in total
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Mon 14 Oct 2019, 04:55    Post subject:  

So, though I didn't add a new commandline parameter, if your firstrib_rootfs does contain more than one kernel (as in firstrib_rootfs/boot/vmlinuz*) then build_weedog_initramfs05_s207.sh will give you a pause (via read command) to allow you to (optionally) remove some if you wish (via, for example, mount_chrootXXX.sh and then vkpurge or xbps-remove, and umount_chrootXXX.sh), and then present you with a number list menu of kernels that remain in firstrib_rootfs/boot. You then enter the number of the kernel you want to use or if you just press Enter at that stage the most recent kernel (according to alphanumeric order) in the list will be used during the initramfs build.

So what I wrote earlier about possibility of adding N in front of vmlinuz name is no longer required. I'll amend my posts above accordingly.

Note that, the script is designed to work with busybox sh (not just bash) so bash select command couldn't be used for the simple menu - instead I'm using cat -n to number the list and sed to determine the selection. The menu is thus basic and simple but seems to work, but all needs better testing than I've had time to give 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 
rockedge


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

PostPosted: Tue 15 Oct 2019, 16:27    Post subject:  

the tests worked well. Built both a 32 and 64 bit versions using my firstrib-00-XX.plug file

I booted into the new WeeDog and thought why not cd into the firstrib_rootfs directory, open a terminal and run the mount_chrootver007.sh script. So using a chroot'ed file system of itself
in which I ran xbps-install -Su in both host and the jailed firstrib_rootfs simultaneously

this is working really well and possibly has some uses in this configuration. Since it is a host system running a container of itself

I am now testing building zoneminder with the script in the chroot mounted firstrib_rootfs and then rebuild initramfs05.gz The end result will be a ready to run simple desktop with a LHMP and zoneminder installed....I hope. Then maybe create a bootable ISO of it.

Although just WeeDog running a jailed version of itself but different is pretty fun to play with


__
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: Wed 16 Oct 2019, 09:53    Post subject:  

Another success.

created a WeeDog using the latest scripts. Booted into that WeeDog and ran the mount firstrib_rootfs script and copied build_ZM.sh into /root and ran it. After successful completion and start in the chroot'ed firstrib_rootfs running in the WeeDog that came from it.

Performed the steps as indicated in the upgrade kernel method to rebuild the initramfs05.gz which worked as well. System booted and ZM runs.

Although the version where I run ZM in the chroot'ed file system in the WeeDog seems to be really a smooth running interesting option. There is the possibility of packaging an ISO at this stage of a finished system.
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: Sat 19 Oct 2019, 14:31    Post subject:  

I found out I can run the umount script for the firstrib_rootfs filesystem with zoneminder and LHMP instances still running and they continue to run normally as if built into the host system file structure.
Although the command line controls can't be used unless the mount script is run again in a terminal, the web console start/stop switch works fine.
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: Sat 19 Oct 2019, 17:54    Post subject:  

rockedge wrote:
I found out I can run the umount script for the firstrib_rootfs filesystem with zoneminder and LHMP instances still running and they continue to run normally as if built into the host system file structure.
Although the command line controls can't be used unless the mount script is run again in a terminal, the web console start/stop switch works fine.


I don't quite follow what you mean rockedge, but sounds interesting!

I still haven't got round to implementing Arch addition to firstrib rootfs build possibility, but not important really since most of us are using Void flavour weedog. I am slowly getting round to looking at merging upper_changes options (still to examine rufwoof's variants of doing that).

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: Mon 21 Oct 2019, 19:42    Post subject:  

what did was setup WeeDog with the latest versions of the build scripts and my firstrib00-32.plug. All done in a frugal install on a HDD connected via USB adapter.

so the directory contains the firstrib_rootfs with mount and umount script included. So all together with the vmlinuz, initramfs05.gz and upper_changes.

I boot that system and then open a terminal and use the mount script to chroot the firstrib_rootfs. I ran the build_ZM.sh script in that terminal sp zoneminder is built in the firstrib_rootfs.

that worked and with some tweaking got the whole ZM and web server started.
once ZM was running I ran the umount script in the chroot firstrib_rootfs terminal and closed the terminal.

now zoneminder is only installed in the firstrib_fs and does not appear in the /upper_changes or the 01firstrib_rootfs.sfs

I can now run Firefox and open up the ZoneMinder web console with http://localhost/zm and ZM works fully. To turn off the ZM and web server
I will have to cd to /mnt/sdb1/weedog and open a terminal and again run the mount script to be able to use command line to stop,start or restart the servers.
Or I can use the web console in Firefox to start stop restart the ZM server only. Hiawatha and mysql database can only be controlled from the terminal command line.

this is very interesting as I can configure ZM to store the recorded data in completely different locations. So it looks like I am booting the 01firstrib_rootfs.sfs and later using firstrib_rootfs chroot'ed in the system started from the .01firstrib_rootfs.sfs


I also found out that stemsee's dir2sfs version works very well in this WeeDog32.


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


**
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: Wed 23 Oct 2019, 19:49    Post subject:  

Hi rockedge,

Interesting to hear you running firstrib inside weedog. Good what you describe is all working. I haven't managed to get round to the various things I'm eventually planning to. In fact, I'll have to come back to weedog matters later (but I will). Presently, I'm setting up web-services for my partner's (spouse) business, so its all DNS records and the like at the moment. Then, having developed a fork of static website generator some longish time ago, I'm looking at different static site generators to see how flexible they perform - Jekyl and suchlike. What I adopt partly depends on the software license and ongoing development history and whether I decide instead to use dynamic site with php, which I've done in the past. I don't want to use site-builders like Wix though - too slow and complex messy code - I like simplicity and the flexibility that comes from the malleability of that. Having said that, Jekyl (can't remember the spelling,) might turn out more complex than I like too so will depend on the benefits. Of course, web dev work is useful later for improving firstrib & weedog public face.

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 
Display posts from previous:   Sort by:   
Page 47 of 48 [709 Posts]   Goto page: Previous 1, 2, 3, ..., 45, 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.0940s ][ Queries: 12 (0.0255s) ][ GZIP on ]