RMA'd motherboard not initialising network devices?

  • I have an ASROCK Rack C2750D4i that I had to RMA owing to the C2000 chipset issue. I've dropped the replacement board in and most things check out, I just can't for the life of me figure out why the network adaptors aren't working.


    They appear to be getting loaded by the igb driver:


    But aren't found anywhere that matters:


    Can anyone point me in the right direction?


    Cheers

  • Gave that a try and after the reboot nothing has changed. The new devices aren't being written to the file and they're still not showing up anywhere else.


    I tried to manually trigger writing that file with

    Bash
    /sbin/udevadm trigger --type=devices --action=add

    And it's staying resolutely empty. Can you think of anything else?

  • Two things you can try.


    First, rename the file and then reboot, the file might properly regenerate:


    mv /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules.old && reboot


    Or if that fails, rename it back and determine the MAC addresses of your new NICs. You can edit the file replacing the old values in there that came from the old motherboard:


    dmesg | grep eth or


    dmesg | grep igb

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Einmal editiert, zuletzt von gderf ()

  • Unfortunately I've already trashed the file and I've been trying to get it to regenerate so that I could manually swap out the mac addresses. I'll keep plugging away at getting it to regenerate.


    Thanks for your help!

  • Just curious, how log did you have the old board before it failed due to the C2000 bug? My C2550D4I has been running 24/7 for 28 months and was rebooted a few days ago without any problems.


    I can provide a copy of my file that you can edit, just ask.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • I got it March, 2016, and it ran 24/7 until dying with IOCK errors in November, 2018. It's taken two months for ASRock to get the replacement board to me so not too happy about that service, but at least I've got it now.


    And yeah, nothing I've tried so far has generated that file for me so I'd be grateful if you could paste yours.


    Semi-related, only lan1 has any lights running on it. lan2 gets me no lights whatsoever. I'm wondering if lan1 being shared with the management interface is getting in the way?

  • On mine, LAN 1 is shared with the management port. I don't think that an interface will light up the link light until the OS grabs it.


    Looks like I am about six months away from a failure, maybe. I got much better service from ASROCK when my original board developed a failed serial port. Got an advanced replacement in a few days. I was down only the time it took to change out the board.


    Here is my /etc/udev/rules.d/70-persistent-net.rules file (the SUBSYSTEM== lines are wrapped)


    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Even dropping that file into place and triple checking the mac addresses wasn't enough - I couldn't stop it from renaming the devices from eth0 to enp7s0


    So I tried disabling the predictable renaming following https://www.freedesktop.org/wi…bleNetworkInterfaceNames/ and that didn't work.


    So I tried to disable it by following answers on stackexchange, none of which worked.


    Eventually, in desperation, I ran omv-firstaid. First option in the menu is to configure network interfaces so I did that and now enp7s0 is a real network interface and just appears to work.


    I'm a little too frustrated to want to keep fighting this. :(


    Thanks very much for your help.

  • Seeing enp7s0 instead of eth0 is not unusual. My Linux Mint box does this and it's quite common.


    My OMV install is more than three years old, starting with 2.x, then in-place upgrading to 3.x, and then in-place upgrading to 4.x. It would not surprise me to see see this happen on a fresh install of OMV 4.x.


    Did ASRock give any reasons why it took so long to get a replacement board to you? I couldn't live without my OMV box for 2 months.


    Glad you are back up and running :)

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Oddly this one has been upgraded in place from 2.x as well, so I've been a touch confused about why I'm having all these pains right now.


    The first big holdup I had was that I filled in the support request form on the ASRock site and nobody got back to me for a couple of weeks. I wound up contacting Newegg and asking them to get in touch with ASRock for me since I couldn't get a response. They couldn't either, so that dragged on for a couple of weeks more.


    At which point someone gave me a phone number I could call and that lead straight to an RMA, so I sent the board in, just in time for it to catch the christmas break.


    Post christmas break, they said they'd finished testing the board and would be sending out the replacement and the RMA was flagged as complete on the third of January with the replacement shipped out on the fourth. I didn't receive any tracking information though, so every few days I would send them an email asking if it was possible to get a tracking number. After ten days I finally got a tracking number from Purolator which confirmed that the shipment had only been started that day, and that took about seven days to arrive.


    All told about two months.

  • The oddnesses of recovering a server continue:



    Code
    Date:        Fri, 25 Jan 2019 15:36:34
            Action:      alert
            Host:        chunk
            Description: status failed (1) -- /srv/dev-disk-by-label-wdred6 is not a mountpoint

    They were previously under /media. Why have they now changed to be under /srv? I have no idea.

  • I filled that online form out to RMA my board and when I didn't hear back by the next day I emailed William Lee directly. His email address is all over the net in forums that deal with ASRock stuff. He emailed me back immediately, said they were having problems with the online RMA system, and he got the replacement board shipped out the next day. I was still running on my old board sans serial port which wasn't a big problem.


    Not sure on which upgrade I noticed the /media vs /srv thing. I do remember that all my already existing disks remained under /media, but newly added ones wound up in /srv. There is an environment variable that controls what the default is going forward, but it won't automatically move already existing mountpoints for you. I manually moved everything to /srv as that's going to be the standard going forward.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • You had a much better experience than I did. Mine has soured me so much on ASRock that I started looking for a replacement board from a different manufacturer. Turns out nobody else really makes anything that compares. :/


    I've now got all the drives mounted and the data is intact and plex is up and running so I'd say I'm pretty close to all good. Next up is to make sure all the docker containers still work - I think they might have gotten a bit broken in the move from /media to /srv.


    Edit: bit broken doesn't even begin to cover it. They're all dead and refusing to start. Great times.

    • Offizieller Beitrag

    Seeing enp7s0 instead of eth0 is not unusual.

    This is a new interface naming convention, as of Debian 9. (It threw me off when I first noticed it.) The old naming convention that generated ethX has been, as they say, "depreciated".

  • I got my replacement board before I got into Dockers, so the total effort for me was to edit /etc/udev/rules.d/70-persistent-net.rules and change the MAC addresses.


    If and when my board dies due to that C2000 bug, I'll see what the RMA story is then. I asked William Lee about this as soon as I read about the bug and he claimed ASRock was going to extend warranties out to cover the problems as they come up. He wasn't very specific though.


    If it turns out I will have to buy a new board I'll probably just eat it and keep going with what I have. Very little out there with at least eight SATA ports on board, and I currently need eight ports. Sure, I could add a PCIe card to get more ports, but I suspect a new MB, new CPU, probably new ECC RAM, and a SATA board would cost more than a new identical to what I already have ASRock board.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • This is a new interface naming convention, as of Debian 9. (It threw me off when I first noticed it.) The old naming convention that generated ethX has been, as they say, "depreciated".

    Makes me wonder why my box stuck with eth0 after upgrading to OMV 4.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    Makes me wonder why my box stuck with eth0 after upgrading to OMV 4.

    Already named and in place? This may be standard for an upgrade. Otherwise, a number of confg files would need to be changed.
    ___________________________________________________________________


    New builds, on Debian 9, have a variety of Ethernet interface names, depending the hardware, BIOS order, PCI slot, etc. -> Debian 9, what's new


    enp07s0 seems to be common on Intel hardware. I have an Acer box with the following.




    It can be changed back, but I don't believe the effort is worth it.

  • After one random reboot my network devices came back as eth0 and eth1. I have no idea why other than perhaps one of my attempts to change it earlier finally took? Very confused.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!