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 Tue 28 Jan 2020, 03:02
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 34 of 49 [725 Posts]   Goto page: Previous 1, 2, 3, ..., 32, 33, 34, 35, 36, ..., 47, 48, 49 Next
Author Message
wiak

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

PostPosted: Thu 12 Sep 2019, 03:46    Post subject:  

AndresC2 wrote:
Hi Wiak Very Happy

Can you see lsmod-lspci-lsusb.log first

and later I apply the fix

thanks wiak


I doubt you need me for this analysis AndresC2 Wink

Note that I'm presuming this log is from your successful will haley boot and not from WeeDog at rdsh3 position, which would tell me nothing since I need the correct booting lsmod (not the lsmod you could take at rdsh3 in WeeDog since that loads all modules at that stage, not only the ones finally required once successful boot has been achieved).

Code:
# cat lsmod-lspci-lsusb.log |  grep uhci
uhci_hcd               40960  0
usbcore               188416  4 usb_storage,ehci_hcd,uhci_hcd,uas
   Kernel driver in use: uhci_hcd
   Kernel modules: uhci_hcd
   Kernel driver in use: uhci_hcd
   Kernel modules: uhci_hcd


As you can see, the missing module is uhci_hcd (same as uhci-hcd as far as modprobe is concerned) so simply boot as I suggested with file modules_remove.plug in /mnt/sdb1/WeeDog at the time of booting containing only the following line exactly:

Code:
modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci|uhci'` 2>/dev/null


By, the way, why your log also shows, ehci_hcd and uas is a bit surprising, since these would normally be for usb2 and above I think. Anyway, if your WeeDog boots successfully with above fix you could reboot with the slimmed down suggestion attemp (i.e. simply edit modules_remove.plug to contain following)t:

Code:
modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'sdhci|uhci'` 2>/dev/null


If neither of the above work then simply use a completely empty modules_remove.plug. If that doesn't work then I have no further ideas (though the fact you say WeeDog boots okay as far as rdsh3 means above should work or something else wrong I don't know about on your system; for example, why you installing busybox on WeeDog attempt but not on will haley attempt?? Busybox not needed and maybe its init is over-writing runit??? I don't know, but do it without installing busybox in your firstrib_rootfs - I didn't install busybox in that myself and all worked fine - i.e. in your firstrib_rootfs you should absolutely 'make sure' /sbin/init ends up being a symlink to something to do with runit and NOT to busybox init, so best not to install busybox for test just in case that overwrites runit setup...).

Anyway, good luck Andres. Seems clear to me it can be solved since once it manages to reach rdsh3 any problems left should be relatively minor.

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3717

PostPosted: Thu 12 Sep 2019, 07:38    Post subject:  

Any suggestions for the best way to setup/boot where the 01firstrib_rootfs.sfs is contained within initramfs05.gz? Which is more convenient for the likes of PXE and other boot choices (virtualbox ??). Haven't tried it yet, but imagine that would have to use bootfrom=/

My save and merge saves scripts would also have to be changed as they currently use the bootfrom parameter as the target of where to save/merge changes sfs files.

Current work in progress is I'm revising my firstrib00.plug so that is can be run as a script with a 'build' parameter, and when so it has wiaks build scripts contained within it, so it builds a vmlinuz, initramfs, 01firstrib_rootfs.sfs but where I'm looking to modify that so the 01firstrib_rootfs.sfs is moved into initramfs.gz. A nice and simple one script along with just needing to modify the first handful of lines in that script before running it i.e. for locale, root and user password setting, wireless ssid/password ...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 
AndresC2

Joined: 08 Jul 2017
Posts: 76

PostPosted: Thu 12 Sep 2019, 08:33    Post subject:  

Hi Wiak : )

Thank you so much !!!!!

WeeDog run fast my friend more than normal debian buster.

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci|uhci'` 2>/dev/null # work fine

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'sdhci|uhci'` 2>/dev/null # much better

posting from Dillo right now

jwm,xfe.mc,xorg,busybox run very fine so far.

later testing more with another desktop.

thank you for your patience wiak.
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Thu 12 Sep 2019, 09:10    Post subject:  

rufwoof wrote:
Any suggestions for the best way to setup/boot where the 01firstrib_rootfs.sfs is contained within initramfs05.gz?


Hi rufwoof,

The original build initramfs did in fact create what I called a huge initramfs because it contained the whole of firstrib_rootfs inside it; that was the version that used chroot rather than switch_root. Admittedly, that early version was pretty basic compared to the present day FirstRib/WeeDog scripts. I think last of the chroot scripts which used a 'huge' initramfs is this one:

https://github.com/firstrib/firstrib/blob/master/build_firstrib_initramfs01_ver008pre.sh

It wouldn't be particularly difficult to modify current WeeDog to produce a 'huge' initramfs version. I think in that old version I maybe did use / as lower dir (though I haven't checked and can't remember EDIT: since checked and yes that was the way I did it then). Maybe better would be to simply embed 01firstrib_rootfs inside the initramfs build followed by switch_root to it (well... I mean to the overlay merged result rather than the 01firstrib_rootfs.sfs lower layer) much as now really (aside from that sfs being embedded inside the initramfs). I've tried to keep the scripts simple so as to be relatively easy to modularise and put together in different ways (though it can be surprisingly difficult to avoid dreaded kernel panics when making even simple modifications to an initramfs/init...).

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797

Last edited by wiak on Thu 12 Sep 2019, 09:41; edited 2 times in total
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Thu 12 Sep 2019, 09:37    Post subject:  

AndresC2 wrote:
posting from Dillo right now

jwm,xfe.mc,xorg,busybox run very fine so far.

later testing more with another desktop.


That's good to hear, Andres, and I'm happy it is running fast for you. By the way, you could, I think, shorten it one more step to save tiny bit more RAM since sdhci is only needed if booting from sd card, which I gather you are not:

Code:
modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'uhci'` 2>/dev/null


Once you have created a firstrib00.plug that is simple but polished enough to be usefully used by others it would be great if you would post it on this thread for download (or in its own thread) and I'd make a link to it on the User Contributed plugins page:

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

It would be the first contributed firstrib00.plug for a debian-based WeeDog system.

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3717

PostPosted: Thu 12 Sep 2019, 12:14    Post subject:  

wiak wrote:
Maybe better would be to simply embed 01firstrib_rootfs inside the initramfs build followed by switch_root to it

That's exactly what my firstrib00.plug is now doing.

Download it (less than 6MB), gzip -d ... decompress it, chmod +x it if necessary; Edit the top section of the file to set your ssid and password and also the password to use for root and user userid's; Then run it with the 'build' parameter
Code:
./firstrib00.plug build

... and go off for a coffee break and return to have vmlinuz and initramfs all ready to go.

I'm using grub4dos menu.lst entry of
Code:
title VOID4
   root (hd0,0)
   kernel /VOID4/vmlinuz-5.2.14_1 bootfrom=/ changes=RAM inram_sz=100% copy2ram
   initrd /VOID4/initramfs05

On first boot, login as root (default password 'root' unless changed as indicated above). At the command line prompt run 'startx'. Once X is running I tend to maximise the tilda terminal window by mousing into that area and pressing F11, thereafter its F1 to toggle showing/hiding that terminal window. If you run demoapp.sh command then that makes terminal life easier (ncurses menu). As before mousing into the top or bottom left corners or using win+space or alt+space ... to show the window manager and program launcher.

If booted from usb, then adding usbwait=12 kernel boot parameter is recommended.

My firstrib plug is all encompassing, all of the scripts build files etc are all contained within itself. Other than needing quite a bit of tidying up that works very well.

Currently the save.sh (and merges.sh) wont work, because it can't store the 02changes.sfs alongside the 01firstrib_rootfs.sfs ... because that's inside the initramfs. Thinking of changing the build scripts so that in addition to bootfrom= another changes= parameter might be included from/to where changes are read/stored. However it would be better if the main (your) scripts were modified to include that rather than having different sets of build scripts. Basically if changes= parameter exists then that device/folder needs to be mounted/accessible and NNxxx.sfs's located there also being layered/loaded in addition to any NNxxx.sfs's in bootfrom= folder location. Or perhaps union joining changes= folder with bootfrom= folder ??

_________________
( ͡° ͜ʖ ͡°) :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: 3717

PostPosted: Thu 12 Sep 2019, 13:56    Post subject:  

Booting with humongous initramfs (main sfs inside initrd) from usb (2.0) and it seems I don't need any usbwait= kernel boot parameter when also copy2ram is being used ... as its all copied into ram anyway Smile
_________________
( ͡° ͜ʖ ͡°) :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 
rockedge


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

PostPosted: Thu 12 Sep 2019, 15:44    Post subject:  

I need the usbwait for some usb hdd's..they just need time to spool up to speed. Others that do not.

It would be cool if I could use a firstrib00.plug along with a firstrib01.plug and so on and so forth. To make the plug system with easy management and even more modular than it is.
Back to top
View user's profile Send private message Visit poster's website 
wiak

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

PostPosted: Thu 12 Sep 2019, 18:00    Post subject:  

rockedge wrote:
It would be cool if I could use a firstrib00.plug along with a firstrib01.plug and so on and so forth. To make the plug system with easy management and even more modular than it is.


rufwoof wrote:
Thinking of changing the build scripts so that in addition to bootfrom= another changes= parameter might be included from/to where changes are read/stored. However it would be better if the main (your) scripts were modified to include that rather than having different sets of build scripts. Basically if changes= parameter exists then that device/folder needs to be mounted/accessible and NNxxx.sfs's located there also being layered/loaded in addition to any NNxxx.sfs's in bootfrom= folder location. Or perhaps union joining changes= folder with bootfrom= folder ??


Okay, I'll look into incorporating both of these. Rufwoof, I tried downloading your plug but seemed to be something amiss at the download site. I'm going out now but will try again later.

EDIT: I need to see what you mean since there is already a changes=parameter, where parameter can be one of:

changes=RAM
changes=readonly
changes=path2dir, where path2dir specifies where upper_changes is to be stored

The above is documented part of current build_weedog_initramfs05 script; as I describe above it certainly worked in previous version but hasn't been tested that I haven't broken its functionality in current version.

EDIT2: I managed to download your plugin now rufwoof, but as I said, I'm just going out, but will look at its contents later. You should say 'busybox tail +25 firstrib00.plug' since normal tail has different options I think. Also I note you are using previous build_weedog_initramfs05_s102.sh (unless I have accidentally mixed up firstrib00.plug files and I am looking at one of your earlier ones). Could you kindly test with latest _s103u since it really needs these tests so I can rename it as stable. Your MAKE via uuencode and doit.sh is an interesting arrangement.

Okay, did quick read of your doit.sh, and see it does, as expected, copying in of 01firstrib_rootfs.sfs and cpio back up again with result the 'huge' initramfs05.gz and so on. I need to think further on your:

rufwoof wrote:
Basically if changes= parameter exists then that device/folder needs to be mounted/accessible and NNxxx.sfs's located there also being layered/loaded in addition to any NNxxx.sfs's in bootfrom= folder location.


Currently this part:

Code:
if changes= parameter exists then that device/folder needs to be mounted/accessible


is already in the existing/current build weedog initramfs script. At the moment, as you know, any existing NNfiles are being copied/layered from bootfrom location only; its really the key chunk of code in that build script so I have to be careful not to mess it up. To do what you would like (including NNfiles stored in changes partition) would indeed better being integrated directly into main script routines that does that layering - I will look into that sometime soonish to see how easy/hard/best-way to do it.

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3717

PostPosted: Thu 12 Sep 2019, 19:27    Post subject:  

Yes changes= ... bad choice of name. Ideally need bootfrom=/ i.e. main sfs is inside initramfs, changes=ram so changes are lost at shutdown, additionals= ... (or whatever choice of parameter name) where additional sfs's are stored and layered when booting i.e. perhaps additional periodic mksquashfs copies of upper_changes so that the changes are persistent across reboots. More usually with the main sfs outside of initramfs 01firstrib_roots.sfs is loaded, then 02somefile.sfs, 03anotherfile.sfs ...etc. sitting alongside 01firstrib_root.sfs also get layered/loaded. But when bootfrom=/ i.e. 01firstrib_rootfs.sfs is inside initramfs then the 02somefile.sfs 03anotherfile.sfs .... need to stored/loaded from another location outside of initramfs

My firstrib00.plug is working with a older version of the build_weedog... script, but using a snippet from that as a example the current code snippet is ...
Code:
cd "\${mountfrom}"  # Since NNsfs_files and NNdirs are there (i.e. bootfrom dir or /mnt/layers/RAM)
lower="";
for addlayer in *; do
        NN="\${addlayer:0:2}" # gets first two characters and below checks they are numeric (-gt
00)
        if [ "\$NN" -gt 0 ] 2>/dev/null; then
                if [ "\${addlayer##*.}" == "sfs" ]; then
                        # layer to mount is an sfs file
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount "\${addlayer}" "/mnt/layers/\$NN"
                elif [ -d "\$addlayer" ]; then
                        # layer to mount is an uncompressed directory
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount --bind "\${addlayer}" "/mnt/layers/\$NN"
                fi
        fi
done

If the main sfs is inside initramfs (so bootfrom=/) and I have a bunch of other sfs's I want layered, then there's nowhere for them to be stored/loaded from as-is ... unless I cpio open up the initramfs and drop them into there alongside the main 01firstrib_rootfs.sfs, which becomes nonviable other than for relatively small/limited filesizes (otherwise initramfs grows to be too large to actually get loaded by BIOS).

Needs a
Code:
lower="";
for loadfrom in $mountfrom $additionals
  for addlayer in *; do
        NN="\${addlayer:0:2}" # gets first two characters and below checks they are numeric (-gt
00)
        if [ "\$NN" -gt 0 ] 2>/dev/null; then
                if [ "\${addlayer##*.}" == "sfs" ]; then
                        # layer to mount is an sfs file
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount "\${loadfrom}/\${addlayer}" "/mnt/layers/\$NN"
                elif [ -d "\$addlayer" ]; then
                        # layer to mount is an uncompressed directory
                        lower="\${NN} \${lower}"
                        mkdir -p "/mnt/layers/\$NN"
                        mount --bind "\${loadfrom}/\${addlayer}" "/mnt/layers/\$NN"
                fi
        fi
  done
done

type additional loop (untested), so that kernel parameters of bootfrom=/ additional=/mnt/sda1/savesfss changes=RAM ... will have 02changes.sfs, 03changes.sfs stored in /mnt/sda1/savesfss layered on top of the content of 01firstrib_rootfs that is stored inside initramfs. $additionals (such as /mnt/sda1/savesfss) would of course also have to be mounted/accessible.

_________________
( ͡° ͜ʖ ͡°) :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: 1862
Location: not Bulgaria

PostPosted: Thu 12 Sep 2019, 20:12    Post subject:  

rufwoof wrote:
Yes changes= ... bad choice of name. Ideally need bootfrom=/ i.e. main sfs is inside initramfs, changes=ram so changes are lost at shutdown, additionals= ... (or whatever choice of parameter name) where additional sfs's are stored and layered when booting i.e. perhaps additional periodic mksquashfs copies of upper_changes so that the changes are persistent across reboots. More usually with the main sfs outside of initramfs 01firstrib_roots.sfs is loaded, then 02somefile.sfs, 03anotherfile.sfs ...etc. sitting alongside 01firstrib_root.sfs also get layered/loaded. But when bootfrom=/ i.e. 01firstrib_rootfs.sfs is inside initramfs then the 02somefile.sfs 03anotherfile.sfs .... need to stored/loaded from another location outside of initramf.


Well, changes=parameter does describe its designed purpose, which is to indicate simply where upper_changes would be stored, be it RAM or wherever. And bootfom= does describe where vmlinuz and initramfs location is. The issue is that NNfiles are not themselves changes files (even if they are rollbacks renamed from earlier upper_changes files). Actual changes file always gets loaded in upper rw layer. So, with these rollback files being loaded, as in your scheme, from a different location, provision needs added probably for that, which would not be addressed by changes= but probably I'll create new additional parameter for that need EDIT: since the needs are mutually exclusive: one, changes= to specify where rw layer upper_changes is to be located, and the other ...= to specify alternative/additional location for NNfiles to be loaded into appropriate NN layers. I hope my thoughts there match the facility you need for your merge/save/load utilities.

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797

Last edited by wiak on Fri 13 Sep 2019, 00:36; edited 3 times in total
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Thu 12 Sep 2019, 20:30    Post subject:  

I'll also look into a more flexible firstrib00.plug mechanism, rockedge, since it's true that current simple inclusion into chroot's /tmp isn't convenient/flexible when it comes to chaining such plugins.

The more a script can handle general purpose use the more flexible it becomes but making any algorithm more general-purpose is often the hard part... Same in general research, specific case algorithms/theories are relatively easy to implement but absolute all-cases formulas much trickier to devise, and in computing practice some happy-medium compromise is often the best we can get without huge bloat. Still, there remains scope to get nearer to the ideal that would cater for most users' specific ideas whilst allowing for alternative schemes.

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
wiak

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

PostPosted: Fri 13 Sep 2019, 01:28    Post subject:  

rufwoof wrote:
But when bootfrom=/ i.e. 01firstrib_rootfs.sfs is inside initramfs


To help keep the code simple, I'll provide that part of the functionality in subtle alternative way that does not effect existing reserved parameters. I'll used the same method currently already used by the initramfs/init script to determine if a 00firstrib_firmware_modules.sfs is to be loaded (being simply its existence or non-existence). Otherwise I'd really need yet another parameter since bootfrom is essential in telling initramfs/init where the vmlinuz and initramfsXX.gz is.

The method I am implementing is simple - if no 01filesystem is found in bootdir, (where it would generally be required), or in new alternative location for NN{sfs,dir} files, then initramfs/init will load a 01firstrib_rootfs.sfs from the 'boot' directory inside the initramfs itself (if it exists). I'm choosing to use boot subdirectory rather than / to account for possibility of chroot version of WeeDog initramfs also being developed further, in which case it wouldn't be 'tidy' to have 01firstrib_rootfs.sfs sitting in main / location, but boot subdir is fine since that's appropriate to when it is used.

EDIT1: For the sake of separation will actually use /boot/NNstore. Also, whilst I think 01firstrib_rootfs.sfs enough in initramfs, I plan to make it a user decision how many NNsfs in there and also to again allow any NN value for firstrib_rootfs there too. That way users have full control over which layers to put read-only items in.

EDIT2: Rather than use "if it exists" logic (as explained before) I instead hope to allow external copies of NNsfs files to override initramfs contained versions. I have been working on that implementation this evening and so far it is looking good in terms of not much extra code required whilst offering fullest flexibility in terms of usage. The next paragraph is thus now a bit behind actual progress, though if my current plan becomes too complex to finalise I may compromise on scope of that flexibility whilst still allowing for the various specific needs already discussed.

The reason I say "if it exists" is, if you remember, the system is already more flexible generally than to 'require' the firstrib_rootfs to always be at layer 01: you can in fact use any layer for NNfirstrib_rootfs, which allows for possibility you might want some sfs below it and some above it. Layer 01 is of course the lowest layer, and the layer 'normally' used for firstrib_rootfs in practice. So, if no 01firstrib_rootfs (sfs or dir) found in bootdir or in initramfs then that's fine; but of course it would then have to be provided but with some other NN value for placement in that other NN layer position. I don't think it would be good to include more than 01firstrib_rootfs in the initramfs for the reason you touched upon concerning the end-size/loading-time and more of the resultant 'huge' initramfs, but I will consider that matter further to see how general-purpose I can make the modified load-layer algorithm without bloat.

Anyway, working on all that and more - such alterations will take some time and mega further testing of course. I'll report progress now and again as I get on with that (sooner or later). Such algorithms can end up appearing nice and simple-looking (and surprising flexible) 'in the end', but that end simplicity hides the amount of consideration (and oft-flawed attempts) that go into finding something reasonably satisfying (with alas many a kernel panic inbetween...).

One thing I'm not prepared to do is to destroy the simplicity in FirstRib/WeeDog build system. It woud be relatively easy to add functionality via hacking-in extra-logic/functions/external-files and so on, without caring about the resultant extra bloat. However, it is not so easy to increase functionality whilst endeavouring to keep the code simple to read and follow whilst endeavouring to improve its overall efficiency and flexible functionality, so that end-apparent-simplicity actually needs a lot more careful consideration and takes longer thus to code. But that's what I will try to do. I've still to further consider firstrib00.plug implementation, but will come up with something to allow easier chaining of that too.

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
rufwoof


Joined: 24 Feb 2014
Posts: 3717

PostPosted: Fri 13 Sep 2019, 07:34    Post subject:  

Nice idea wiak!

I've been building with the 3u build script and that all seems to be working for me, with the exception that if I do put 01firstrib_rootfs.sfs inside the initramfs and use bootfrom=/ ... then it crashes on bootup. Other than that and its building my firstrib00.plug fine

_________________
( ͡° ͜ʖ ͡°) :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: 1862
Location: not Bulgaria

PostPosted: Fri 13 Sep 2019, 08:33    Post subject:  

rockedge wrote:
It would be cool if I could use a firstrib00.plug along with a firstrib01.plug and so on and so forth. To make the plug system with easy management and even more modular than it is.


wiak wrote:
I'll also look into a more flexible firstrib00.plug mechanism, rockedge, since it's true that current simple inclusion into chroot's /tmp isn't convenient/flexible when it comes to chaining such plugins.


Actually I hadn't looked at how to chain firstrib plugins before so took a quick look tonight and no longer agree with my own statement above: it is actually relatively easy to do as things stand. One problem is the surprising one of how to determine partition the current directory is in. You might think pwd command would do the job but you can't rely on that. For example, if in /mnt/home in a DebianDog, pwd command just says /mnt/home, which does not therefore reveal current dir (/mnt/home on DD is a symlink to actual /mnt/partition where booted from).

There is also a problem that opening terminal at partition booted from on Dogs results in something like /mnt/live/mnt/sda5 rather than simply /mnt/sda5 (assuming booting from sda5). This complicates matters further.

I think I have solution to above. I'll come back to this tomorrow since late now. Once I have that simple matter determined from script point of view, chaining firstrib plugins is easy to do.

wiak

_________________
New Puppy/Dog forum: https://puppylinux.rockedge.org
Tiny Linux Blog: https://www.tinylinux.info/
Check Firmware: http://murga-linux.com/puppy/viewtopic.php?p=1022797
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 34 of 49 [725 Posts]   Goto page: Previous 1, 2, 3, ..., 32, 33, 34, 35, 36, ..., 47, 48, 49 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.1112s ][ Queries: 12 (0.0273s) ][ GZIP on ]