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 Fri 25 Jul 2014, 09:44
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Lucid Puppy 5.2.8 - Updated ISO Version 005 - APR 05 2012
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 150 of 189 [2827 Posts]   Goto page: Previous 1, 2, 3, ..., 148, 149, 150, 151, 152, ..., 187, 188, 189 Next
Author Message
otropogo


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

PostPosted: Mon 31 Dec 2012, 13:59    Post subject:  

rerwin wrote:
otropogo,
Thanks for the clarification. When assuming you had copied the module, I also assumed you had run depmod, so that it shows up in modules.alias. Now, it sounds, to me, that maybe you have not run depmod in the regular pupsave. At least that would explain what we see -- or don't see.
Richard


No. I don't recall running depmod under any combination of PC and 2fs. Pdiag is the only line command I've run on either PC during this discussion.

(On my desktop) I've just typed "depmod" in a ROX terminal, and absolutely nothing happens.

Quote:
sh-4.1# depmod
sh-4.1#


I

_________________
otropogo@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
sheldonisaac

Joined: 21 Jun 2009
Posts: 395
Location: Philadelphia, PA

PostPosted: Mon 31 Dec 2012, 14:37    Post subject:
Subject description: module stuff
 

otropogo wrote:

No. I don't recall running depmod under any combination of PC and 2fs. Pdiag is the only line command I've run on either PC during this discussion.I
otropogo, much of what you and Richard have been discussing is beyond me.

However, it seems that if one types

depmod --help

it gives some guidance?

For example, depmod -an | more

gives huge screenfuls of info.

Hopefully, some more knowledgable person will speak up.
Back to top
View user's profile Send private message 
otropogo


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

PostPosted: Mon 31 Dec 2012, 14:52    Post subject: how are 2fs files found, and /mnt/home location determined?  

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"

_________________
otropogo@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
otropogo


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

PostPosted: Mon 31 Dec 2012, 15:51    Post subject:
Subject description: module stuff
 

sheldonisaac wrote:
otropogo wrote:

No. I don't recall running depmod under any combination of PC and 2fs. Pdiag is the only line command I've run on either PC during this discussion.I
otropogo, much of what you and Richard have been discussing is beyond me.

However, it seems that if one types

depmod --help

it gives some guidance?

For example, depmod -an | more

gives huge screenfuls of info.

Hopefully, some more knowledgable person will speak up.


Hi sheldonisaac,

Thanks for your suggestion. I looked at the help menu, but didn't find it very enlightening.

The most promising arguments, -a, -A, -m, displayed nothing. The "verbose" argument generated a huge list, but a search on "8192" turned up 0 hits.

The "warning" list generated by
Code:
depmod  -w
has the following reference to the usb version of the Realtek wifi chip, although it, like the 8192se pci version, fails to appear in the connection wizard modules list on this system.

Quote:
usb:v07B8p8178d*dc*dsc*dp*ic*isc*ip* 8192cu
WARNING: duplicate module alias:
usb:v0BDAp8177d*dc*dsc*dp*ic*isc*ip* 8192cu
WARNING: duplicate module alias:


But there's no reference to the pci module.

the -n argument has several lines referencing the 8192 usb module, but again, none for the pci version. As far as I can tell, the output of your -an argument is the same. I copied, pasted, and searched that too, and found only the same 8192 usb module referenced.

There are certainly huge screenfuls of text generated, but the informational content,relative to my problem, eludes me.

_________________
otropogo@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
kevin bowers

Joined: 20 Dec 2009
Posts: 143

PostPosted: Mon 31 Dec 2012, 17:16    Post subject:  

fecklesslout wrote:
Hi all,
I'm new to Linux and am trying to salvage data on a dying SSD in my PC. The PC has three other HDDs in it, of which all are functioning fine. I've tried installing Lucid Puppy from a CD but it goes to a black screen. I've restarted and tried puppy pfix=nox and xorgwizard. No matter what I select at xorgwizard it takes me to a black screen (including vesa). I've tried puppy acpi=noirq and puppy acpi=strict. Nothing is working.

Can someone please help me troubleshoot this?
The PC is a Intel core i5 2500k, with nVidia GTX 570. Let me know if there's any more information you need.


First, you don't need to install Puppy at all to use it for data salvage; simply boot to CD and copy whatever data to one of your functioning drives, or burn it to another blank CD.

Unless what you meant is that you can't boot to CD either? That's actually quite different than installing. If that is the case, several things you could try:

boot: puppy pfix=ram vesa

try a different Puppy, maybe Slacko? I'm typing this on a core i5 system in Slacko 5.4-PAE.

BTW will the system boot Windows or any other OS?

If your motherboard has the circuitry to make use of the graphics chip in the processor, try pulling the graphics card out and connecting the monitor straight to the MB. Or if you have another graphics card laying around try it.

Maybe one of the big distros will have more graphics drivers than any Puppy, perhaps try Ubuntu? It will run as a live CD, that is you don't necessarily need to install it, just boot the CD.

Good luck!

P.S. @Playdayz, you are sorely missed! Luck, life & love to you and yours.
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1501
Location: Maine, USA

PostPosted: Mon 31 Dec 2012, 17:44    Post subject:  

otropogo,
Quote:
(On my desktop) I've just typed "depmod" in a ROX terminal, and absolutely nothing happens.

Quote:
sh-4.1# depmod
sh-4.1#
What you see is what I expect. If you check the properties of /lib/modules/2.6.33.2/modules.alias, you should see that the "modified" date is the time you ran depmod. Depmod simply examines all of the modules in /lib/modules/2.6.33.2 and lists the alias lines for each, in modules.alias, to establish the appropriate module for each device hardware ID. So, that needs to be run any time the mix of modules is changed. That would be the case if you use a regular-lupu pupsave with lupuplus*. Now, try your test on the "depmodded" pupsave setup.

About those warnings: I infer from them that either the module 8192cu contains the duplicate entries or that there are multiple copies of it in different places within the /lib/modules/2.6.33.2 directory.

If the depmod does not solve the problem, please look at /initrd/pup_rw/lib/modules/2.6.33.2 for any "8192" modules that might interfere with the lupuplus modules. If you find any, please delete them or move them outside of /lib/modules/2.6.33.2/.

Beyond those thoughts, I think I am out of ideas. I am not going to try to keep up with the drive-swapping activities.
Richard
Back to top
View user's profile Send private message 
otropogo


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

PostPosted: Tue 01 Jan 2013, 03:13    Post subject:  

rerwin wrote:
otropogo,
Quote:
(On my desktop) I've just typed "depmod" in a ROX terminal, and absolutely nothing happens.

Quote:
sh-4.1# depmod
sh-4.1#
What you see is what I expect. If you check the properties of /lib/modules/2.6.33.2/modules.alias, you should see that the "modified" date is the time you ran depmod. Depmod simply examines all of the modules in /lib/modules/2.6.33.2 and lists the alias lines for each, in modules.alias, to establish the appropriate module for each device hardware ID. So, that needs to be run any time the mix of modules is changed. That would be the case if you use a regular-lupu pupsave with lupuplus*. Now, try your test on the "depmodded" pupsave setup.


Hi Richard,

Afraid I don't understand your instructions this time. You seem to suggest that running depmod (ie. typing the term and hitting CR in a terminal) will update my older 2fs file and make the wireless module perform as expected.

If so, it had no effect. There is still no module available for loading, and no mention of the r8192_pci module in udev.trace.


Quote:
About those warnings: I infer from them that either the module 8192cu contains the duplicate entries or that there are multiple copies of it in different places within the /lib/modules/2.6.33.2 directory.

If the depmod does not solve the problem, please look at /initrd/pup_rw/lib/modules/2.6.33.2 for any "8192" modules that might interfere with the lupuplus modules. If you find any, please delete them or move them outside of /lib/modules/2.6.33.2/.


Have looked at /initrd/pup_re/lib/modules/2.6.33.2 but don't see any modules there. The folder contains three bin files, modules.alias.bin, modules.dep.bin, and modules.symbols.bin. There are a number of text files, and two further folders, intrd and kernel, that do contain some modules further on. But nothing named "8192".


Quote:
Beyond those thoughts, I think I am out of ideas. I am not going to try to keep up with the drive-swapping activities.
Richard


Well. Thanks for your efforts. I should be used to running into dead ends with Puppy after so many years of it. And I fully understand your reluctance to embark on yet another probably futile quest to unravel its workings.

As with the disappearing wireless module question, I was hoping someone just happened to know how the puppy bootloader's program is structured to search for puppy files.

Not being able to predict except by trial and error how to use the boot commands except by trial and error is a trivial inconvenience compared to having one's wi-fi capability inexplicably nullified. But it should also be a much easier matter to clarify, since anyone with more than one drive can easily replicate the problem.

_________________
otropogo@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
fecklesslout

Joined: 30 Dec 2012
Posts: 2

PostPosted: Tue 01 Jan 2013, 07:04    Post subject:  

kevin bowers wrote:

First, you don't need to install Puppy at all to use it for data salvage; simply boot to CD and copy whatever data to one of your functioning drives, or burn it to another blank CD.

Unless what you meant is that you can't boot to CD either? That's actually quite different than installing. If that is the case, several things you could try:

boot: puppy pfix=ram vesa

try a different Puppy, maybe Slacko? I'm typing this on a core i5 system in Slacko 5.4-PAE.

BTW will the system boot Windows or any other OS?

If your motherboard has the circuitry to make use of the graphics chip in the processor, try pulling the graphics card out and connecting the monitor straight to the MB. Or if you have another graphics card laying around try it.

Maybe one of the big distros will have more graphics drivers than any Puppy, perhaps try Ubuntu? It will run as a live CD, that is you don't necessarily need to install it, just boot the CD.

Good luck!

P.S. @Playdayz, you are sorely missed! Luck, life & love to you and yours.

Yeah, sorry I didn't mean install, just boot from the CD. Keep getting the black screen. Tried your ram vesa suggestion and same result, black screen.

I'll give ubuntu a try and see how I go, thanks for your help Kevin!

System won't boot OS as the drive that failed is the one with the OS on it.
Back to top
View user's profile Send private message 
rerwin


Joined: 24 Aug 2005
Posts: 1501
Location: Maine, USA

PostPosted: Tue 01 Jan 2013, 12:09    Post subject:  

otropogo,
Quote:
Have looked at /initrd/pup_re/lib/modules/2.6.33.2 but don't see any modules there. The folder contains three bin files, modules.alias.bin, modules.dep.bin, and modules.symbols.bin. There are a number of text files, and two further folders, intrd and kernel, that do contain some modules further on. But nothing named "8192".
That is good info. Please look at the /initrd/pup_rw/lib/modules/2.6.33.2/ directory in line mode so you can see the "modify dates". Does the modules.alias.bin date match the modules.alias date? If they do not match or there is no modules.alias file, then that would be the problem. Also, the dates should be of the last time you ran depmod -- yesterday, I assume.

Note that when both of the modules.alias(.bin) files are present, the bin file will prevail. The busybox version of depmod does not update the .bin file, so that the modules.alias file may not be accurate as to what really happens. It appears that the lupuplus puppy does not use the busybox version, although it may still be used during bootup.

Another thing to check: Run pfind for the module in question to verify it is present. Or just look for "8192" to see what versions are present.

Since I am not sure, beyond that, what I am looking for, please reconsider sending me a PM with a pdiag file taken on your regular pupsave that is not performing. Use the latest version of pdiag, to omit the sensitive files. (Pemasu assures me that SNS encrypts the key information, wherever it is kept.)
Richard
Back to top
View user's profile Send private message 
otropogo


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

PostPosted: Tue 01 Jan 2013, 21:02    Post subject:  

rerwin wrote:
otropogo,
Quote:
Have looked at /initrd/pup_re/lib/modules/2.6.33.2 but don't see any modules there. The folder contains three bin files, modules.alias.bin, modules.dep.bin, and modules.symbols.bin. There are a number of text files, and two further folders, intrd and kernel, that do contain some modules further on. But nothing named "8192".
That is good info. Please look at the /initrd/pup_rw/lib/modules/2.6.33.2/ directory in line mode so you can see the "modify dates". Does the modules.alias.bin date match the modules.alias date? If they do not match or there is no modules.alias file, then that would be the problem. Also, the dates should be of the last time you ran depmod -- yesterday, I assume.

Note that when both of the modules.alias(.bin) files are present, the bin file will prevail. The busybox version of depmod does not update the .bin file, so that the modules.alias file may not be accurate as to what really happens. It appears that the lupuplus puppy does not use the busybox version, although it may still be used during bootup.

Another thing to check: Run pfind for the module in question to verify it is present. Or just look for "8192" to see what versions are present.

Richard


...

I don't know whether to laugh or cry.

I checked the date/time stamps of modules.alias and modules.alias.bin, and they're identical.

Then I had pfind search for "8192" in "all files", and got the following list.

Quote:
/etc/ndiswrapper/net8192se
/etc/ndiswrapper/net8192se/net8192se.inf
/lib/firmware/RTL8192CE
/lib/firmware/RTL8192CE/rtl8192cfw.bin
/lib/firmware/RTL8192CE/rtl8192cfw_test.bin
/lib/firmware/RTL8192SE
/lib/firmware/RTL8192SE/rtl8192sfw492.bin
/lib/firmware/RTL8192SE/rtl8192sfw74.bin
/lib/firmware/RTL8192SE/rtl8192sfw.bin
/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
/lib/modules/all-firmware/rtl8188_8192su.tar.gz
/sys/module/cfg80211/holders/r8192se_pci
/sys/module/r8192se_pci


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"

Thanks again for your help. And happy new year!

_________________
otropogo@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
ICPUG

Joined: 24 Jul 2005
Posts: 1289
Location: UK

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


Joined: 24 Aug 2005
Posts: 1501
Location: Maine, USA

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


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

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.

_________________
otropogo@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
otropogo


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

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@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
otropogo


Joined: 24 Oct 2009
Posts: 702
Location: Southern Rocky Mt. Trench

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@gmail.com facebook.com/otropogo
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 150 of 189 [2827 Posts]   Goto page: Previous 1, 2, 3, ..., 148, 149, 150, 151, 152, ..., 187, 188, 189 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
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.2216s ][ Queries: 13 (0.0439s) ][ GZIP on ]