Snap Server 4000 that thinks it's a 2000

[snej]

One of the ide channels seems to have recently failed on my Snap 4000 series.
I have 4x80 gig drives in it, running RAID 5. I think the failure was caused by a loose IDE cable, because replugging the IDE cables seems to have fixed the problem with the drive channels. Afterwards the Snap ran it's disk check, and spent a few hours "repairing" the array. I can once again access my ~240 gig (~320 w/parity) share, and all my files appear to be intact, which is all great.

But my snap server now seems to think it is a 2000 series device.
Disk management only allows me to select RAID 0 or 1 options.

The About dialog now reports my Snap as:

Model: 2000 series
Software: 3.4.790 (US)
Hardware: 0.0.0
Server #: 16999
Bios: 2.0.252

I cannot update the OS using the 3.4.8x software or any of the 4.x software. I get the following error:

Problem: Invalid SUP file for the given platform. Try selecting another SUP file and repeating the operation.

In the debug console, the bios model displays as 0, the 2 drive IDE.
I am able to set it to 2, the 4 drive IDE, but immediately after setting, it seems to revert back to 0.

Does anyone know how I can force my Snap back to recognizing itself as a proper 4000 series device?

[blue68f100]

That is strange.
You should have a hardware version.
You need your model set to "2 4 drive IDE Laser"
I do not know if the raid needs to be turned off, and set to JOBD.
You may need to unlock the bios for it work. (bios unlock).
If you unlock the bios make sure you lock it back after the change (bios lock).

David

[snej]

Originally Posted by blue68f100

That is strange.
You should have a hardware version.
You need your model set to "2 4 drive IDE Laser"
I do not know if the raid needs to be turned off, and set to JOBD.
You may need to unlock the bios for it work. (bios unlock).
If you unlock the bios make sure you lock it back after the change (bios lock).

David

Thanks for the tips, but unfortunately, this still does not keep the setting at Laser.

I navigate to the console page:

bios unlock
bios model 2
bios lock

and then check the model again, and it reports as being back to minnie.

I'm not sure what difference disabling RAID would make, and since I have the 3.4 OS, I cannot use JBOD.


//Edit:
The serial number that the device is listing is also incorrect, however when I set the proper serial number (which also changes the hardware address) the machine reverts back to the incorrect serial, just like it does for the model #.

[blue68f100]

Do you know what hardware version it was before it went south? This may need setting.
I was looking at a snap document on setting them up from a bare unit. They were able to tell if a unit was not correctly configured by looking at the serial No. hardware and ram.
There are 3 option for drive setup, individual (JBOD), mirror (1) and span (0) . But I don't know if it going to help in this case.
Have you tried setting the SN and model at he same time with the bios unlocked?
There is a "/force" cmd, that is attached to the end of a cmd. You might try it.

[snej]

I don't still have the hardware version. I checked my old documentation and couldn't find it written down anywhere.
I changed out the ram about a year ago, and no longer have the original stick for them to check.
You don't happen to still have access to that setup document do you?

I tried /force at the end of the serial and model commands, but they still revert back to the prior setting immediately.

I'm trying to avoid reformatting these disks, so I don't lose all the data on them currently. I have tried booting the server with no disks attached and setting the SN and model, but still no luck.

[blue68f100]

You may have to set all of the values that are not correct. I do know the SN is tied to the model. You did mention that the SN changed the model. There is also an OEM flag, But I don't know how it is used. You may check back through the forum and find out how they changed their 1000 to a 2000. The procedure should be the same. The info I gave you is correct to the best of my knowledge. I only have the 2X00 models, so I can't verify the other flags.

Does it changes back on reboot or lock bios? If so try rebooting with out locking the bios back and see what happens.

I would BACKUP the data that is on it. It's riskey doing these comands.

I will keep digging. Maybe I will come up with something else to try.
You may need to consult with MisterBill or poogles_uk. These two are the brains on the 4X00 models.

[snej]

Thanks for your help bluegreen, and thanks for setting me straight on JBOD.

It appears that the values change on a cold boot, when the server compares it's current values to some sort of internal checksum. The server log shows:

E 	Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image. 	Network 	11/18/2005 	 2:36:40 PM 	
W 	Ethernet driver : Writing whole image. 	Network 	11/18/2005 	 2:36:40 PM 	
W 	Ethernet driver : Changing platform bytes from 0.0.0 (0) to 0.0.0 (2). 	Network 	11/18/2005 	 2:36:40 PM 	
W 	Ethernet driver : Changing model byte from 0x00 to 0x02. 	Network 	11/18/2005 	 2:36:40 PM 	
E 	Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image. 	Network 	11/18/2005 	 2:36:40 PM 	
E 	Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image. 	Network 	11/18/2005 	 2:36:40 PM 	
W 	Ethernet driver : Writing whole image. 	Network 	11/18/2005 	 2:36:40 PM 	
W 	Ethernet driver : Changing platform bytes from 0.0.0 (0) to 2.0.1 (0). 	Network 	11/18/2005 	 2:36:40 PM 	
E 	Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image. 	Network 	11/18/2005 	 2:36:40 PM

By only internally rebooting the machine, I was able to change the values long enough to update the OS version to 4.0.830 and then 4.0.860.
The hardware value that appears when the serial number and model number are correct is 2.0.1

//Edit:
I have all the data on the disks backed up now, so if everything blows up, I shouldn't lose any data.

I will look into the old posts/info on changing the 1000 to a 2000

[blue68f100]

I'm not sure I would have done any updates with the hardware not indicating correctly. I think the OS is stored in flashram on the 4000. You may have just locked you self into a dual 2000.

I looked through the posts earlier today. The ones that I found used the Unlock, model, lock sequence.

It may be a long shot. You might try loading a image file from another 4000.

David

[Nuschel]

I'm actually having the exact same issue with my 4000. Has anyone come up with a way to reflash / repair from this problem?

[blue68f100]

Or is your 4000 thinks it a 2000, seen this both ways.
Do you know what version of bios you had?

Backup any data you want to keep.

check your model & platformbyte setting from debug.
"bios model"
"bios plarformbytes" Should be 2.0.1 probably is 2.0.0

Your platformbytes needs to be changed.
unlock bios
bios platformbytes 2 0 1
Check bios model if not correct change
bios model 2 ( 4 drive unit) * may auto reboot
lock bios
reboot server

Should be back to a 4000 model

[Phoenix32]

David, he and I spoke in PM and he told me he had already done that except he did not mention unlocking/locking the BIOS. He told me it would not take after a reboot. I asked him if he unlocked the BIOS first (and then lock when done), but he has not answered back yet.

[Nuschel]

I've tried locking again when it is done, still same result. Thanks for the help in the PM and forums. I will continue trying.

[blue68f100]

Post what you values are.
bios model (0 for 2 drives)
bios platformbytes (0.0.0, 2.0.0, 2.1.0)

Platformbytes is very picky on syntax. If 2 0 1 gives an error try 2.0.1 You may be forced to change one byte at time. I ran in to all of these trying to reset the 1000 that was set to a 2000.

You must unlock the bios before any of these values can be changed.

[Nuschel]

Model Byte currently is:
==> 0 - 2 drive IDE: "Minnie"
1 - 1 drive IDE: "Mortie"
2 - 4 drive IDE: "Laser"
3 - 12 drive IDE: "Clipper"

Platform Bytes are "0.0.0"

Tried commands in this order

bios unlock
bios platformbytes 2 0 1
bios model 2
lock bios
reboot 0

The model shows changed after command, but the setting does not stick
The platform bytes always shows 0.0.0 regardless of what is entered

bios version shows:

Failsafe Bios not found

Bios stamp 2.0.252 Thu Apr 01 16:30:19 1999

Plat Bytes 0.0.0

Model Byte 0

The ethernet address / serial number is also showing the wrong information

Shows:
Ethernet Address has been set to 00-C0-B6-00-42-67 (Serial Number 16999)

Should be:
Ethernet Address has been set to 00-C0-B6-04-9F-1C (Serial Number 302876)

System log shows
E Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image. Network 3/18/2007 4:50:47 PM
W Ethernet driver : Writing whole image. Network 3/18/2007 4:50:47 PM
W Ethernet driver : Changing platform bytes from 0.0.0 (0) to 0.0.0 (2). Network 3/18/2007 4:50:47 PM
W Ethernet driver : Changing model byte from 0x00 to 0x02. Network 3/18/2007 4:50:47 PM
E Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image. Network 3/18/2007 4:50:47 PM

I tried

bios platformbytes 2.0.1

but I got a syntax error.

info version shows:

Product: 0 - "Minnie: 2 drive IDE" - Platform Bytes "0.0.0"
Server-4.0.860, Build Date: Mar 2 2005 17:50:35
This is the NON-Debug executable, and was built by KEVIN
You are logged in as user ROOT (local)

Let me know if any additional information is needed.

Thanks

[blue68f100]

Do you have record of what the bios version was prior to the change. I'm thinking the bios should be 2.0.282 . The 2.0.252 ties the platformbytes (2.0.0) to a 2000.

I really don't know where to start. Since most all of the settings were lost.

Since the SN is tied to the model no, lets see if the cmos can be changed.

bios unlock
check bios cmos serial-no
bios cmos serial-no (serial no/default/hex4th-hex5th-hex6th chars of ethernet addr)
bios lock
check bios cmos serial-no

bios unlock
bios platformbytes 2 0 1
bios lock

then check to see if it took, "bios platformbytes"

bios unlock
bios model 2
bios lock

if incorrect try to change the order, knowing that changing the model forces a reboot.

What were you doing that caused everything to get scrambled? OS update?

I know the model numbers are tied to the Serial No. So you may be required to change the bios cmos first.

The good news is that is is still booting (uses same hex code). Was not the case with the my 1000.

[Phoenix32]

David, this looks like someone has been in there before messing with it.

[blue68f100]

Not necessarly. I have heard random reports that some times the platformbytes is reset during OS upgrades. With the 4000 and 2000 using common MB it almost falls back to a fail safe. It is only 1 byte different, 2.0.0 vs 2.0.1.

But this one acts like it lost power during the upgrade.

[Nuschel]

I don't know what version the bios was before, I got the device in this condition.

I'm wondering if the reason the changes are not taking effect is due to

Product: 0 - "Minnie: 2 drive IDE" - Platform Bytes "0.0.0"
Server-4.0.860, Build Date: Mar 2 2005 17:50:35
This is the NON-Debug executable, and was built by KEVIN
You are logged in as user ROOT (local)

Showing it is a NON-Debug executable.

I've done just about everything I can think of on this device, to no avail. Is there some way to force an OS update, ignoring the file verification?

[blue68f100]

The updates are bassed on the platformbytes. For the reason of the sup file failure. The sup files have hex markers that cross reference to platformbytes. Which is also tied to the BIOS. So every thing is linked.

Your only option may be to stick to where you are, or find someone who can reload the BIOS.

[Phoenix32]

Originally Posted by blue68f100

Not necessarly. I have heard random reports that some times the platformbytes is reset during OS upgrades. With the 4000 and 2000 using common MB it almost falls back to a fail safe. It is only 1 byte different, 2.0.0 vs 2.0.1.

But this one acts like it lost power during the upgrade.

It's the serial number and ethernet stuff that has me wondering, not the platform byte.

[blue68f100]

After recovering form a snap1000 that was set to be a 2000. I learned everything (all updates) is based on the platformbytes. This is the info a OS upgrade looks at to know which MOAI file to use. In one of my documents they was a foot note refering to serial numbers and model numbers. Like the 4100 all seam to start with 500k, 2000v1 200k... I have seen the MAC and SN change with the platform bytes change.

But I learned it will not take a platformbyte that it does not reconises. Since the failsafe BIOS is missing, it leads me to think a Upgrade failed. It may require the bios to be reloaded using the factory software.

It would be interesting to know if the 4000 will setup and clean system.

Out of curisoity is the HD cables colored? and are the HD set to MS or CS?.

The 16999 SN make the units a problem 2000v1. Right of the top of my head I do not remember where the 4000 changed from MS to CS.

Is this a 1U or 2U unit?

[Nuschel]

It is a 2U unit.

Do you think that I would be able to force an update using the

bios flup

command and a utility like snapup?

[blue68f100]

If you had the BIOS file you could. But there presents the problem, do you have the BIOS files?

You have the proper OS loaded, just all of the flags are off.

Some of the early early OS Update files (v2) had the MOAI files but none that I have seen included the BIOS files. Unless it was hidden on the factory cd shipped with unit. But none that I have seen. All of the sup files are in Intel HEX code. So the code is loaded to specific flashram addresses. I do not have a program that extracts the code from a working unit, nor have I heard of one.

The BIOS FLUP (5 blinks) mode is what is used when you use assist to load the OS. Snapup is like a early Assist program.

It took me over a year to figure how to reset a 1000 that was set to a 2000 model, would not boot at all.

[Phoenix32]

Originally Posted by blue68f100

The BIOS FLUP (5 blinks) mode is what is used when you use assist to load the OS. Snapup is like a early Assist program.

[Nuschel]

Ok, I was able to downgrade the OS on my 4000 to version 4.0.830.
However, the model and platformbytes are still wrong. The ethernet address is also wrong.

I can unlock the bios, change the settings for each of these and lock bios, but none of the configuration will stay. Any ideas?

info log t

3/20/2007 23:47:18 2 D SYS | HiRez: Platform bytes are Wrong! (0.0.0)!
03/20/2007 23:47:18 2 D SYS | e2: E2-Cache was defaulted!
03/20/2007 23:47:18 2 E NET | Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image.
03/20/2007 23:47:18 2 W NET | Ethernet driver : Changing platform bytes from 0.0.0 (0) to 2.0.1 (0).
03/20/2007 23:47:18 2 W NET | Ethernet driver : Writing whole image.
03/20/2007 23:47:18 2 E NET | Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image.
03/20/2007 23:47:18 2 D SYS | e2: E2-Cache was defaulted!
03/20/2007 23:47:18 2 E NET | Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image.
03/20/2007 23:47:18 2 W NET | Ethernet driver : Changing model byte from 0x00 to 0x02.
03/20/2007 23:47:18 2 W NET | Ethernet driver : Changing platform bytes from 0.0.0 (0) to 0.0.0 (2).
03/20/2007 23:47:18 2 W NET | Ethernet driver : Writing whole image.
03/20/2007 23:47:18 2 E NET | Ethernet driver : Checksum, signature or ethernet address is wrong. Defaulting E2-Image.
03/20/2007 23:47:18 2 S SYS | System Initialization : Server v4.0.830
                               Build Date: Dec 24 2003 19:04:13
                               Boot Count: 2
03/20/2007 23:47:18 2 D SYS | Executable built by KEVIN
03/20/2007 23:47:18 2 D SYS | Hardware platform:0.0.0  Model:0  (64 MBytes)  S/N:16999
03/20/2007 23:47:18 2 D SYS | ETH: Reset- Eaddr set to 00 C0 B6 00 42 67
03/20/2007 23:47:18 2 D SYS | Update IP...
03/20/2007 23:47:18 2 I NET | INIT: Setting IP address to 192.168.1.108
03/20/2007 23:47:18 2 D SYS | Update IP...
03/20/2007 23:47:18 2 D SYS | Initial file system BIO cache size is 6709632 bytes, 808 buffers
03/20/2007 23:47:18 2 D SYS | DISK: Initial ARBs: 808  Memory: 132512
03/20/2007 23:47:18 2 D SYS | Code Page set to 437
03/20/2007 23:47:18 2 D SYS | QDL System is ENABLED
03/20/2007 23:47:18 2 D SYS | Disk cache flush enabled
03/20/2007 23:47:19 2 D SYS | SNMP agent enabled for ReadWrite.
03/20/2007 23:47:19 2 D SYS | AFP: started
03/20/2007 23:47:19 2 D SYS | 'FTPD' started.
03/20/2007 23:47:19 2 D SYS | Update WorkGroup...

info ver

Product: 0 - "Minnie: 2 drive IDE" - Platform Bytes "0.0.0"
Server-4.0.830, Build Date: Dec 24 2003 19:04:13
This is the NON-Debug executable, and was built by KEVIN
You are logged in as user ROOT (local)

info cmos

Server Name:             SNAP16999
Ethernet Address:        00-C0-B6-00-42-67
Serial No:               16999
Auto-Gen. IP Addresses:  DISABLED
IP address:              192.168.1.108
IP netmask:              255.255.255.0
IP Default gateway:      192.168.1.1
DHCP Server Address:     192.168.1.1
WINS/NetBios Name Server:0.0.0.0
DNS Server:              68.12.16.30
SMTP Mail Server:        0.0.0.0

One interesting fact that I noticed is that after issuing the

config cmos serial-no

command, the name of the device changed to reflect the new serial number.

At this point, I am resigned to believe that the problem is not in the OS, but rather in the BIOS.