SuSE Pro v8.2 installation

[Sylva]

Greetings all:

I am a Windows tech person, but a returnee/newbie in Linux.

In trying to install SuSE's Pro v8.2, I am running into trouble because this version would not circumvent memory bits in error. More precisely, on one of my machines, out of 512MB there are 6 bits in error, 2 which exhibit return errors, the other 4 exhibiting only one error during a whole night's test.

I don't feel like throwing out 512MB of memory because an infinitesimal part is in error. This problem is very nicely gotten around in their v6.3 via the complementary Setup.exe program.

-------------------------------------------------------------------------------
At the very beginning of any choice of installation, after the line: NET4: Unix Domain sockets 1.0/SMP for Linux NET4.0
the following errors occur:

RAMADISK: compressed image found at block 0 invalid compressed format (err-1)<6>Freeing initrd memory:4941K freed
attempt to access beyond end of device 03:04:rw=0, want=2, limit=1
EXT-fs: unable to read superblock attempt to access beyond end of device 03:04: rw=0, want=2, limit=1
MINX-fs: unable to read superblock attempt to access beyond end of device 03:04: rw=0, want=33, limit=1
isofs_read_super: bread failed, dev=03:04, iso-blknum=16, block=32
---------------------------------------------------------------------------------

After the above block of errors, the OS identifies BVENDOR, SVENDOR and it goes into

kernel panic: VFS: unable to mount root fs on 03:04

Do you know of any kernel parameter, patch or some way to get around this problem?

Thanks for the attention,

John

 

[lullysing]

A bar of memory should have 0 errors on it. It's warranty time for that piece of hardware my friend ( you DID buy something else than el cheapo ram, DID you? )...

_____________________________
when someone asks for your username and password, and much *clickely clickely* is happening in the background, know enough that you should be worried.

 

[Sylva]

I am afraid your answers don't help much. If you can't do without flaming don't even answer. I bought the &quot;el cheapo&quot; because I was unemployed. Besides, Widows 2000 does a fine job, my reasons for Linux are purely experimental, see what's all the hype about.

Please answer my questions only if you can stay away from cheap attack.

John.

 

[lullysing]

Don't take this for a flame friend, but no memory stick should have problems, otherwise it WILL mess up exactly when it shouldn't be.

I know i don't trust ram with errors. The &quot;el cheapo&quot; reference is because a lot of people buy cheap &quot;no name brand&quot; ram without warranty, when putting say, 5-10 dollars more per bar gets you some kind of warranty that if the stick is bad, you get it replaced for free.

Dig?

_____________________________
when someone asks for your username and password, and much *clickely clickely* is happening in the background, know enough that you should be worried.

 

[lullysing]

Btw, your error looks like something with the filesystem getting wonky at mount time...you say this happens during INSTALLATION or when you boot the INSTALLED system?

_____________________________
when someone asks for your username and password, and much *clickely clickely* is happening in the background, know enough that you should be worried.

 

[Sylva]

No problem, lullysing, just that there are lots of people out there with all kinds of problems. It's the times we're living under, I guess.

The problems occur at installation time. Linux doesn't even give a chance to get to the file system. It goes into kernel panic right after it sets up the ramdisk. It says it cannot get past the 4941kb allocated for device 03:04. Is it that it may be talking about the ramdisk that was set up as a device? This would make sense, since a disk is a device.

Thanks for your input, John.

PS. When one is unemployed the difference counts a whole lot. I bought the memory for $36, but the tested memory was more than double that amount. It's obvious what the choice will be for an unemployed person, especially that Windows 2000 server was the target OS, not Unix/Linux. Win 2000 is far more lenient, especially if one uses it for a learning home environment.

 

[lullysing]

I'm pretty sure it has to do with the defective ram. If during instalation the system makes a ramdisk and stuffs the linux filesystem on it( and on the buggy parts of it) then yes, it's gonna be problematic.

Try swapping the memory from another box you have just as a test.

--Dave

_____________________________
when someone asks for your username and password, and much *clickely clickely* is happening in the background, know enough that you should be worried.

 

[Sylva]

That's exactly what I have done, but no cigar. The other RAMs were faulty as well. Remember though, it's only 6, (that is, six) bits out of 4,096,000,000 that are at fault, so circumventing them shouldn't be all that hard. This is why I am looking for some software workaround, such as inserting values into variables at installation time. After more investigation I found that there were patches out there and also some functions, such as MEM that should help. I haven't had the time to try them yet. In essence, I'll have to again do thorough RAM testing (which SuSE 8.2 does do) and jot down the faulty addresses to be entered into the patch/function (whichever applies) at installation time. It will also be good exercise and food for thought to gain more knowledge. If something works, I'll definitely communicate.

John.

 

[flugh]

Try this page yet:

http://rick.vanrein.org/linux/badram/

I think this is what you are looking for. If I understand this correctly, the patch causes the kernel to test all of RAM during boot. If it finds bad RAM, it marks it as bad, and then allocates it to itself so that no programs can try to access it and cause crashes/kernel panics/the sky to fall. It's a pretty crafty way to save having to replace some funky RAM

----
JBR

 

[Sylva]

Yes, flugh, I have it, just haven't had the time to take to it. Simon Urbanik from the U of Augsburg says that if the faulty locations are known, they can be fed to the mem variable at installation time as kernel parameters, which will mask those faulty bits. So there are some possibilities. Then, I took a look at the book that came from my old SuSE v6.3, where these things are documented, but stuck into the kernel parms chapter and not really explained what they can be used for. Newbies, like me, will not get the hang of it because of lack of experience and knowledge. Thanks for the input. As I said, I'll keep you all posted about the results, but it'll need time


John.