Page 110 of 143
Posted: Thu 01 Nov 2012, 15:04
by bigpup
otropogo,
Damn! I forgot Gparted doesn't work in Puppy any more...
Works OK for me.
Explain?
With all the save files you seem to have.
Very important they each have a specific unique name.
If you have more than one with the same name, it could be causing some of your problems.
Even a copy of a save file should be given a specific name.
Better yet give it a name that has nothing to do with lupusave.
Posted: Thu 01 Nov 2012, 15:31
by otropogo
bigpup wrote:otropogo,
Damn! I forgot Gparted doesn't work in Puppy any more...
Works OK for me.
Explain?
When I click on the menu/system/gparted tab, I get the menu of drives on the system. When I click on one of them, the menu disappears, and nothing happens. When I look at running processes, there's no sign of gparted.
With all the save files you seem to have.
Very important they each have a specific unique name.
If you have more than one with the same name, it could be causing some of your problems.
Even a copy of a save file should be given a specific name.
Better yet give it a name that has nothing to do with lupusave.
Never have a problem with this when booting from the LiveCD, and yes, all of my 2fs files are distinctively named.
But in any case, I reduced my 2fs files to two on hdd and one on the flash in the course of this experiment.
The problems seem to me to be in the flash installer.
It doesn't have adequate controls over the process, for one thing. It didn't detect any issues with the MBR (pmount doesn't give any amount for free space).
It went through the motions of redoing the MBR, and didn't report any problems. It then proceeded to "wipe" the disk and install lupupluslibre to the disk from the LiveCD, and again reported no problems, although it was only able to copy 11MB of data (8MB of the 353 lupu528.sfs) and 2MB for initrd.gz) to a disk pmount reported at 500MB.
Posted: Thu 01 Nov 2012, 15:40
by rcrsn51
otropogo wrote:Thanks for your suggestion. I'm afraid there's no cigar yet though.
You now have a frugal install that starts its boot sequence on a flash drive. In this scenario, Puppy wants to find all its core files in the same location as the main sfs file. So copy vmlinuz and initrd.gz from the flash drive onto the hard drive.
Now Puppy is finding all its files in the same place, so it will also see the save files.
To improve the search process, include the boot argument "psubdir=xxx" in your syslinux.cfg file.
Posted: Thu 01 Nov 2012, 20:28
by bigpup
When I click on the menu/system/gparted tab, I get the menu of drives on the system. When I click on one of them, the menu disappears, and nothing happens. When I look at running processes, there's no sign of gparted.
This is starting to look like a bad download of the Puppy version iso.
Try this to see if it makes a difference.
Boot with the Puppy live CD
Use boot option puppy pfix=ram
Now try to use Gparted.
What happens?
Posted: Thu 01 Nov 2012, 20:32
by otropogo
rcrsn51 wrote:otropogo wrote:Thanks for your suggestion. I'm afraid there's no cigar yet though.
You now have a frugal install that starts its boot sequence on a flash drive. In this scenario, Puppy wants to find all its core files in the same location as the main sfs file. So copy vmlinuz and initrd.gz from the flash drive onto the hard drive.
Now Puppy is finding all its files in the same place, so it will also see the save files.
Ah, yes. Wish I had known that yesterday. Happily, I'm still able to edit the syslinux.cfg file on the flash card, but Windows couldn't format it, and eraser said it couldn't establish cluster size,probably because Puppy's universal installer messed up the ext3 2fs save (for which it failed to ask for a size...). I'll have to try to run Gparted under Knoppix to try to get the full capacity back.
Glad I didn't use a pricey 64GB flash card for this install.
To improve the search process, include the boot argument "psubdir=xxx" in your syslinux.cfg file.
I don't know if it will improve the search speed any, since it only takes 10 seconds now. Maybe that's because it's in a folder named "pupsave" in the root directory of disk 0.
Apparently, the 2fs files, and presumably any other sfs files, must be in the same directory where the loader finds lupu_528.sfs , vmlinuz, and initrd.gz, or it won't offer them for use.
At least it looked no further once it found the directory with the last three. To get it to offer my other 2fs file for use, I had to copy it to the same folder.
But I'm curious as to the exact format required for psubdir=xxx?
I tried
which is the path to the directory containing the necessary files.
But then the boot failed with the message "lupu_528.sfs" not found, and left me at the command line.
Posted: Thu 01 Nov 2012, 20:36
by bigpup
This is the way I use Gparted for heavy work.
Gparted live CD
For partitioning I would suggest you use the Gparted live CD that you can get from here.
You can download a free version to make your own Gparted live CD.
It is up to date and specifically made to run Gparted.
Info:
http://gparted.sourceforge.net/livecd.php
Download:
http://sourceforge.net/projects/gparted ... ve-stable/
2fs enlargement glich
Posted: Thu 01 Nov 2012, 20:39
by otropogo
I happened to boot with a smallish 2fs file, and decided to increase the size by 64MB.
Then rebooted with the original file I had meant to use, only to see that it was enlarged (at least, that's what the popup said) instead of the intended target.
Guess I'll have to reboot with the file I intended to enlarge, to see if it grows as well or not.
Posted: Thu 01 Nov 2012, 20:42
by bigpup
Re: 2fs enlargement glich
Posted: Thu 01 Nov 2012, 20:48
by bigpup
otropogo wrote:I happened to boot with a smallish 2fs file, and decided to increase the size by 64MB.
Then rebooted with the original file I had meant to use, only to see that it was enlarged (at least, that's what the popup said) instead of the intended target.
Guess I'll have to reboot with the file I intended to enlarge, to see if it grows as well or not.
Yes if you select to re-size a save file you have to reboot using that same save file. At boot is when the re-size is done.
When you select to re-size it works only on the next boot/reboot one time.
New selection to re-size has to be made each time you want to do it.
Posted: Thu 01 Nov 2012, 20:55
by otropogo
However, do note that Puppy now has a confirmation dialog if only one save-file found, enabling you to back off and not auto-update it. I announced this a couple of days ago.
Not what happened to me just now.
Until I copied a second 2fs file into the /pupsave directory, Puppy simply booted with the file it found there, without any dialogue allowing me to "back off" as Barry puts it.
Re: 2fs enlargement glich
Posted: Thu 01 Nov 2012, 21:01
by otropogo
bigpup wrote:otropogo wrote:I happened to boot with a smallish 2fs file, and decided to increase the size by 64MB.
Then rebooted with the original file I had meant to use, only to see that it was enlarged (at least, that's what the popup said) instead of the intended target.
Guess I'll have to reboot with the file I intended to enlarge, to see if it grows as well or not.
Yes if you select to re-size a save file you have to reboot using that same save file. At boot is when the re-size is done.
When you select to re-size it works only on the next boot/reboot one time.
New selection to re-size has to be made each time you want to do it.
Curious. Where is the information to resize the file kept while you're rebooting? Surely, wherever it is, it should also contain the information regarding the name of the file to be enlarged?
Missing the enlargement by failing to reboot the same 2fs file is just a minor annoyance. But enlarging a file you didn't mean to enlarge could be a serious problem, since it can't be undone.
Posted: Thu 01 Nov 2012, 21:12
by otropogo
Thanks. I knew that, probably have an older copy around, but it always irks me that I can't get it to work in Puppy anymore.
BTW - I did try to download the latest version just now, but for some reason sourceforge and its mirrors are downloading like molasses today, at least at this end.
Will try again later.
Update, after downloading Gparted from Taiwan at top speed, the download failed with a series of nonsensical error messages, starting with "no room, try another directory" or words to that effect, and ending with "unable to read source file", after supposedly tranferring 126/127MB.
So I booted Knoppix 7.0.4, went to Preferences/Gparted (v 070), and viewed the corrupted SD card with it. Apparently, the only thing I could do was to reformat the card (I used FAT16). I then copied the files from the LiveCD, edited syslinux.cfg, set the boot flag, and tried to boot with it. But the system reported the disk was unbootable.
So I took it back to the Universal Installer, used the USB Flash drive function, left the MBR alone, re-edited the syslinux.cfg, renamed the sfs file to .bak, and tried booting again. Finally, success...
What have I learned?
...
UPDATE: several hours of further experience with both flash installers have changed my mind. Bootflash is more versatile and faster, it just takes a bit more attention.
...
It also turns out to be unnecessary to rename or delete the sfs file from the flash media when changing pmedia=usbflash to =atahd in syslinux.cfg to with sfs and 2fs files on the hard drive.
Nor is it even necessary to place all the 2fs files in the same folder with the sfs file. But it may be necessary to keep lupu_528.sfs in the root directory or in a folder in the root directory. I haven't tested this.
PS. thanks again, rcrsn51 and bigpup
Posted: Thu 08 Nov 2012, 06:05
by otropogo
bigpup wrote:When I click on the menu/system/gparted tab, I get the menu of drives on the system. When I click on one of them, the menu disappears, and nothing happens. When I look at running processes, there's no sign of gparted.
This is starting to look like a bad download of the Puppy version iso.
Try this to see if it makes a difference.
Boot with the Puppy live CD
Use boot option puppy pfix=ram
Now try to use Gparted.
What happens?
Sorry I've taken so long to reply to your suggestion above. The answer is yes, gparted works when I use the option pfix=ram. However, I booted from the usbflash install. Apparently the issue has something to do with the 2fs file.
But now I'm trying to figure out why I can't install puppy to flash on a 2GB SD card although I can do it on a 500MB SD or a 256MB CF card.
Every time I do, Universal install declares success, but the card merely becomes unreadable, and I have to go to Gparted, or to a camera, to reformat it. Even Windows 7 can't fix it.
Inconsistent syslinux.cfg behaviour
Posted: Fri 09 Nov 2012, 00:56
by otropogo
After considerable fiddling, I managed to compose a 256CF flash card that reliably boots lupuplus from the hard drive.
But unlike the 500MB SD card I've been using up to now, simply changing pmedia=usbflash to pmedia=atahd in syslinux.cfg didn't do the trick. It would only load from the card itself, ignoring the change.
But if I booted with the command puppy pdev1=sda1, then the hard drive was searched, the 2fs files on it were presented, and the lupuplus sfs (which is too large to fit on the CF card) was loaded into RAM.
I then found that adding the line
after
in syslinux.cfg achieved the same result.
However, either way, the loader then displays :
searching deeper in sub-sub-folders in partitions
which has never appeared with the atahd argument on the SD card.
And the message makes no sense, since the lupu_528.sfs file is in a folder in the root directory of sda1. And this message still displays if I add the argument
/pupsave
(the folder where the sfs and 2fs files reside), nor does the search (the longest part of the loading process) seem any faster than when booting with the SD card with only
specified.
Posted: Fri 09 Nov 2012, 02:44
by bigpup
And the message makes no sense, since the lupu_528.sfs file is in a folder in the root directory of sda1. And this message still displays if I add the argument
/pupsave
Try making this
Posted: Fri 09 Nov 2012, 06:26
by otropogo
bigpup wrote:And the message makes no sense, since the lupu_528.sfs file is in a folder in the root directory of sda1. And this message still displays if I add the argument
/pupsave
Try making this
Yes, bigpup. That worked. I timed the interval from hitting ENTER at the puppy boot prompt to the moment the 2fs files were displayed at
81 seconds without the spsubdir argument, and
38 seconds after it was added
A substantial speed-up, thanks.
Interestingly, I then added pdev1=sda1 psubdir=pupsave to the SD card's syslinux.cfg file also, but the gain was much smaller in that case, a mere 10 seconds shaved off.
49 vs 39 seconds.
My guess is that the loader on the CF card was searching further than the one on the SD card before the psubdir argument was added. But I can't imagine why.
Presumably pmedia=atahd automatically sets the SD loader to search the root directory of the first partition of disk0 first, followed by the the folders in that directory.
But the argument that the CF card required to find the same directory would have set it to do exactly the same thing, since sda1 is the first partition of disk0.
I'm tempted to experiment further by putting extra 2fs files elsewhere on the hard drives, including in folders within folders, where they're not supposed to be found at all. I know that when I boot from a LiveCd (I don't have one burned at the moment), the loader searches all storage devices on the system for 2fs files, and the partition on which the chosen 2fs file is located becomes "home" and can't be unmounted.
However, I wonder whether more than a handful of us care about this.
I couldn't resist moving one 2fs file into the root directory of sda1 and removing all but the pmedia=atahd argument from the SD card's cfg file. The loader then showed only the two 2fs files remaining in the pupsave folder.
So I conclude that it takes the loader 10 seconds to examine the 21 files and 99 folders (or as many of the latter as precede "pupsave' in its search order) in the root directory of sda1 looking for lupu_528.sfs. And this explains the time saved by adding the psubdir=pupsave .
argument.
But why it takes the loader launched from the CF card 32 seconds longer to do exactly the same thing remains a mystery to me.
Posted: Fri 09 Nov 2012, 08:11
by greengeek
otropogo wrote:However, I wonder whether more than a handful of us care about this.
Sometimes only one person digs deep enough to discover new information, but it is still very helpful. This sort of thing is always useful information. It adds to the overall knowledge pool and helps us understand the finer points of what is going on. Good research.
Posted: Fri 09 Nov 2012, 09:29
by ETP
Hi greengeek,
Please access your PMs. (I need feedback on MK5 & MK7)
Posted: Fri 09 Nov 2012, 16:37
by bigpup
otropogo,
Some of this speed difference could be caused by the different storage devices read speeds.
Posted: Fri 09 Nov 2012, 17:07
by otropogo
greengeek wrote:otropogo wrote:However, I wonder whether more than a handful of us care about this.
Sometimes only one person digs deep enough to discover new information, but it is still very helpful. This sort of thing is always useful information. It adds to the overall knowledge pool and helps us understand the finer points of what is going on. Good research.
Thanks for your encouragement, greengeek.