I used UUID and it works for me.
Code: Select all
title tahrpup
uuid ba259b38-29a0-40e7-84bc-032f1d46204b
kernel /tahr/vmlinuz psubdir=tahr pmedia=atahd pdrv=sda2:/tahr/ zdrv=sda2:/tahr/zdrv_tahr_6.0.6.sfs
initrd /tahr/initrd.gz
Code: Select all
title tahrpup
uuid ba259b38-29a0-40e7-84bc-032f1d46204b
kernel /tahr/vmlinuz psubdir=tahr pmedia=atahd pdrv=sda2:/tahr/ zdrv=sda2:/tahr/zdrv_tahr_6.0.6.sfs
initrd /tahr/initrd.gz
Code: Select all
title Puppy xenial 7.0.8.1 (sdc2/xenial)
uuid e9e64b47-ccd4-42c5-aeff-e771e264af3c
kernel /puppy/xenial/vmlinuz acpi_osi=Linux libata.noacpi=1 intel_pstate=disable pdrv=isoSave:/puppy/xenial/ pfix=nosave
initrd /puppy/xenial/initrd.gz
I haven't been watching closely but had an ideagyro wrote:I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/init and http://www.fishprogs.software/puppy/initrd/initrd.gz.
Changes in this 11 June version:
1. Improved error reporting, particularly in the early "sorting out boot parameters" phase.
2. Interpretation of "pdrv=sdb2:dir/filename.sfs" has changed from "sdb2:/dir/filename.sfs" to "sdb2:/psubdir/dir/filename"
3. Checks for the existence of the "overlay" module, and error exits if it's not found.
4. Writes a "POVERLAY='yes'" line to PUPSTATE, if overlay support is found.
5. Builds the stack in 2 phases, first an ro sfss stack, mounted on "/pup_sfss" and then the full rw stack at "/pup_new".
I've also uploaded a couple of scripts I use a lot when working with "initrd.gz":
http://www.fishprogs.software/puppy/initrd/file2initrd and http://www.fishprogs.software/puppy/initrd/initrd2file.
Just execute them without any parameters to see the "Usage" info.
gyro
No, I have still not found a way to modify an existing overlay stack, but testing of this is not yet complete.Moose On The Loose wrote:Has the loading of an SFS on the fly been made possible yet?
Or could try building a new "fixed" stack and pivot root to that.Moose On The Loose wrote:If not perhaps a "fast reboot" could be added that doesn't reboot but instead pivots off the overlayed file system makes changes and goes back onto the modified overlayed system. This would be a lot faster than a complete reboot.
Yes, if a modified stack can be done, it seems like a faster way to get to a changed system. It may take some trickery to make the changes up to that point stay but not override the new SFS.gyro wrote:No, I have still not found a way to modify an existing overlay stack, but testing of this is not yet complete.Moose On The Loose wrote:Has the loading of an SFS on the fly been made possible yet?Or could try building a new "fixed" stack and pivot root to that.Moose On The Loose wrote:If not perhaps a "fast reboot" could be added that doesn't reboot but instead pivots off the overlayed file system makes changes and goes back onto the modified overlayed system. This would be a lot faster than a complete reboot.
gyro
The url's of all the files I've uploaded for this project are now provided in the 1st post.Rangan Masti wrote:where to find the new initrd uploaded.for testing?
Code: Select all
pdrv=sdc2:/slacko/ ydrv=:ydrv_overlay.sfs pfix=nocopy
You're welcome, and thanks for testing.Rangan Masti wrote:Hi, good afternoon. Testing initrd with my compiled kernel 4.12.0-rc6 with
built-in overlayfs.Thank you for the link last sent. Have a good day.
There is no problem creating a new overlay stack that includes the current rw directory and a different set of ro directories. The problem is getting that new overlay stack to replace the current /, in a running system.Moose On The Loose wrote:Yes, if a modified stack can be done, it seems like a faster way to get to a changed system. It may take some trickery to make the changes up to that point stay but not override the new SFS.