Puppy Linux Discussion Forum

[gerry]

Tried both 8139cp and 8139too. Both failed with a message roughly as:

Could not open /lib/modules/2.6.27.7/kernel/drivers/net/mii.ko: no such file or directory

EDIT: another afterthought: when I did the grep for eth0, I did it on the "official" 412. When I did it on Slaxer, it returned nothing.

Gerry

[big_bass]

Sit Heel Speak

thanks for testing

I dont see how the MBR was over written

Slackware always uses lilo
puppy using grub

the kernel has nothing to to with the installer

I always hand edit my lilo.conf

[gerry]

big_bass: found the problem.

/lib/modules/2.6.27.7/kernel/drivers/ is a very bare cupboard, with hardly anything in it- certainly no drivers.

Is your pup-412.sfs the same as the "official" one? That will be why I was not asked if I wanted to save the .sfs file to hd after I'd done the pupsave: there's one there already.

Gerry

[big_bass]

gerry


the sfs has the same name as the original 4.12

I pulled it anyway


since there was not a positive post

if you do get it working please
post

I would like to know what was happening
since everything is working for me

thaks for testing


looks like I'll have to rename the sfs

so it doest conflict
and load the old 4.12 settings
since I only have one sfs that may be whats happening


big_bass

[gerry]

That's a pity- it's an exciting idea! And the POWEROFF does work- first time for a Puppy live cd on my old machine.

Gerry

[big_bass]

gerry I havent given up I will rename all the files

to read 512 instead of 412


so it will be pup_512 soon Slaxer_Pup 512

that will keep the setup from clashing
with the other pup_sfs

because they are very different sfs
and I believe thats the problem


big_bass

[gerry]

Someone else might need 512 for an official release one day. Why not BB412 or something? Or s412? pup-slx412.sfs?


Gerry

[big_bass]

you guys had me worried

gerry 512 is mine now I called it first
so I am on a shinny new duo core sony vaio laptop

for some tests and I do believe its an error with conflicting sfs names

since I had no problem booting installing and reading the new save


anyway I should use a different sfs name to avoid those problems



I feel relieved and will modify the files inside the initrd and in ithe sfs

a big thanks for testing

here is the hardinfo report
and the bootkernellog from this sony

big_bass

[puppyiso]

After posting questions last night(Beijing time), I tried to download the puppy this morning but it's gone.



I saw you saying pulling it out for now but thought that's still there in asia site.



Whenever you've done with fixing, please re-upload so I can try out.



In the meantime, I will try smp enabled G_Pup.

[aragon]

hi big_bass,

to complete the error-report:

1. Tested again with xvesa
- first boot pfix=ram works fine
- reboot
- save-file on hd (vfat), copy pup_412.sfs to hd
- 2nd boot went ok to desktop but does not find much application... (see xeers.log in attached zip)

2. Tested again with xorg
- first boot pfix=ram works fine
- reboot
- save-file on hd (vfat), copy pup_412.sfs to hd
- 2nd boot same result xorg drops to console. xorgwizard does not help, startx ....
- tested xorgwizard with xvesa, desktop loads but missing apps (see above)

attached you'll find a zip with some log-files, maybe they help.

Could it be a problem of the layered filesystem? The missing applications on 2nd boot let me think of that...

if you need more infos, let me know.

aragon

[MU]

the agpbus driver makes problems.
var-log-Xorg.0.log:

[aragon]

The problem sits in front of the screen!

So i'm reading it in this thread, i'm reading it in the 4.2-smp-thread....

i was getting mad with the fault, i always cleaned the dir of the safefile (topdir of the hd) to do nothing wrong. started new pfix=ram...

than i followed mu's instructions the modprobe gave an error. thought i investigate it a little more as an lsmod before gave me a loaded agpgart.

so go to /lib/modules. what's that? am i on a magical mystery tour?

folder 1. => 2.6.25.15
folder 2 => 2.6.27.7

so back to my harddrive? what's that? a subfolder with a backup of my pendrive? and yes, you're right, there's a pup_412.sfs!!!

after renaming that, sure everything works after reboot!!

So please big_bass (and MU) accept my deepest excuse, i feel like the moron of the day!

the ashamed
aragon

[MU]

hehe, yes, that is a common trap.

Unfortunately, it is not trivial, to use an own naming convention.
In Muppy, I used "msy_301.sfs" instead of pup_301.sfs.
But this required to modify several scripts, not only init, but also other places like Puppyinstaller.

So I would suggest, that big_bass stays with pup_412.sfs.
It would take too much time, to add such patches, and might be discouraging, to track down bugs because of overseen occurences.

A general solution is to use Puppys ability to place files in a subfolder.
In grub, I start around 20 different versions of Puppy like this:

[aragon]

Hi Mark,

for my normal installs i also use the grub-approach with subdirs. For testing i normally use a live-cd or simply copy the needed files to an usb-stick. but as i'm using the one usbstick for compiling and the other one for testing 4.2-smp...

another question: as puppy could read/load the 'wrong' files, wouldn't it be the easiest way to test for concurrent pup-files, and give a message like

[big_bass]

aragon



Thank you for testing


I am happy you discovered what was happening

building anything then uploading your work is a big responsibility
if I detect that there is a problem I would rather suffer the
defeat then cause damage to someones computer

this is the reason I pulled the ISO so quickly
even though I tested and built very carefully
and was sure of my work ready to upload

I believe that from a technical point what was won
far outweighs the losses

after the error reports
I did edit the init in areas where modules were called but already loaded in the kernel so you wont get those errors

thats a positive
I also checked if there were "else" commands if modules werent loaded

this was simple thing and I made notes in the initrd.gz in a text file
so it would be easy to locate with the line numbers

I like to keep things simple nothing fancy

a big thanks to you Mark also


changing 412 to 512 is much easier than changing the 'pup' prefix
I have no urge to play with that now or later

good news is now some more testing and I can add
that to the new iso

please please report the good and the bad
so my next upload has the corrections
I dont take technical problems personally

big_bass