Snap 4100 confusion

[djC]

Greetings to everybody and wishing a PRO-COOL 2006!

This is my first post here, so I'd like to point out that it's *PACKED* with great info and help! Keep up the good work everyone and hopefully I can add to that!

Here's my question to anyone who could help:
I recently ended up (lucky man) with a Dell 705 (aka Snapserver 4100, as I learned here), a pull from a friends company serverroom, I just paid 100 euros for it!

Now, it is a 160GB model, but -as most of you here- wanted to upgrade the disks and -preferably to >137GB ones. So, I got myself 4x250GB (WD2500), ATA100 disks, which are currently seen by the system as ~128GB each.

I read every single relevant post in this forum, which allowed me to transform the Dell to a SnapAppliance and upgrade to SnapOS 4.3.830 (was 3.4.790), but -as correctly stated again in the forum- this version will STILL not allow setting of the 48lba bit.

And here goes my confusion regarding the 4100:
-Does the newer version (4.8.890) finally allow the setting of the 48lba bit ?
-Does the earlier "disappeared" version 3.4.805 allow the setting of 48lba bit ?
-Other than supporting Windows 2003, are there any more major differences between the two versions?

Is there someone who can get me access to get and test these versions?

Thx everyone in advance for your time!

[kogvos]

Hi there,

There are a lot of people on here who know a great deal more about these things than I do so what I'm going to say will probably be corrected as the thread progresses.

Unfortunately you are stuck with 128MB on each disk regardless of the software version. I bought a 120G model a little while ago without discs and put 4 x 160GB drives in it and I can only get that despite running the latest software on it. It seems to be that the Promise IDE controllers are not set to allow large drives although the chips themselves do support it.

I've just upgraded the RAM in it to 256MB because the standard 64MB stick woud not allow the creation of a RAID5 array and althogh it had been working OK in a mirrored arrangement, recently it went into a kernel panic and corrupted all the data.

Others have recommended a Kingston PC100 RAM stick as the machine only uses PC100 however low profile PC100 seems very expensive now. I managed to get a 256MB PC133 stick very cheaply - KVR133X72C3L/256. Its ECC RAM but the Snap doesn't care about that.

Overall, I think the earlier model - the 4000 - is much more flexible since it is a 2RU design it can use standard height RAM and it can access 300GB or more on each disk.

Regards,

Jamie

[blue68f100]

Upgrading to large HD is a function of the HW, BIOS and OS versions. Check your BIOS and HW and see if it is greater than v2. If so v4 OS will use LBA48. I have helped many with up this upgrade. Most are suscessful if these requirments are meet on a 4100, not so on 4000.

[djC]

Thanks for your replies guys.

blue68f100,
I just checked on the info you mentioned:
SW: 4.0.860
HW: 2.2.1
BIOS: 2.4.437

Although I do have a >2 BIOS and HW version, as far as LBA48 is concerned, the reply I get when I connect the WD 2500 (250GB) and run the "info log T" command on the debug page, is:

01/10/2006 0:37:22 24 D SYS | IDE: A 48 bit LBA capable Hard Drive was detected ...
01/10/2006 0:37:22 24 D SYS | IDE: 48 bit LBA is not supported on 4100 and 12000 platforms.
01/10/2006 0:37:22 24 D SYS | IDE: Setting the hard drive size to maximum addressable by 28 bits: 131071 MBytes.

I wonder...
...if I downgraded to 3.4.805, would I get the LBA48 thing to work, what do you think?

...any other suggestions?


kogvos,
thanks for the RAM tip, I am looking into it right away :-)

[blue68f100]

This has been a problem with some of the 4100's.

Some have worked around it, by issuing a lba48 reset.
This general procedure is that the server must be in JBOD (individual) configuration.

Copy the OS from your current master drive to the new drive (250 gig).
Remove all drives that are not 250 gig. ( 1 single drive is good)
Boot from the 250 gig drive.
Issue ide 48bitLBACounter reset from debug
then co de format 10000 /reinit
reboot, the drive will be reformatted on restart.
then check to see if you see 230 gig of drive space.
use ide 48bitLBACounter get to check the results 0=failure

Rumors have it that 3.4.805 was release with 48bit enabled, but was quickly pulled by SnapAppliance. They did not want the older units to handle the large HD, killing off customers from upgrading to newer versions.

When you did the upgrade to 120's did you just install the drives and the snap did the setup. This means that the OS is stored in flashram. Which means the OS can not be backed out. The 4000 is this way but I think the 4100 uses a boot loaded to load from the HD. If it uses a boot loaded the OS can be reloaded.

[djC]

OK, here are some interesting (freaky, though -read on) developments in this quest for storage space:

I was just about to go over the cloning of disk 1 (10000) of the 4100, in order to get the OS on to the 250GB disk, when I decided I should test whether the appliance would boot without ANY disks. If it did, it would mean that the OS is not on any of the HDDs.

Indeed, after removing all ATA cables, and turning on the 4100, the appliance took some time (checking the absence of the disks, I suppose) and booted normally.

Then I turned it off, connected a single 250GB and turned it back on. Indeed, after some time, there it was, a 137GB disk 1. Hmmm, I thought, let's put the original back there. Again, there it was, a single 40GB disk 1.

I concluded that probably the trick with imaging the original disk simply would not work, as the behaviour of the appliance was the same, regardless of the disk connected.

Than it came to me, that the only thing that had a chance to make it work is to fool the OS (since it's common between 4000s and 4100s) to think that this is a 4000.

I was wondering how to do that and did -again- some reading on other people's (with 4000s) posts on this forum. An interesting finding was that ALL 4000s I came across had a HW version of 2.0.1, whereas all 4100s I came across had a HW version of 2.2.1.

Being curious by nature I decided to change the HW version, by issuing the following commands, knowing that this could render the 4100 useless:

bios unlock
bios platformbytes 2 0 1
bios lock

Indeed, the commands executed without error, and after that, clicking on the snapappliance icon displayed the new version!

Here is the interesting (and freaky) part:
I had to go all over the procedure of reinitialising disk 1 (10000) again, now that I had changed the HW version.

So, I rebooted the server....

IT WOULDN'T boot!

I tried reseting the appliance totally: Nothing.
I tried connecting the original disk 1: Nothing (this probably also indicates that there is no OS on it).
I also tried connecting disk 1 on the extra IDE port (probably there for maintenance and repair purposes) that 4100s have. Nothing.
I also rebooted my router/DHCP server and rescanned my network for clients and the appliance is simply not there.

On the front bezel two LEDs light up: the System LED flashes twice every minute and the Link LED stays on (normal, as the net cable is connected).

My thoughts are now...

- As mentioned, the 4000s boot from disk 1.
- IF, indeed, I made the appliance think it's a 4000, it is normal that it cannot boot, as it looks for the OS somewhere it does not exist (original disk 1).
- My changing of the HW version, must have no impact on normal operation, as the appliance did react normally AFTER the change, but BEFORE rebooting (which is because the OS was still in the appliance's memory).
- if I load an image of the OS into disk 1, I could probably make it boot and then check its status

My wild guess here is that, if I manage to boot using an on-disk image from a 4000 (with OS v4 on it), eventually I will have fooled the appliance to think that it is a 4000 and format the large disks in full capacity.

Otherwise... I have a 4100 m/b to hang on the wall and four 40GB disks to spare!

If all this works, I think we may have found the solution into turning stuborn 4100s to TB-stations!

Question is.... is there anybody in here to provide me with such an image???

[blue68f100]

There has been many a Snap Server that have become door stops by change the HW config. Generally it locks in update mode looking for the IP and downloads OS or firmware. With no way to recover from it. Most are done on a 1000 trying to make it work as a 2000, to get RAID.

If you had taken the time to read Hack a Snap 1000, you would had discovered you had to change it back before it rebooted.

Your only hope is multiple resets to factory, with a bootable drive in place. Watch the lights. If you need a document explaining the blinking LED lights let me know.

The Snap 4000, 4100 1000v1, 2000 all store the OS in flashram. The newer models use a standard boot loader.

Good luck.

[djC]

Here I am again!

A short update:

As I had left the 4100 turned on for quite some time (over 40mins) and the Assist utility running (and scanning), at some point it located the snapserver, of course with completely reset settings.

I immediatelly tried the "recipe" you provided, but unfortunatelly it didn't work.
I kept getting the message "Pseudoflash not found" and when executing "co de info" I received a "no disks " message. I tried the image on both a 250GB and an original 40GB disk, but no luck.

Note here that everytime the server rebooted, I had to wait for over 40mins to get Assist to locate it.

After trying to make it locate the OS on the disk for several times, I gave up and changed the platformbytes back to 2.2.1. After a reboot, server worked properly (of course no 48bit lba).

I don't have any other ideas, maybe another combination of platformbytes and model would work, any suggestions are welcome.

In any case thank you very much blue68f100 for your replies and help!

[blue68f100]

There was one post refering to a specific Promise controller chip. He said that there was a bug in the chip that did not allow 48LBA to work correctly. I was helping one other user that had the same grave problems in trying to get his 4100 to accept large disk. He had an array set (raid5) with one spare. The array consited of 3 40gig and a 300gig spare. The init cmd on the 300 kept yielding 137 gig. He did not tell me that the unit was set to raid5. I fould out when he sent me the info ablut the drives showing the 137 gig dirve. What I had him do was remove the raid back to JBOD (individual) disk. Reboot, Verify JBOD. Remove all execpt the 300 in master. Rebooted, reset to factory, reboot again. Issue the format /reinit cmd. He had 300 gig. He had to do one drive at a time. We concluded that the 40 gig drives were preventing the lba48 from being set. After all drives were formated he built his RAID5 with a 3 disk array+ 1 spare.

There was another user that had problems and his problem was tracked down to WD or Maxtor drives. I think he tied an Hitachi and it worked. Just a sugestion.

I would not play with platformbytes or model. There has been many 1000 turned into door stops playing with that. I have one here that I have not been able to get it out of waiting for IP address. The user was trying to turn the 1000 into a 2000 and failed to get the model changed back before the unit rebooted on him.

[firestar2k3]

Originally Posted by blue68f100

Upgrading to large HD is a function of the HW, BIOS and OS versions. Check your BIOS and HW and see if it is greater than v2. If so v4 OS will use LBA48. I have helped many with up this upgrade. Most are suscessful if these requirments are meet on a 4100, not so on 4000.

can you help me i have bios >2 and really need 48bit plz help!!

[firestar2k3]

Originally Posted by blue68f100

Upgrading to large HD is a function of the HW, BIOS and OS versions. Check your BIOS and HW and see if it is greater than v2. If so v4 OS will use LBA48. I have helped many with up this upgrade. Most are suscessful if these requirments are meet on a 4100, not so on 4000.

can you help me i have bios >2 and really need 48bit plz help!!

[blue68f100]

Post the "info devices" results. and the HW & BIOS versions.

[re3dyb0y]

For FireStar

Model Software Hardware Server # BIOS
4000 series 4.0.860 (US) 2.2.1 554308 2.4.437


We've tried counter reset and also config devices reinit

[blue68f100]

Does the device info shows any of the non-present drives in a raid 5 array. Some times with an broken array, the drive data is stored in flashram. It will only show up with one of the original drives installed? Apparently you can't mix and match.

[blue68f100]

On post 495 it refers to promise controler does not support 48bit LBA. But BSD and unix does.

You might try the rare 3.4.805 version. It is suppose to support 48bit.

[Seatech]

I'm trying to turn my 705N into a TB box.

I have 4 New 250GB Toshiba Drives.

704N info............
Software Version: 3.4.790
Hardware Version: 2.2.1
Bios Version: 2.4.437

Has anyone done this upgrade on a Dell 705N?

Any help will be great.....

[Seatech]

After hours of reading...I see that version 3.4.805 is the best hope I have..

Well, I do not have this Version and would like to find here..

Please email me if you have it..

Thank you

[re3dyb0y]

Contat ME

And NB

You wont get a TB with 4 250gb,s you will get around 900GB

[kcrossley]

Originally Posted by poogles_uk

You wont get a TB with 4 250gb,s you will get around 900GB

Are you suggesting that you've gotten this to work?

[djC]

<please ignore>

[djC]

A quick "Quest for the 48bit LBA issue" update:

Having tried several tips, which -unfortunatelly- did not work on my 4100s Bios/HW/SW combination, I was left with a last chance:

Trying the older v3 4 805.

Indeed, I tried to upgrade the appliance using the v3 sup file, but I kept receiving the message "this file is not a valid upgrade for the server". Perhaps Snap decided not to let us go back, or I am doing something terribly wrong

Does anybody what exactly is the issue, and if there is a procedure to achieve a downgrade to v3?

[blue68f100]

On servers where the OS is stored in flashram, this becomes a problem.
I believe the folowing models 1000v1, 2000, 4000, 4100 store the os in flashram. The reason for not needing a image file. If you need an image file to boot the server, reload the image file then try the upgrade to 805.

What else havn't we tried??????

Remove all drives.
format one with fat32 or ntsf since it a large drive.
Install into server. Does the server prepares/setup the drive for use?
If YES, your hosed. for v3 reload.
login to debug and enter the secret cmd "co de format 10000 /reinit"
then check for capacity.

I had one user it took several trys for it to take.
Have you tried a different brand drive (seagate). There have been some cases where one brand would not work, and another would. It has to do with the number of disk platters, heads and cylinder need for that particular capacity. On the 300 gigs, it can be done with 2 or 3 platers now. This makes a difference in how the lba setup. They will have diferent heads and cyl counts.

Just a thought.