Posted: Sun 26 Feb 2012, 13:43 Post subject:
How to get Grub to pick a pupsave file... in 4.3.1?SOLVED

This issue has been covered a few times before: how to configure grub so that, using on both cases the same distro files (Puppy 4.3.1. frugal in this case), it boots with a certain pupsave file, saving the step of a new menu with the options 0-no pupsave, 1,2,3 etc for the different pupsaves found in the hard disk, etc...

It seems some versions of the init scripts can handle a 'psave=' grub parameter intended to get this purpose. Puppy 4.3.1. does not have such feature, so I modified the init file as explained here:

With p421 you can use 'psave=' and specify the pup_save to use in case of several pup_saves in the same dir. To enable this in other series 4 you would need to edit the init as above.

This even seems to have been a 'delicate' issue. A bit ahead, on the same thread:

Quote:

Are you going to tell Barry? I've already been chastised in his blog for daring to suggest he started 4.3 from the wrong base (4.1.2 instead of 4.2.1). He doesn't see it that way, because the development method IS more advanced than either, but here is another example of things being solved for 4.2 getting lost.

Apparently, the 'psave=' grub parameter, which allows to make the choice, got lost in 4.3.1.

(I also tried an initrd.gz editor by Pizzasgood, but it generated two screens of errors, maybe the peculiar idiosyncrasy of 4.3.1?).

OK, so I modified the init script as required, repacked everything back into initrd.gz, put initrd.gz back within the correct puppy folder (keeping a prechanges backup), and modified menu.lst with the appropriate psave= parameter.

It keeps booting normally, but without success: boot after boot, I am presented with the menu with 0 - no pupsave, and 1, 2, etc with all the pupsaves found in the hard disk.

I have tried all kind of combinations of commands in the menu.lst: including the psubdir parameter and without it. Using the old PUPSAVE parameter (the one that requires to specify the kind of filesystem, etc). Including the psubok parameter. Nothing seems to work. I guess there is something very particular about the way 4.3.1. handles this issue.

It is not big deal because Puppy is so lightweight that my solution has been duplicating all the 4.3.1. files, vmlinuz, initrd.gz, pup-431.sfs, and my desired pupsave, into a new folder, and have the psubdir parameter pointing to each of the options from grub entries. But I find a bit annoying having such unnecessary duplication of data, and above all, I'd like to understand what is this all about.

Anybody has a clue of what is going on here? After a whole morning learning about Grub, I'm quite curious.

Would it be a feasible approach to use LILO instead?Last edited by Rattlehead on Tue 28 Feb 2012, 08:36; edited 1 time in total

It won't matter which bootloader you use, because it is not the bootloader which processes that option -it's in the init scripts -that's where you'd have to make it work. 'psave' is a Puppy-specific 'cheatcode' -the bootloader, the kernel, and the 'real' init (if it was used by Puupy) all ignore that option.

As amigo mentioned, fiddling with the grub command line won't help you.
So I would suggest you restore the original grub line.

That done, this old trick from a few years ago just might help you, however.

In the same directory as your current personal savefile (<- this is important <- ),
create a dummy file with nothing in it, with a name such as
lupusave-abc.3fs or whatever the convention is for 4.3.1.

Now, when you re-boot, an intermediate menu will appear after the kernel is loaded, something like:
0 no sfs (similar to pfix=ram)
1 your regular personal sfs savefile
2 the dummy file.

I'd suggest you choose 0 (zero) if you want to create a new personal sfs.
With this 0 option, you boot into a "virgin" puppy. You can then add/remove whatever you like. Make your 4.3.1 Puppy into a game distro or a media distro, or what have you.

When you're finished, save your work under a personal savefile with a different, specific name, such puppy431-games.2fs

At next boot up, you will then have 4 choices:
the three above, plus your new sfs file.

Choose the one you want, but make sure you avoid the dummy file for this boot.

Once booted, I would suggest you now erase the dummy file: since you now have more than one valid puppysave files, the intermediate menu will still appear.

And removing the dummy file will prevent "distraction" or "key mix-up" accidents.

You can repeat this little process at will to create as many "flavours" of puppy 4.3.1 as you like.

It is not big deal because Puppy is so lightweight that my solution has been duplicating all the 4.3.1. files, vmlinuz, initrd.gz, pup-431.sfs, and my desired pupsave, into a new folder, and have the psubdir parameter pointing to each of the options from grub entries. But I find a bit annoying having such unnecessary duplication of data, and above all, I'd like to understand what is this all about.

just thinking out loud after reading the other posts . . . Rather than have all these duplicate files, could you use symlinks pointing to one set of files?

More or less it would be the same solution you mentioned, but saving space.

@Musher: I could be wrong, but I think that the OP is trying to come up with a way of skipping the step, that you set out to help him create.

I think the goal is at boot, he is presented with one set of choices, something like:
1) puppy 4.3.1 pupsave for Jenny
2) puppy 4.3.1 pupsave for Jim
3) puppy 5.25 pupsave for Fred
4) Ubuntu
5) Window$

I was not referring to the grub menu. Which seems to be the case judging from your example.

What I'm talking about is that you can actually defer your choice of pupsave files for Tom, Dick or Harry, or for wine, games or media, to within the puppy launch process.

With my suggestion, in your example, you could have only one entry in your grub menu for Puppy 4.31 and at the intermediate menu, present your choice for Jenny and Jim.

I can't explain it more than I did. If you don't believe me, try it. Try creating a dummy file in the same folder as your regular pupsave file and reboot as usual. You'll see that I am not inventing anything. This would save you from copying the boot files into another directory or from symlinking them from one.

This tip was suggested by "MU" way back when* and I'm still using it on my lupu 5.2.5 to distinguish between "flavours" of lupu. For example, I have one for the regular lupu and one which is more wine-oriented.

You can really have an intermediate menu appear to choose different pupsaves -- other than the grub menu.

In any case, at whatever level, you need an entry, whether in the grub menu or within Puppy after the kernel has loaded. You can't wish a pup_save file into loading, can you?

BFN.

* Unfortunately, I had no success searching for MU entries in the forum. Are entries from permanently gone members made invisible to the forum search tool? I don't know. (Just in case I decide to "go", maybe I should open a blog to save my own stuff in. Off-topic, I know.)_________________musher0
~~~~~~~~~~
"Logical entities must not be multiplied beyond necessity." | |
« Il ne faut pas multiplier les entités logiques sans nécessité. » (Ockham)

Another (very restricted) workaround, you can use PSAVEMARK to boot a save file from another partition of the same drive.

E.g. usually you boot from sda1 with one save file there. Now you create/copy another save file on sda2. All you have to change in menu.lst is adding "psavemark=2" at the kernel line.
If you have e.g. 5 partitions, you can have 5 different save files. No menu to choose a different save file.
I've not tested it with 4.3.1.

Hope this helps
Rolf

Edit: @musher0
I don't think that Mark has gone permanently but yes, you can't find all his posts by forum search. You could use google search for this forum._________________Ich verwende "frugal", und das ist gut so.
Raspberry Pi without Puppy? No, thanks.

how to configure grub so that, using on both cases the same distro files (Puppy 4.3.1. frugal in this case), it boots with a certain pupsave file, saving the step of a new menu with the options 0-no pupsave, 1,2,3 etc for the different pupsaves found in the hard disk

I assumed "saving the step" meant avoiding or skipping the step. But perhaps, as you've read it means preserving or even restoring a step that has been lost. In which case I fully agree with your suggestion.

And I actually like your method. Especially for giving an extra chance of essentially booting pfix=ram / ie no save file because I sometimes am not paying attention when the initial splash screen comes up.

Hey people, thanks for all your suggestions. Let me elaborate a bit more what I wanted. What I was trying to achieve was a 'sandbox mode', in order to ease trying out pets, restoring things when something goes badly...

To do so, I have set two options in my grub menu: 1)my regular pupsave file, and 2)the sandbox pupsave, cloned from 1) and disposable.

I have set grub menu with timeout=1 second, so it gets kind of 'masked' at boot. In case I want to toy around one day, I wait for the menu to appear and press arrow down, it cancels the countdown, and then I choose sandbox and do all my testings in such 'sandbox mode'. Otherwise, the boot remains fully automatic.

Getting some things to work can take several attempts, compilations, adding stuff that later will no longer be necessary... So once I'm successful, I go back to the normal pupsave and apply the successful solution, avoiding all the previous clutter. The sandbox pupsave is then deleted and replaced by a clean one.

The difference between this method to choose pupsave, and Musher's suggestion, is that Puppy's intermediate menu does not time out, so I would be asked for a choice every boot; and I want the boot to happen automatically.

Sorry for the idiomatic ambiguity; yes, by 'saving the step' I meant skipping the intermediate menu.

@Amigo,
trying out different grub parameters was only one of the things that I did, out of frustration, after I saw that modifying the required lines in init did not have the reported effect (I wish my own self from a year ago could see me: modifying inird.gz! He would be soaked in cold sweat ).

@Rhadon,

thank you for the suggestion, I did not know the psavemark parameter. It would have been very useful to me before, because another of the things I tried indeed was formatting a small partition to ext2 and installing my sandbox there... but the intermediate menu did not make difference and detected everything that is in a hard disk. With psavemark I could probably make that work, but, in the meantime, I have discovered some advantages to my 'redundant' mehtod: for example, it allows to share the sfs files, like devx, etc. So I think by the moment I'll stick to my configuration.

@Sfeeley
Yeah, I also thought of making links instead of duplicating the actual files. I did not get to try it because I thought, afaik, that during that early stage, the bootloader does not recognize filesystems, but dumps complete image files, enormous chunks of information from the HD to RAM, and a link looks like something 'sophisticated' that must be taken care of by a filesystem. Maybe it might have worked, I'm no expert in the boot sequence, but at that time I was tired and I settled with my 'redundant' system, and it works well for me.

So, I guess, the mysterious 4.3.1.-Grub affair will have to remain unsolved...

Rattlehead wrote:
> Getting some things to work can take several attempts, compilations,
> adding stuff that later will no longer be necessary... So once I'm
> successful, I go back to the normal pupsave and apply the successful
> solution, avoiding all the previous clutter. The sandbox pupsave is then
> deleted and replaced by a clean one.

Very clever. Why didn't I think of that? Your head is probaly not "rattled" too much.

@catdude:
Thanks for the very clear illustration of the two launching systems in one fell swoop. My own brain was close to neutral gear last night. I couldn't come up with a proper example.

@rhadon
Thanks for the info about the search tool and about MU. If he ever comes back, I'm sure he'll be greeted with proper "NY" tickertape, with lots of people lining the "Broadway" of PuppyVille and much, much applause.

I have it working now . I have just deleted my /sandbox folder because its files are no longer necessary. Just an additional pupsave-431_sandbox.2fs file, as intended.

Thank you so much Catdude for contributing your solution. I wonder what was I doing wrong; maybe a combination of tiny steps. My initial hypothesis, at the beginning of this thread, was that the improved initrd.gz was not compatible with 4.3.1. You, by contributing it, have taken that possibility out of the equation. As I did not know that, I extracted and edited init by my own means, using the cpio command and all of that. It seemed to work alright, but maybe there it was the 'wrong turn'.

I'm curious about one thing: you specify a psubdir option only in the first stanza, the one that leads to the intermediate menu. Is it casual, or is it, maybe, the heart of the matter?

@musher0, I'm very glad you liked my solution. I used to make a backup of my pupsave before I started my tests, and went back to it only when something went really wrong. When I succeeded, I was usually too lazy to go back to it and apply the solution a second time, so I guess I've been accumulating a lot of random garbage along the years. With this system, I push myself to be more organized. In addition to the timeout=1 trick, it makes my geek life much easier

I wonder if this feature made it to Lupu. I'll check it one of these days and if not, I'll contribute it as a suggestion for the upcoming Puppy version. All the brain work is done here, so I guess it will be very easy to include.

This is what I really love about Linux; to some people, a few Mbs or an additional keypress is no big deal; but if a computer is, like they say, an extension of one's brain... well, I want to have as much command of it as possible.

I wonder if this feature made it to Lupu. I'll check it one of these days and if not, I'll contribute it as a suggestion for the upcoming Puppy version. All the brain work is done here, so I guess it will be very easy to include.

Don't be daft! Crash's great work that was in Puppy 4.2.1 never made it to Puppy 4.3, (different developer - you see), and then got lost.

You are very welcome, but i wouldn't go as far as saying it was my solution,
as all i did was hack a file with code that was put together by Crash.

Rattlehead wrote:

...I extracted and edited init by my own means, using the cpio command and all of that. It seemed to work alright, but maybe there it was the 'wrong turn'.

I simply used a couple of scripts, namely: Open_initrd.sh and Rebuild_initrd.sh
that are included in the 0_pupbuild_tools_2.tar.gz package
that jrb posted a link to in this post (last link in that post)
Be sure to read the included Readme.txt file.

Rattlehead wrote:

I'm curious about one thing: you specify a psubdir option only in the first stanza, the one that leads to the intermediate menu. Is it casual, or is it, maybe, the heart of the matter?

I did that intentionally, to restrict Puppy to searching ONLY in that subdirectory.
The 2nd and 3rd stanza's did not require it as the psave=xxx parameter told Puppy which savefile to use.
But saying that, i don't think it would hurt if you also added it to those stanza's too.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum