meauto segfaulting suddenly in simply mepis 2004.02
This is an all the sudden thing. I rebooted to my windows partition to do something in windows I rebooted to Linux and now meauto which has worked since I installed Simply Mpeis 2004.02 now segfaults when run. Again this is an all of the sudden thing and I did not change or touch it.
I have a p4 I built myself and again Mepis is great ot detected my hardware installed all my drivers no problem.
Intel board, Nvidia vagp cagr, cmi-pci (pci) sound card, 3com pci nic card, etc. etc.
I am waiting to upgrade to .03 when it hits the mepis Debian pool.
So all my pci devices are now being recognised manualy by me adding them to modules with a helkp of a friend.
So when?? I run meauto directly froma command promt as root, I get this:
root@0[sbin]# /sbin/meauto
Running meauto for MEPIS Linux (C) 2003-4, MEPIS LLC...
??Finding pci devices...
Segmentation fault
No further information available.
Again this is all the sudden, it was fine when I shut it down to reboot into windows. This was like less than 24 hours ago.
Any help or sugestions would be apreciated.
thanks in adavnce for thos that reply.
Figured this out. Please read.
Aparently, there is a bug in meauto whcih makes the latest version of hwdata incompatable with meauto and makes it segfault. The unfortiante thing is that no one caught it and the the latest hwdata wen't from the Debian unstable pool to testing. Aparently Mepis is aware of this and is trying to fix. In the mean time someone made a solution on mepislovers website that worked. If you get the dev mailings, it was posted there as well. Basicaly you revert back to a previous version of hwdata and add a line to apt-get prefrences so that apt-get update and upgrade won't try to upgrade to the new version of hwdata again. Just go to mepislovers.com and look it up in the forum there. Again this is a temporary fix, but it works. I found out by checking my dev mailings for the day as I am on the mailing list here.
Thanks to those who would have replied and helped, and probably pointed me to this anyway.
Grak
I posted about it on this site too
http://www.mepis.org/node/view/3762 plus I posted about it here, at mepislovers and on the dev mailing list before hwdata got moved to the debian testing repository, way back. It was a problem I found because I changed my apt sources to upgrade from unstable instead of testing and when I found out that this unstable version of hwdata messed up meauto, I posted about it. Now it is a problem for all users and not just the ones that are running unstable for their upgrading.
I wonder if Warren can put th
I wonder if Warren can put the working hwdata in Mepis repository with a wrong version (larger number than the one in Debian pool) so when people upgrade because of their pinning they would still get the working version. This would only be a hack till he finds a better solution.
yes there needs to be a perminat fix
I think this is not a major priority for the dev team as the fix that is available works well and most people can easily aply it, but it is on the dev teams list of things to look at and fix.
The fix is now listed here in the enws part of this forum under meauto not jsuts at mepislovers or whatever.
The fix works?? beautifly and manipulates apt well.
It should be their priority i
It should be their priority in my opinion
To know that you have to apply the fix you have either to stay current with the discussions on the forum or get burned and come here for help, this is not good enough from a distro that wants to be considered user-firendly and targets new Linux users.
Read the post at this link about hwdata fix!
Warren fixed hwdata
Cool. So I guess he had the s
Cool. So I guess he had the same idea...
I ran gdb on meauto and this is the output. for debugging.
Meybe this can help anybody out there help me fix this. Again this an all of the sudden thing.
Running meauto for MEPIS Linux (C) 2003-4, MEPIS LLC...
Detaching after fork from child process 3211.
??Finding pci devices...
Detaching after fork from child process 3212.
Detaching after fork from child process 3214.
Detaching after fork from child process 3217.
Program received signal SIGSEGV, Segmentation fault.
0x410933d0 in strcpy () from /lib/tls/libc.so.6
Thanks again for those that help and reply.