Page 39 of 189 [2830 Posts]   Goto page: Previous 1, 2, 3, ..., 37, 38, 39, 40, 41, ..., 187, 188, 189 Next
Author Message
ICPUG
PostPosted: Tue 08 Jan 2013, 14:20    Post subject:

I've run a couple of tests. My current set up has Lupupluslibre and standard Lupu in 2 subfolders of my sda5 partition. Booting each separately I create a file in the home directory to identify which lupu I was in. This was done to be sure I had the correct save file loaded in subsequent tests.

Test 1
I moved lupupluslibre and its save file into the root of sda5 and used the following menu.lst with grub4dos:

##############################################
# GvR Sept 30th 2004
color black/cyan yellow/cyan
timeout=5
default=0

title Default Boot on HD 0
rootnoverify (hd0,0)
chainloader +1
boot

title Lucid Puppy Linux 5.2.8.005 from NTFS sda5
kernel (hd0,4)/lupu5285/vmlinuz PMEDIA=idehd PDEV1=sda5 psubdir=lupu5285 video=640x480
initrd (hd0,4)/lupu5285/initrd.gz
boot

title LupuPlusLibre Linux 5.2.8.005-2 from NTFS sda5
kernel (hd0,4)/vmlinuz PMEDIA=idehd PDEV1=sda5 video=640x480
initrd (hd0,4)/initrd.gz
boot
##########################################

I first booted to Lupupluslibre and because I had not specified psubdir since it was in the root of sda5 it offered me a choice of save files. I chose the lupupluslibre file and it booted fine. I checked for the file in home and I did indeed have the lupupluslibre save file.

I now rebooted and chose to boot standard lupu. According to point 4 of Otropogo's post, Lupupluslibre was going to boot anyway. It didn't. Standard Lupu booted without offering a choice of save files. I checked the file in the home directory and it was indeed the standard lupu save file.

Test 2
I now copied standard lupu to a similar folder on my sda1 partition. Using the following menu.lst:

##############################################
# GvR Sept 30th 2004
color black/cyan yellow/cyan
timeout=5
default=0

title Default Boot on HD 0
rootnoverify (hd0,0)
chainloader +1
boot

title Lucid Puppy Linux 5.2.8.005 from NTFS sda5
kernel (hd0,4)/lupu5285/vmlinuz PMEDIA=idehd PDEV1=sda5 psubdir=lupu5285 video=640x480
initrd (hd0,4)/lupu5285/initrd.gz
boot

title Lucid Puppy Linux 5.2.8.005 from NTFS sda1
kernel (hd0,0)/lupu5285/vmlinuz PMEDIA=idehd PDEV1=sda1 psubdir=lupu5285 video=640x480
initrd (hd0,0)/lupu5285/initrd.gz
boot

I first booted to the Lupu on sda1 and changed the file in the home directory to uniquely identify it with this partition.

I then booted Lupu from sda5 again. It worked and the file in the home directory hadn't been changed so I know I had the right save file.

So Otropogo's point 1 that pdev1 will not determine the partition from which the sfs file is loaded is clearly not true in my setup.

I have also extracted the init file of standard lupu 5.2.8-005 for review. I am going to try to flowchart the 'Finding Puppy Files' routine but as it consists of 8 A4 pages of Barry's bash scripting I may be a little while!
ICPUG
PostPosted: Mon 07 Jan 2013, 14:34    Post subject:

You might like to read this post and those around it:

http://www.murga-linux.com/puppy/viewtopic.php?p=652119#652119

The discussion spreads over pages 9-11 of the thread and sorta peters out without a definitive answer after rcrsn51 found a solution to his particular problem.

Shinobar makes an interesting contribution in his post of Wed 12 Sep 2012, 22:02.

I think you are being a bit draconian in your last post in suggesting pdev1 or psubdir are not doing the job. I think in certain circumstances you may be right but not in all circumstances. I have a multitude of pups on my PC each in their own (hard drive) subdirectory. I do have sfs files and associated save files in the same subdirectory though. I use pmedia, pdev1 and psubdir for each pup in its own section of the boot config file (I use grub4dos and menu.lst). I don't like putting any pup in the root folder of a partition. So far I have not experienced the conflict you are reporting. I must run some tests and see if I can replicate your problems.
otropogo
PostPosted: Sat 05 Jan 2013, 20:49    Post subject: How does puppy's flash boot loader pick the sfs file?
Subject description: pdev1 and psubdir don't determine which lupu_528.sfs file loaded, what does?

Have just completed a dizzying series of test with a newly configured USBflash boot card, trying to figure out how to control which version of the lupu_528.sfs file is loaded.

Have established that:

1. pdev1=sdxx will not determine the partition from which the sfs file is loaded

2. psubdir=folderx will not determine the /partition or /partition/folder from which it's loaded

3. no matter what is written in syslinux.cfg or entered at the boot command line, the loader always boots from sda1 if a lupupluslibre sfs is located there.

4. the loader always loads lupupluslibre instead of lupu_528 standard, even when the latter is in the root directory of sda1 or in a higher subdirectory (ie. earlier in the search order).

5. when lupu_528 (standard) was initially installed earlier today to a CF flash card, the entry:
Code:

pmedia=atahd


Without further arguments, would make it load the 139 MB standard sfs from the card, without presenting any other options.

Adding
Code:
psubdir=pupsave
, either in syslinux or at the boot command line, would cause it to present all of the 2fs files found in all of the /pupsave folders on the system, including that on the CF card itself.

In the second configuration, however, no matter which 2fs file was selected, the lupupluslibre sfs would be loaded from sda1.

6. after a good deal of rebooting, however, booting with the same code

pmedia-atahd

also resulted in the 353MB libre version being loaded!

7. it doesn't matter how one renames the folder holding the lupupluslibre sfs, the loader finds it and loads it instead of the standard sfs. The psubdir argument affects only the location of the 2fs files made available for loading.


Can anyone make sense of this?
otropogo
PostPosted: Sat 05 Jan 2013, 20:04    Post subject:

ansivar wrote:
Quote:

BTW - I had occasion to do a fresh install of lupu_528.005 yesterday on another PC. I ran depmod immediately afterward, but found no listing for the 8191/8192 Realtek module in the network wizard load list (I couldn't test further, since that PC doesn't have a corresponding wifi device). I then tried again, without the existing 2fs file, using the pfix=clean boot command, and then checked the network wizard modules list again. Still no r9191/92 appeared.

I'm not clear on the whether lupu_528.005 is lupu_528 standard or lupu_528 plus, but it appears that the Realtek wifi module was added after its creation.



For rt8192 with k2.6.33.2 try this:
http://www.murga-linux.com/puppy/viewtopic.php?p=462469#462469


Thanks. I do have the problem fixed now, after using depmod on my 2fs file. That is, Network Wizard is able to detect the wifi device and install the driver.

However, I am still puzzled as to why the driver doesn't appear in the load list as the r8169 does.
ansivar
PostPosted: Sat 05 Jan 2013, 19:24    Post subject:

Quote:

BTW - I had occasion to do a fresh install of lupu_528.005 yesterday on another PC. I ran depmod immediately afterward, but found no listing for the 8191/8192 Realtek module in the network wizard load list (I couldn't test further, since that PC doesn't have a corresponding wifi device). I then tried again, without the existing 2fs file, using the pfix=clean boot command, and then checked the network wizard modules list again. Still no r9191/92 appeared.

I'm not clear on the whether lupu_528.005 is lupu_528 standard or lupu_528 plus, but it appears that the Realtek wifi module was added after its creation.



For rt8192 with k2.6.33.2 try this:
http://www.murga-linux.com/puppy/viewtopic.php?p=462469#462469
otropogo
PostPosted: Sat 05 Jan 2013, 16:26    Post subject: More on quirky lupu boot command syntax

Have been playing further with USBflash boot creation, and discovering more and more pitfalls along the way.

Aside from third party bootlash apps, there are two Puppy menus to accomplish this, and a number of bifurcations on those.

My latest attempt was to use Puppy Universal Installer. For reasons I don't understand, choosing the seemingly obvious first option on the menu:

Quote:
setup/Puppy Universal Installer/USB Flash drive/sdc Generic USB CF reader, size 244.3 MiB/ install Puppy to sdc


The only other option on this menu is apparently entitled "Superfloppy", but if you read the largish text carefully, it turns out that the option I chose is the superfloppy one, which leaves the CF card without any partitions, so that it appears simply as sdc on the desktop.

After installing, for which one must either have a LiveCD mounted or an iso opened on the system, I found that the CF card had a usbflash marker placed on it. I added the boot messages from the iso and also a pre-created 2fs file, renamed isolinux.cfg syslinux.cfg, and changed the line pmedia=usbflash to pmedia=atahd.

On rebooting, I discovered that the loader ignored the change, and booted with the sfs and 2fs files on the card. I tried renaming the usflash marker, but that made no difference, nor did moving the marker to one of the hard drives, that only accomplished automounting that drive as well.

In order to boot automatically with the sfs file on the hard drive, and be able to choose among the three 2fs files available,I had to:


1. delete the usbflash marker completely, and

2. add the arguments
Code:
pdev1=sda1 psubdir=pupsave
after
Code:
pmedia=atahd
in sytslinux.cfg

It's still not clear exactly what,
Code:
 pmedia=atahd
does. I suspect it's superfluous, but haven't tested this yet.

Code:
pdev1=sda1 psubdir=pupsave
also behaves unexpectedly.

Logically, it should look only in sda1/pubsave for both the sfs and the 2fs files. But in reality, it looks for a pubsave folder in all of the available drives, including the partitionless CF card, (which can hardly qualify as an atahd).

Will try a few more test reboots to clarify this further.

Update - following numerous reboots rewrites of syslinux.cfg, I've learned that:

1. the argument
Code:
pdev1=sda1
seems to accomplish nothing, leaving it out between

Code:
pmedia=atahd
and
Code:
psubdir=puppy


One would expect it to limit the loading of 2fs files to those in sda1/pupsave, but in fact, all 2fs files in /pupsave/ folders on all available drives are presented. Perhaps it would allow the loading of lupu_528.sfs from a drive other than sda1, if that was desired. But if the sfs is on sda1 that argument seems pointless.


2. my attempts to limit the presentation of 2fs files to those in sda1/pupsave with the entry
Code:

psubdir=sda1/pupsave
and
Code:
psubdir=/mnt/sda1/pupsave
all resulted in a lockup with a message the lupu_528.sfs couldn't be found.

I tried various ways to circumvent this at the boot command line without having to modify the syslinux.cfg line, but all of these failed the same way, including the various boot drive override options


3. after removing both the pdev1= and psubdir= arguments, and leaving only
Code:
pmedia=atahd
, Puppy automatically loaded both the sfs and the 2fs file from the CF card, without offering any other options. I tried putting a marker file caled atahd in the root directory of sda1, since the loader obviously can't distinguish hard drives from any other drive, but it made no difference.

4. However with configuration #3, I was able to modify the loading procedure by entering

Code:
psubdir=pupsave
at the boot command line. The loader then offered all of the 2fs files in the sda1 and sdc pupsave folders, as well as the "0" option.

So it appears one can amplify the last line of the syslinux.cfg file, but not contradict it.

For emergency uses, this last configuration would seem to be the best, as it's the most flexible, allowing one to choose loading from hard drive or from flash media with a simple reboot, without having to somehow get an OS running to access and edit the file.

A final (I hope!) update.

Still hoping to discover some utility in the pdev1=sdxx argument, I rebooted with the minimalist syslinux configuration last described above, and at the boot prompt entered:

Code:
puppy pdev1=sdb1 psubdir=pupsaveC


This resulted in the autoloading of the only 2fs file in the pupsaveC folder (the only such folder on the system), on sdb1. That folder also contains a copy of the standard 139 MB version of lupu_528.sfs. And the reason for the pdev1 entry was to see whether that version would be loaded.

It wasn't. The loader ignored the pdev1 argument, and loaded the libreplus version from sda1/pupsave instead.

I would welcome a correction, but until I see evidence to the contrary, I conclude that the code pdev1=sdxx is entirely useless. Apparently, the puppy loader looks for the first instance of a lupu_528.sfs file, starting with either the boot media or root directory of the first partition of the first hard drive, and loads it. I forgot to test this adequately, but will do so after posting this.

The good news is that one can leave a spare 2fs file or two and a spare sfs file in another directory on a secondary drive, and call is up as needed from the boot command line with nothing more than an appropriate psubdir argument

And possibly when the usual sfs file fails for some reason, the puppy loader will deign to use the next copy in line.

Further update. Several hours more of testing leave me more dumbfounded than ever. My guess as to how the puppy loader selects the sfs file to load proved wrong, and I couldn't make any sense of what actually happend. See my next post below on loading.
otropogo
PostPosted: Fri 04 Jan 2013, 15:59    Post subject:

rerwin wrote:


...

Regarding the date of pet installation, check the modify date (list mode) of the "/root/.packages/*.files" files, which should correspond to when they were installed. Those files list the files that would be uninstalled. If there are also any "remove" (not sure of the exact name format) files, they are the "puninstall" scripts to do additional cleanup upon uninstallation.


Thanks for the further explanation.

Have done as suggested, but the results are a bit puzzling, because of the earliest "modify dates". I haven't found a way to copy and paste this display, other than as a screen save, which I'll try to post here. The earliest dates are for "Packages-Ubuntu-Lucid-xxx, dated April 30, 2010. Is it possible that my 2fs file is that old?

Next come Puppy 5 and Quirky packages dated February and May 2011, followed by a dozen Ubuntu and Puppy packages all dated the same date and time to the second on August 17, 2011.

The first pet install I recognize in the list is xfprot_2.4 on Sept 8, 2011.

This suggest to me that my 2fs file was created on August 17, 2011. But how to explain the prior dates then?

BTW - I had occasion to do a fresh install of lupu_528.005 yesterday on another PC. I ran depmod immediately afterward, but found no listing for the 8191/8192 Realtek module in the network wizard load list (I couldn't test further, since that PC doesn't have a corresponding wifi device). I then tried again, without the existing 2fs file, using the pfix=clean boot command, and then checked the network wizard modules list again. Still no r9191/92 appeared.

I'm not clear on the whether lupu_528.005 is lupu_528 standard or lupu_528 plus, but it appears that the Realtek wifi module was added after its creation.
rerwin
PostPosted: Fri 04 Jan 2013, 14:07    Post subject:

otropogo wrote:

Will try running lsmod later. The drop down menu I referred to is the one presented by hitting the "load module" button in the Puppy Network Wizard gui. The list displays neither 8191 nor 8192 modules, although on my Toshiba, it offers to (and does) install) a working wireless module.

To determine the precise vintage of my regular 2fs file, I'd have to go through my postings for many months. That will take some time. However, I think it's likely it originated with lupu_525, and it's certain that I used 528 patch upgrades, as they're still shown in the petget list of installed pets.

It's too bad petget doesn't display the dates of installation for pets. That would help. I also wish I had uninstalled all of these before going on to newer versions, as I'm a bit antsy about what the uninstallation of an earlier pet might do to the currently installed app. It would make more sense if petget automatically uninstalled the earlier pet for a given application before installing the new one, after taking over the configuration.
otropogo,
I don't know, right now, how that module list is generated, so cannot explain why you module in not listed.

As for your regular pupsave, I am very pleased that you ran the update patch. That removes a lot of possible contaminants.

Regarding uninstallation: That process either removes the installed files or replaces them from the lupu528 SFS file (the original in the distro). If you have multiple versions of a pet installed, uninstallin any of the versons will do that deed, so that any alternate version will be lost. So, if you have the latest pet for a package, I suggest uninstalling each of the versions, then installing the latest. If any of the installed pets are for relevant wifi drivers, uninstalling each of those would eliminate potential conflicts. You could then reinstall the module-pet that works elsewhere, if necessary.

Regarding the date of pet installation, check the modify date (list mode) of the "/root/.packages/*.files" files, which should correspond to when they were installed. Those files list the files that would be uninstalled. If there are also any "remove" (not sure of the exact name format) files, they are the "puninstall" scripts to do additional cleanup upon uninstallation.
otropogo
PostPosted: Wed 02 Jan 2013, 20:21    Post subject:

greengeek wrote:
Good on you both for persisting with this. It looks like some deeper understanding may come from it. I will certainly gain from knowing more about the boot process and pmedia etc commands and how they actually affect the booting. It might help me resolve some of the oddball issues I sometimes have when booting from multi-Pup installs. I've noticed things don't always go quite the way for me that they seem to for others, so it is handy to see tricky issues worked through thoroughly. It is often the exceptions that require the deepest investigation, rather than just persisting with shortcuts that happen to work...


Thanks,

Have wasted most of the afternoon with more experimentation, mostly disastrous, but with a few tidbits of info gleaned.

1. Bootflash install Puppy to USB, which I used to reinstall after my flash card somehow got corrupted, and failed with a simple
Quote:
boot error
message (I recommend locking the SD card except when modifications are needed) requires some tweaking, at least when you use the iso to install. The syslinux.cfg generated consists of only one line, and provides no boot command line.

So I copied all of the boot messages and the isolinux.cfg file from the LiveCD to the flash card, renaming the last syslinux.cfg. This gives you the option of modifying the boot parameters from the command line when the syslinux configuration fails to work.

2. pmedia=atahd psubdir=pupsave is a bit misleading. It displays all lupusave.2fs files found in "pupsave" directories, including any on a flash card.

3. when you load the 528.sfs and the 2fs file from different partitions, both partitions are automatically mounted and neither can be unmounted (this is indicated by the red dot on the desktop icons for both)

4. the source partition for the 2fs file automatically becomes /mnt/home, and can be written and saved to

5. the source partition for the sfs file if different, is no longer found in the normal /mnt/ path. If you click on the desktop icon, you can open it on the desktop, and see that its path is /initrd/mnt/dev_ro2

It's not clear whether you can write to the drive at all under these conditions. I tried to do a Pupsave Hot Backup to the drive, and I couldn't browse to it in the app's gui.

When I entered the path manually in the gui's navigation window, and tried to save a hot backup that way, I got the response:

Quote:
not enough free space


My dev_ro2 (normally sda1 or home) currently has about 90GB of unused space, and the file being saved is only 32MB! So I'd say this configuration spells nothing but trouble for the user. I decided not to risk the data on my hard drive by exploring this mystery.

It would be interesting to know how or why such an arrangement came about. After all, when both sfs and 2fs are loaded from the same partition, that partition is perfectly writable. In fact, most of my saves are to folders in the /mnt/home directory.

The one possibly useful function of loading 2fs and sfs from different partitions is to tell you (if there's any doubt) the location of the sfs file loaded into RAM.
greengeek
PostPosted: Wed 02 Jan 2013, 17:49    Post subject:

Good on you both for persisting with this. It looks like some deeper understanding may come from it. I will certainly gain from knowing more about the boot process and pmedia etc commands and how they actually affect the booting. It might help me resolve some of the oddball issues I sometimes have when booting from multi-Pup installs. I've noticed things don't always go quite the way for me that they seem to for others, so it is handy to see tricky issues worked through thoroughly. It is often the exceptions that require the deepest investigation, rather than just persisting with shortcuts that happen to work...
otropogo
PostPosted: Wed 02 Jan 2013, 16:20    Post subject: Strange behaviour of isolinux.cfg and syslinux config
Subject description: boot line commands behave quite differently in syslinux config

Have just run some tests with various combinations of entries in syslinux.cfg and the boot command line using USBflash, and replicated the strange result posted previously above.

Test 1.

I renamed the syslinux.cfg file on the USB flash card used to boot the system, so that no syslinux.cfg remained.

RESULT: This prevented the PC from booting, and I had to reset. This confirms that the loader must run the syslinux.cfg on the device the BIOS is instructed to boot from.

Test2.

I reinstated the syslinux.cfg file with the final line edited to read
Code:
pmedia=usbflash


RESULT: there was no searching of the hard drives for puppy files, the 528.sfs file was loaded into RAM from the flash card (judging by the delay), and the (only) 2fs file on the flash card was automatically loaded.

Test3.

I booted from the liveCD, whose isolinux.cfg reads pmedia=CD

RESULT: the hard drives were searched, as was the flash card on USB, and all 8 2fs files(from sda1/; sda1/pupsave;sdb1/pusaveB; and sdd1/) were presented for use. The 528.sfs file was loaded into RAM from the hard drive

Test 4.

I revised the final line of syslinux.cfg on the flash card, substituting
Code:
pmedia=atahd
for
Code:
pmedia=usbflash
, then booted from usbflash

RESULT: six 2fs files were presented for loading, those in:

/sdb1/pupsaveB
/sda1/
/sdd1/

But NOT those in sda1/pupsave

This is exactly the mysterious exclusion I described in my previous post.

Test 5

I rebooted without any changes to syslinux.cfg, but at the Puppy boot command line entered:

puppy pdev1=sda1 psubdir=pupsave

RESULT: the two 2fs files in sda1/pupsave were presented for loading.

So why were they skipped when the command was simply
Code:
pmedia=atahd
?

I also wonder why
Code:
pmedia=usbflash
results in no searching for the sfs file or 2fs files on the hard drives, as
Code:
pmedia=CD
does? I can see no benefit from this restriction, only difficulties.
otropogo
PostPosted: Wed 02 Jan 2013, 14:14    Post subject:

[quote="rerwin"]
otropogo wrote:
...

Re #1: I am not sure where you are using a "drop-down menu" unless it is in the boot manager blacklist section. What actually matters, here, is what the lsmod command lists. That would tell us which 8192 module is being used. Finding "8171" (your hardware product ID) in the udevtrace.log would also be interesting -- actually, the entries just before it containing "819". But the depmod seems to have sorted things out.

One other thought: I saw in one of your postings above that you are using a pupsave originally created in an earlier version of Lucid Pup. If that version was not "528", we might have some things to clean up. Lupu528 has significant internal changes to module loading. And lupuplus has even more. I provided a package that prepared older versions for use with 528, to clean out any conflicts. If the original pupsave was pre-528, given that this is your primary pupsave, I am willing to work with you to ensure that it does not contain any residue from the pre-528 lupu. But if the original is from an early 528, that probably is not necessary. Also, if you installed any lupu528 update packages, they could be overriding the lupuplus versions of some files. We can check that out, too.

....


Richard


Thanks for your offer.

Will try running lsmod later. The drop down menu I referred to is the one presented by hitting the "load module" button in the Puppy Network Wizard gui. The list displays neither 8191 nor 8192 modules, although on my Toshiba, it offers to (and does) install) a working wireless module.

To determine the precise vintage of my regular 2fs file, I'd have to go through my postings for many months. That will take some time. However, I think it's likely it originated with lupu_525, and it's certain that I used 528 patch upgrades, as they're still shown in the petget list of installed pets.

It's too bad petget doesn't display the dates of installation for pets. That would help. I also wish I had uninstalled all of these before going on to newer versions, as I'm a bit antsy about what the uninstallation of an earlier pet might do to the currently installed app. It would make more sense if petget automatically uninstalled the earlier pet for a given application before installing the new one, after taking over the configuration.
otropogo
PostPosted: Wed 02 Jan 2013, 13:46    Post subject: Re: how are 2fs files found, and /mnt/home location determined?

ICPUG wrote:
...
I am a bit confused about your drive setup and how many (and where) your sfs and save files are. It seems to have changed from the intial start to the final where you added and then removed a drive. I thought we would be back to start but obviously not!


You would think so, but in fact after removing the third hdd, I had exactly the same sfs and 2fs in the same places as at the start (however, see my note on the syslinux.cfg error below).

Here's the sequence of events.

1. Normal setup used for many months now, syslinux
Code:
pdev1=sda1 psubdir=purpsave


hdd sda1/ contains one barebones 2fs file

hdd sda1/pupsave/ contains lupu_528.sfs, my main 2fs file, and a barebones 2fs file

hdd sdb1/pupsaveB contains lupu_528.sfs and four 2fs files

USB flash SD flash card sdd1/ contains lupu_528.sfs and a barebones 2fs file.

all of the lupu-528.sfs files above are identical.There's an intird.gz and syslinux.cfg file in each directory holding a 528.sfs file. The system is always booted from the usb flash card, and with the normal setup above, presents only the two 2fs files in the sda1/pupsave folder.

2. I added a third hdd which, because of the position of the cable, automatically displaced sda1, which became sdb1. Puppy loader couldn't find 528.sfs and locked up.

3. I booted by changing the boot sequence on the boot command line, and changed pdev1... to pmedia=atahd, expecting the loader to once more offer the 2fs files in sdb1 (formerly sda1). But instead, it presented the 2fs files in sdc1/pupsaveB (formerly sdb1/pupsaveB), one of which has the same name, and is a slightly earlier version of, my main 2fs file. I didn't notice this at once, although a warning was offered by the fact that Seamonkey upgraded to the current version (it had already done so on the 2fs I normally use).

With
Code:
pmedia=atahd
, the puppy bootloader presented the 2fs files in:

sdc1/pupsaveB

and

sdb1/

but NOT the two 2fs files in sdb1/pupsave

It's this omission that puzzles me.

I hesitate to revisit what happened after that, because the most accurate record is what I posted above, and anything I write now from memory is likely to confuse things further.

To add to the issues, I've just discovered an error in the code of the syslinux.cfg file I thought was being used, where I have
Code:
pdeve1=sda1
. I assumed that the bootloading process employed the syslinux.cfg file on the the flash card when booting from USB, but this discovery raises doubts.

I haven't noticed any error messages, so I wonder whether the erroneous argument is just ignored, or the process looks for the next available syslinux.cfg without errors, or that configuration file was never used at all.

The only syslinux.cfg with the correct code sits in the root directory of sda1. Could it be that that's the code that's being run during the boot process?


Quote:
The mechanism for searching has never been FULLY detailed and I only gave a bit of detail about it a long time ago for an earlier version of Puppy. That is now out of date with Puppy 5.2.8.

The code in the init file in the initrd.gz library needs to be analysed and I find it quite difficult to follow in recent pups.


Thanks for your interest. It makes these seemingly futile inquiries seem a little less quixotic. It seems to me that little glitches are piling up in the Puppy code, and even in the kernel, and like mutated DNA, they are gradually building a toxic brew.

For example, one of my recent frustrations with Linux has been that I can't access a 64GB SDXC flash card with it. Windows 7 can handle the hardware, and Knoppix 7.0.4 could handle smaller SDXC cards, but not the 64GB one.

So last night I downloaded and ran the latest Knoppix LiveCD ver. 7.0.5, using kernel 3.6.11. I tried reading the card in a USB3.0 reader I've used successfully with Knoppix to read smaller cards. The flash card would appear under various names, N800, 64GB, sdb1 (this is on a laptop with only one hdd), and then disappear before I could open it.

I gave up on the external reader, and tried the card in the Toshiba's internal SD/XD card slot. There it appeared and I was able to copy the files from the card to the hard drive!

This makes no sense at all, as the Toshiba predates SDXC cards of that size (and perhaps even SDXC itself), whereas the Delkin USB3.0 card reader specifically supports SDXC and UDMA formats. It's also extremely frustrating, because the slot reads the card at a mere 10MB/s, whereas on the USB3.0 port (under Windows7) this card is read at 50MB/s.
rerwin
PostPosted: Wed 02 Jan 2013, 11:42    Post subject:

otropogo wrote:
I was about to go online to post my results, when I thought of trying net wizard one more time, and "presto" wlan0 appeared for the first time.

I checked to be sure that I was indeed running with my main 2fs file - easy to do, as it's the only one that has xfprot installed - and I was. I'll make a hot save after posting this just to be sure (at 1.4GB, it takes a while).

I then proceeded to load the driver without further problems. I couldn't do anything more with it as I have no wifi host within range.

So I'm afraid we may never know with certainty exactly what was wrong, other than the failure to run depmod. IIRC, I did try the net wizard without success after running depmod last night, but possibly without rebooting the system first.

There are two remaining anomalies:

1. - even though the net wizard recognizes the wireless chip now, offers to load the driver for it and apparently does so, I'm still unable to find any 8192 modules (usb or pci) listed in the drop-down menu of available modules. The r8169 module OTOH, which I use for my Realtek ethernet chip, IS listed.

2. - when network wizard offers to install the wireless driver, it refers to it as rtl8191 not 8192, but pfind gets no hits searching "all files" on "8191".
That is very good news!

Re #2: Sometimes the module contains inaccurate/misleading information. Later versions of the 8192 drivers include support for 8191 devices. So that "typo" is understandable.

Re #1: I am not sure where you are using a "drop-down menu" unless it is in the boot manager blacklist section. What actually matters, here, is what the lsmod command lists. That would tell us which 8192 module is being used. Finding "8171" (your hardware product ID) in the udevtrace.log would also be interesting -- actually, the entries just before it containing "819". But the depmod seems to have sorted things out.

One other thought: I saw in one of your postings above that you are using a pupsave originally created in an earlier version of Lucid Pup. If that version was not "528", we might have some things to clean up. Lupu528 has significant internal changes to module loading. And lupuplus has even more. I provided a package that prepared older versions for use with 528, to clean out any conflicts. If the original pupsave was pre-528, given that this is your primary pupsave, I am willing to work with you to ensure that it does not contain any residue from the pre-528 lupu. But if the original is from an early 528, that probably is not necessary. Also, if you installed any lupu528 update packages, they could be overriding the lupuplus versions of some files. We can check that out, too.

BTW, the part of the list you included that shows the modules available -- and no duplications -- is:
Code:
/lib/modules/2.6.33.2/kernel/drivers/net/wireless/8192cu.ko
/lib/modules/2.6.33.2/kernel/drivers/net/wireless/r8192ce_pci.ko
/lib/modules/2.6.33.2/kernel/drivers/net/wireless/r8192se_pci.ko
/lib/modules/2.6.33.2/kernel/drivers/staging/rtl8192e
/lib/modules/2.6.33.2/kernel/drivers/staging/rtl8192e/r8192_pci.ko
/lib/modules/2.6.33.2/kernel/drivers/staging/rtl8192su
/lib/modules/2.6.33.2/kernel/drivers/staging/rtl8192su/r8192s_usb.ko
/lib/modules/2.6.33.2/kernel/drivers/staging/rtl8192u
/lib/modules/2.6.33.2/kernel/drivers/staging/rtl8192u/r8192u_usb.ko

Richard
ICPUG
PostPosted: Wed 02 Jan 2013, 09:07    Post subject: Re: how are 2fs files found, and /mnt/home location determined?

otropogo wrote:
After adding and removing a removable hdd (which became sda1, reshuffling the drive order), and necessarily modifying the linuxsys.cfg file on the usb flash card which I use to boot into Puppy Linux. I rebooted with the new syslinux.cfg, and was surprised by the result.

The last line in the original syslinux.cfg read
Code:
pdev1=sda1 psubdir=pupsave

This would offer only the two lupu-save*.2fs files in the sda1/pupsave folder. And the root directory of sda1 would automatically be named /mnt/home, which is convenient for saving web pages with SMonkey.

When the third hdd was added, and became sda1, this no longer worked, so pdev1... psubdir... was replaced by
Code:
pmedia=atahd
, which allowed me to boot from the renamed sdb1/pupsave.

But after removing the third drive, which changed sdb1 back to sda1, the same
Code:
pmedia=atahd
entry caused only the 2fs files in a pupsaveB folder on sdb1 to be offered, together with a single 2fs file in the root directory of sda1.

The 2fs files sitting in the sda1/pupsave folder were NOT presented.

I didn't notice the path, and simply selected the main 2fs file, unaware that it was on an unusual path. It was only when I tried to save a web page to the /mnt/home directory that I noticed the strange development.

I had always assumed that the linux loader would search the hard drives for the lupu_528.sfs file in ascending hdd order, starting with sda1, and use the first copy it found, then search for 2fs files in the same order, and make the hdd on which the 2fs used is located the /mnt/home directory (ie. automounted, and not unmountable).

Apparently, this is not the case, or pmdia=atahd would have resulted in the 2fs files in sda1/pupsave/ being offered for use.

And so I wonder what the actual mechanism might be?

Can anyone direct me to a comprehensive online explanation of this process and/or explain the situation described above?

I have tried googling this issue, but unfortunately "home" is a word that is commonly found in much more general contexts in Puppy Linux related searches, and I haven't been able to ferret out anything remotely related to the exact search procedure the puppy loader uses when "searching disks for puppy files"


I am a bit confused about your drive setup and how many (and where) your sfs and save files are. It seems to have changed from the intial start to the final where you added and then removed a drive. I thought we would be back to start but obviously not!

The mechanism for searching has never been FULLY detailed and I only gave a bit of detail about it a long time ago for an earlier version of Puppy. That is now out of date with Puppy 5.2.8.

The code in the init file in the initrd.gz library needs to be analysed and I find it quite difficult to follow in recent pups.
Display posts from previous:   Sort by:   
Page 39 of 189 [2830 Posts]   Goto page: Previous 1, 2, 3, ..., 37, 38, 39, 40, 41, ..., 187, 188, 189 Next

Powered by phpBB © 2001, 2005 phpBB Group