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 Sat 21 Oct 2017, 01:15
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Another re-write of the "init" script - using OverlayFs?
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 7 [93 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Author Message
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Tue 13 Jun 2017, 03:31    Post subject: Re: Announcing a new version  

Moose On The Loose wrote:
Has the loading of an SFS on the fly been made possible yet?
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:
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.
Or could try building a new "fixed" stack and pivot root to that.

gyro
Back to top
View user's profile Send private message 
Rangan Masti

Joined: 01 Jan 2013
Posts: 32
Location: Germany, Berlin

PostPosted: Tue 13 Jun 2017, 05:16    Post subject:    

Wish you success guys.
Back to top
View user's profile Send private message 
Moose On The Loose


Joined: 24 Feb 2011
Posts: 773

PostPosted: Tue 13 Jun 2017, 10:03    Post subject: Re: Announcing a new version  

gyro wrote:
Moose On The Loose wrote:
Has the loading of an SFS on the fly been made possible yet?
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:
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.
Or could try building a new "fixed" stack and pivot root to that.

gyro


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.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Wed 14 Jun 2017, 16:11    Post subject:  

When I tried to change the list of ro directories in an overlay with a "remount", there were no error messages, but the overlay remained unchanged. So this seems to be a dead-end.

But I was able to create a new overlay using some directories from the old overlay (including the rw dir, "upperdir" and "workdir") + a new ro directory. Then unmounting the old overlay and moving the new overlay to the original mount point. This worked.
Although this was just using play directories, not the actual / overlay.
So there is still some hope of being able to create a new overlay at /pup_new and doing some sort of pivot root to /pup_new, (again).

Unfortunately, it is probably safer to start by returning to the ancient puppy method of building the whole stack in "init" and not modifying it at all.

I've uploaded a new version of the "init" and "initrd.gz".
This one creates an ro overlay containing just the sfs's at /pup_sfss, and after sorting out what directory to use as an rw directory, creates the full overlay on /pup_new, using /pup_sfss as the "lowerdir".
This restores the logic of dealing with the sfs's first, then sorting out the save layer.
This also means that in the running system /initrd/pup_sfss contains the files of all the sfs's.

This version is also the first one that writes a PUPSTATE where the variables that are written are fully compatible with current puppies.

gyro
Back to top
View user's profile Send private message 
Rangan Masti

Joined: 01 Jan 2013
Posts: 32
Location: Germany, Berlin

PostPosted: Thu 15 Jun 2017, 05:47    Post subject:  

Hi Good morning, where to find the new initrd uploaded.for testing?
Thank you and have a great day!
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Fri 16 Jun 2017, 21:56    Post subject:  

Rangan Masti wrote:
where to find the new initrd uploaded.for testing?
The url's of all the files I've uploaded for this project are now provided in the 1st post.
But here's the one for the "initrd.gz" any way, http://www.fishprogs.software/puppy/initrd/initrd.gz.
Note: If the kernel in your puppy does not support "overlayfs", "init" will fail.

gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Thu 22 Jun 2017, 17:08    Post subject:  

I've had no success with trying to modify an overlay that is mounted as /, so I'm moving on to try some save layer techniques.

I've uploaded http://www.fishprogs.software/puppy/initrd/ydrv_overlay.sfs, to help with testing. It currently only includes "shutdowconfig" but in the next version it will also include "rc.shutdown".
And I've added some information on how to use the files, to the first post.

This version can boot automatically to pupmode=12 using a savefolder.
Just boot with boot parameters similar to the following:
Code:
pdrv=sdc2:/slacko/ ydrv=:ydrv_overlay.sfs pfix=nocopy
If you already have a ydrv but no adrv you could specify "adrv=:ydrv_overlay.sfs" instead.
It should boot as pupmode=5 for the first boot. On first shutdown there should be no "shutdownconfig".
If your frugal install directory is on a Linux partition, a reboot should result in pupmode=12.

There is no logical reason why the mount point of a savefile could not be used as the rw directory of the overlay instead of a savefolder.

Because there is no way to modify an overlay mounted as /, and modifying any ro directory in an overlay leads to an "undefined" result, pupmode=13 simply cannot work. So I'm working on a pseudo pupmode=13.

gyro
Back to top
View user's profile Send private message 
Rangan Masti

Joined: 01 Jan 2013
Posts: 32
Location: Germany, Berlin

PostPosted: Fri 23 Jun 2017, 06:34    Post subject:    

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.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Fri 23 Jun 2017, 14:30    Post subject:  

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.
You're welcome, and thanks for testing.
Just for information, overlayfs support can be builtin or a module; if it's a module, the "init" script will "insmod" it.

Just one question, does your kernel have aufs support?
This should work without aufs support, but the puppy kernel's I use for testing all include aufs support. And it's on my todo list to test it using a kernel that doesn't have aufs support. So if it works with your kernel and it doesn't have aufs support, I can cross that test off my list.

gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Fri 23 Jun 2017, 14:36    Post subject: Re: Announcing a new version  

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.
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.
So, I'm putting this into the too hard basket for now.

gyro
Back to top
View user's profile Send private message 
Rangan Masti

Joined: 01 Jan 2013
Posts: 32
Location: Germany, Berlin

PostPosted: Fri 23 Jun 2017, 14:43    Post subject:  

Hi good evening. Thank you for the response. My compiled kernel has no aufs module in it.
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 2930
Location: Worcestershire, UK

PostPosted: Mon 26 Jun 2017, 04:54    Post subject:  

gyro wrote:
It should boot as pupmode=5 for the first boot. On first shutdown there should be no "shutdownconfig".
If your frugal install directory is on a Linux partition, a reboot should result in pupmode=12.

This didn't happen for me....on 1st shutdown the message "Session not saved" flashed up and on reboot it was still pupmode=5.

I renamed the ydrv-overlay to a full ydrv name....it installed correctly....there was no shutdownconfig

Boot:
title Devtest (sda3/devtest)
uuid 95a633e7-6fab-431d-9fa8-550812ab03f8
kernel /devtest/vmlinuz pmedia=atahd pdrv=sda3 psubdir=devtest pfix=fsck
initrd /devtest/initrd.gz
Screenshot.png
 Description   
 Filesize   75.66 KB
 Viewed   136 Time(s)

Screenshot.png


_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Mon 26 Jun 2017, 17:25    Post subject:  

Rangan Masti wrote:
Hi good evening. Thank you for the response. My compiled kernel has no aufs module in it.
Ok, thanks.
gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1401
Location: Brisbane, Australia

PostPosted: Mon 26 Jun 2017, 17:36    Post subject:  

peebee wrote:
I renamed the ydrv-overlay to a full ydrv name....it installed correctly....there was no shutdownconfig
Well you had to rename the ydrive, because there is no "ydrv=" parameter in your boot entry to override the default filename.

But you should get pupmode=12.
Where does the symbolic link "/initrd/pup_rw" point to?
It should point to an "/mnt/sda3/devtest/LxPupScsave" directory.

I have this working on LxPupSc 17.06.22.

Edit:
Ah, ah, you also need a "pfix=nocopy" instead of "pfix=fsck" on your boot entry.
Without the "pfix=nocopy" it remains at pupmde=5, all in ram.
With the "pfix=nocopy", since the partition is going to remain mounted anyway, it tries for pupmode=12.

gyro
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 2930
Location: Worcestershire, UK

PostPosted: Tue 27 Jun 2017, 06:31    Post subject:  

gyro wrote:
Edit: Ah, ah, you also need a "pfix=nocopy" instead of "pfix=fsck" on your boot entry.

Hi gyro

Is this a temporary fix or a design decision for how the new init will always work?

Putting pfix=nocopy does not seem intuitive to me - I want Puppy loaded into ram to maintain the speed advantages.....I've never used nocopy so I'm vaguely remembering that that's what it means....

Thanks
peebee

_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 3 of 7 [93 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
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.1252s ][ Queries: 14 (0.0117s) ][ GZIP on ]