New on LowEndTalk? Please Register and read our Community Rules.
Delimiter CPU upgrade woes
Did anyone else buy a one-time CPU upgrade from the promo 2 weeks ago? If yes, how well did that go for you?
I'm asking because after waiting for 9 days after paying for the upgrade, they finally did it yesterday, just in time for the weekend. Server now doesn't have a network, it doesn't even get an ARP response from the switch when asking for the gateway's MAC address. iopinging the local disk is beyond sad and I'm seeing responses in the multiple-seconds area. Obviously nobody is going to reply to the ticket until at least Monday.
Let me know if you were affected and what the solution was.
Comments
I think you meant to tag "clusterfuck"
When the upgrade was completed you were sent a ticket with the following:
Its very clear that if you leave your network configuration as-is then you won't be able to pass any traffic. You have to update your network configuration to use the new network device.
New hardware = new MAC address = new udev rule = new network device name.
As my colleague stated, if you need help provide the root password and they'll do it for you.
Its the SAME disk as you previous machine, its just moved from the old server to the new one.
Rather than wasting time here trying to generate drama, take my colleague up on his offer to assist you which was sent in the notification of the upgrade completion. If you had done this then you would already be online.
Don't worry. If you post on LET you'll get a response from their support team within minutes.
Oh dear.
How about telling the customer that there is going to be a MAC change in advance Mark? That's what a professional would do.
I'm certainly not handing out the root password, that's why am asking here if someone else had the same problems.
And it's not as easy as deleting the persistent-rules file since there is no such file for some reason (Ubuntu Server).
New hardware equals new MAC it's that simple. The MAC is unique to each hardware interface. As far as I know you can't change hardware the way they did without getting a new MAC. (Pull drives and install in a new server)
If you get new NIC, you're going to get a new MAC. That's how network cards work.
Just give him the MAC address goddamnit.
I've found the network problem: the biosdevname kernel option is no longer honored in 16.04. That's why it couldn't find eth0. I replaced it with enp5s0f0 and network is back again.
Now I still see ioping results in the 2 second range, disk is extremely slow.
As always, love and hate for Delimiter.
Good hardware offer with limited service, you really need to know what you are doing otherwise another drama thread will be posted
Just consider their support is just like a remote hand in DC and you will be fine. TBH, their hardware and network is awesome.
Is write back cache enabled?
Yes, that was one of the first things I verified.
mdadm ist syncing the softraid but even this is extremely slow with 9093 minutes to complete (150 hours).
Isn't that obvious? New server? So new nics?
I don't see how one could do it otherwise with any modern server. The base NICs are almost always integrated on the board.
Anyway, follow up with the support ticket if you need assistance. I would suggest sending them:
Also tell them what OS and version you are running.
Unmanaged is unmanaged
If you don't know how to run a server, then you need to go managed.
Thats what we offer - good box + good network + unmanaged
Well, it did say "CPU upgrade" in the offer. Since I'm not running around in a DC all day how am I supposed to know that this involves a server change. And again, it wasn't just the MAC that changed, the device name changed as well and eth0 was no longer working.
However, network is back. Still trying to figure out what is going on io-wise.
I'm pretty sure the email said there would be a server change, second like mark said the OS still expects eth0 to be the old NIC, so it's not going to use that name for the new one.
Xeon 5400 -> Xeon 5600 is a different family of devices. You can just swap CPUs between such disparate families.
In the upgrade completion ticket that was sent to you, you were told:
That should have been a hint that you needed to do something with the network interface.
If your OS decides not to map the device names to ethX because of a package change, kernel change or whatever change that is nothing to do with Delimiter.
Its pretty obvious, you can run ifconfig -a and you'll see straight off the device names that your OS has setup.
Well, it should reuse eth0 when you remove the persistent-rules file and if biosdevname is set to 0.
If your raid array is re-syncing, that might cause issues with io performance.
Wait for the sync to finish, then re-test
Google the CPU and check the chipset?
It being your OS not the server. So again nothing to do with Delimiter.
You should be discussing this with people on Ubuntu's forums to find out why your configuration didn't work as expected.
It actually said somewhere in the email that there will be a server change.
I've synced mdadm arrays before. Much larger ones. It has to be something else, it can't take 150 hours for a 500 GB array to sync.
..?
......?
Then the correct thing to do at this time, is open a ticket and ask for assistance.
I reread the email (all of it this time ;-)
All this thread did was make me sigh.
Me too, I landed right in provider-smartass-county just by asking if someone (a user, not a provider) experienced the same symptoms.
Nice try.
They finally?
You finally.
My delimiter dedi features slow drives too tough I'm not sure if this was caused by the recent CPU/server upgrade. The server is not using a RAID.
dd if=/dev/zero of=test_$$ bs=64k count=16k conv=fdatasync 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 50.2164 s, 21.4 MB/sCommands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Write cacheCPU is 99.*% idle, iotop is full of 0.00 B/s and smartctl doesn't show any signs of a corrupted drive.
Any ideas?