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 17 Jul 2018, 21:33
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
Rationalisation of init
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 5 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Author Message
gyro

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

PostPosted: Sun 24 Jul 2016, 05:08    Post subject:  

@jlst,

I think there are 2 process here:
1) Upgrade save from one puppy version to another, e.g. tahrpup 6.0.2 to tabrpup 6.0.5. Trying to ensure that any new stuff in puppy...sfs is not hidden by old stuff in the save layer.
2) Update system files if a different set of sfs files are included in the stack, i.e. update menu, update fonts, etc....

Maybe rc.update is more about 2) rahter than 1), and the "init" script is supposed to do 1).

gyro
Back to top
View user's profile Send private message 
Moose On The Loose


Joined: 24 Feb 2011
Posts: 778

PostPosted: Sun 24 Jul 2016, 11:26    Post subject:  

gyro wrote:
@Moose On The Loose,

I assume that you are referring to the code processing the "pfix=" boot parameter?

gyro


This case was specific but I was hoping to make a broader point that telling the user something they did was ignored because it didn't make sense should be a common practice. It could also apply to other configuration points like perhaps the video driver not supporting a requested feature.
Back to top
View user's profile Send private message 
jlst

Joined: 23 Nov 2012
Posts: 571

PostPosted: Sun 24 Jul 2016, 20:43    Post subject:  

Yesterday i was testing the new init with the current initrd-tree and static progs and code from rationalise

Added fdrv, ydrv and adrv to push the limits.
First book... ok.
Installed devx, reboot ok.
Second boot.. ok

Reboot.. oh.. it doesn't reboot, it also tries to unmount /pup_rw so I was going to test possible fixes... but it was 1am already (almost 2am).

This is what I know:
executing mount, it showed /pup_rw while all others were "/initrd/pup_*"

/initrd/pup_rw was a broken symlink, so that may explain something.

also checking the savefile, in /initrd/tmp/bootinit.log i see this:

mkdir: can't create directory '/pup_new/initrd/pup_rw': No such file or directory
mount: mounting /pup_rw on /pup_new/initrd/pup_rw failed: No such file or directory

--

The script should delete "/pup_new/initrd/pup_rw" (it may be a broken symlink) before attempting to create the dir

So the question is.. how did this happen?
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Mon 25 Jul 2016, 04:44    Post subject:  

@Moose On The Loose,

I tend to agree with the principle, but there are limits to how far you can go.
e.g. With boot parameters of the form "param=value", then the code should be able to give a warning if the "value" is not acceptable, but since the "param" is picked-up by name, unacceptable "paramm=" is never decteded.
The new init code tries to log unacceptable "value" to "bootinit.log".
On the other hand, having a catch-all at the end of the "pfix=" code that logs a message, looks like a good idea.

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

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

PostPosted: Mon 25 Jul 2016, 04:50    Post subject:  

jlst wrote:
The script should delete "/pup_new/initrd/pup_rw" (it may be a broken symlink) before attempting to create the dir
It's supposed to do this, I will check it.
Although rc.shutdown also used to delete the symlink.
When I've seen a problem like this it was caused by changing from pupmode=13 to pupmode=12, or from savefolder to savefile.
jlst wrote:
So the question is.. how did this happen?
I've done so many reboots, I find it hard to believe it's just that.
But while I've used many adrv etc..., I've never introduced an extra sfs like the devx. So it's back to even more testing.
gyro
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Mon 25 Jul 2016, 06:14    Post subject:  

@jlst,

I've applied a patch that should fix the left-over symbolic link problem.

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

Joined: 23 Nov 2012
Posts: 571

PostPosted: Mon 25 Jul 2016, 16:06    Post subject:  

Yes that fixes the issue, but it looks like the devx is not loaded at bootup, running 'sfs_load start' in a terminal window loads the devx and updates stuff.

it looks like the new init is still missing code to load the extra sfs
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Tue 26 Jul 2016, 07:58    Post subject:  

jlst wrote:
it looks like the new init is still missing code to load the extra sfs
Yes, and I have no intention of adding it.
Extra sfs's are left to sfs-load.
When I loaded the devx with sfs-load, every boot produced a "next boot will be faster" message, and the menus were not updated until I did a manual "fixmenus". So more testing of what's happening with the BOOTCONFIG file for me.

I would really like to see a complete separation of the system sfs's handled by init, and the extra sfs's handled by sfs-load. This includes sfs-load not touching any sfs's mentioned in DISTRO_SPECS or PUPSTATE, and not accessing BOOTCONFIG at all, i.e storing it's list of extra sfs's somewhere else.

Oh, thanks for testing.

gyro
Back to top
View user's profile Send private message 
Moose On The Loose


Joined: 24 Feb 2011
Posts: 778

PostPosted: Tue 26 Jul 2016, 10:17    Post subject:  

gyro wrote:
@Moose On The Loose,

I tend to agree with the principle, but there are limits to how far you can go.
e.g. With boot parameters of the form "param=value", then the code should be able to give a warning if the "value" is not acceptable, but since the "param" is picked-up by name, unacceptable "paramm=" is never decteded.
The new init code tries to log unacceptable "value" to "bootinit.log".
On the other hand, having a catch-all at the end of the "pfix=" code that logs a message, looks like a good idea.

gyro


I think that all parameters in the "xxxx=yyyy" form end up as environment strings. At least the log could have a dump of all of them. This way there is a chance the person may spot the problem.
Back to top
View user's profile Send private message 
jlst

Joined: 23 Nov 2012
Posts: 571

PostPosted: Tue 26 Jul 2016, 15:45    Post subject:  

Indeed. You're right gyro. sfs_load should be part of the system, so i'll move it to where it belongs, in rootfs-skeleton/usr/sbin, that's where you can add patches
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Wed 27 Jul 2016, 04:47    Post subject:  

Moose On The Loose wrote:
I think that all parameters in the "xxxx=yyyy" form end up as environment strings. At least the log could have a dump of all of them. This way there is a chance the person may spot the problem.
I don't know if they do become enviroment strings.
But you can always see what boot parameters were used with the command:
Code:
cat /proc/cmdline
gyro
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Wed 27 Jul 2016, 05:08    Post subject:  

jlst wrote:
Indeed. You're right gyro. sfs_load should be part of the system, so i'll move it to where it belongs, in rootfs-skeleton/usr/sbin, that's where you can add patches
I thought I was just arguing for the separation of responsibility for different sfs files between init and sfs_load, not commenting on it's location.
The current sfs_load tries to fudge this separation by rewriting BOOTCONFIG with only the system sfs files, during shutdown.

I've found my problem with sfs_load, it doesn't play well when you specify adrv... etc with a non-standard filename. But it does, if you use only the names as per DISTRO_SPECS. It needs to ignore the actual filenames as per PUPSTATE, in the same way it does the standard ones as per DISTRO_SPECS.
I was specifying pcmanfm32.sfs as my adrv, and show.sfs as my ydrv.

I'm not likely to be producing patches to sfs_load in the near future.
Although writing an sfs-install utility to replace sfs_load is on my long term bucket list.

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

Joined: 23 Nov 2012
Posts: 571

PostPosted: Wed 27 Jul 2016, 13:06    Post subject:  

Ok, meanwhile i'll be paving the way with the current init and sfs_load.
Back to top
View user's profile Send private message 
gyro

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

PostPosted: Fri 29 Jul 2016, 11:59    Post subject:  

One other thing that probably should be included is swapfile support.

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

Joined: 22 Feb 2016
Posts: 1528

PostPosted: Fri 29 Jul 2016, 22:49    Post subject:  

edit: Nevermind, found the answers.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 5 of 6 [88 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
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.0615s ][ Queries: 13 (0.0186s) ][ GZIP on ]