Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Kimsufi KS-1: Upgraded to 20.04 and then lost access
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Kimsufi KS-1: Upgraded to 20.04 and then lost access

cyanogeniccyanogenic Member
edited May 2020 in Help

Hi all,

Noob here.

Before I re-image the server back to 16.04, I want to check if there's other ways of saving the install.

So I got a KS-1 last week just to play around with, as my Aruba €1 VPS wasn't powerful enough to run some of the things I wanted to try.

I installed 16.04 from the Kimsufi interface, and then proceeded to upgrade to 18.04. No problem. I then proceeded to upgrade it to 20.04. After a restart I lost access to it via SSH.

What can I try to save it? I can boot into Kimsufi's rescue mode (rescue64-pro) but just not sure what to check or update.

Note: I can't ping my server, SSH into port 22 or port 1022 (that was set up during the upgrade process). I can boot into rescue mode or reinstall the image (just prefer not to if I can save it!)

Comments

  • AndruAndru Member

    Check firewall for port 22 and check ssh server config or if it's up&running.
    Upgrade should not be a problem in 99% of dedi cases.

    Good luck!

  • Mr_TomMr_Tom Member, Host Rep

    If you can boot it into rescue mode it might be worth checking what network hardware is used, and checking whether any additional modules/drivers are required. I know some newer distros don't work out the box with some older network hardware

    Thanked by 1quicksilver03
  • @Mr_Tom said:
    If you can boot it into rescue mode it might be worth checking what network hardware is used, and checking whether any additional modules/drivers are required. I know some newer distros don't work out the box with some older network hardware

    Yep I'm in rescue mode right now.

    Uhhhh is this what I'm looking for? lshw shows all my network interfaces are disabled... /facepalm

    *-network:0 DISABLED
    description: Ethernet interface
    physical id: 1
    logical name: gretap0
    capabilities: ethernet physical
    configuration: broadcast=yes multicast=yes
    *-network:1 DISABLED
    description: Ethernet interface
    physical id: 2
    logical name: ifb0
    serial: ---------
    capabilities: ethernet physical
    configuration: broadcast=yes
    *-network:2 DISABLED
    description: Ethernet interface
    physical id: 3
    logical name: ifb1
    serial: ----------------
    capabilities: ethernet physical
    configuration: broadcast=yes
    *-network:3 DISABLED
    description: Ethernet interface
    physical id: 4
    logical name: erspan0
    capabilities: ethernet physical
    configuration: broadcast=yes multicast=yes
    *-network:4 DISABLED
    description: Ethernet interface
    physical id: 5
    logical name: dummy0
    serial: ------------
    capabilities: ethernet physical
    configuration: broadcast=yes driver=dummy driverversion=1.0

  • Mr_TomMr_Tom Member, Host Rep

    Hmm it's not listing the adapter name.

    What do you from lspci |egrep -i "network|ethernet" ?

  • @Mr_Tom said:
    Hmm it's not listing the adapter name.

    What do you from lspci |egrep -i "network|ethernet" ?

    01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

  • Mr_TomMr_Tom Member, Host Rep

    Does lspci -nnk list which module (if any) it's using?

  • @Mr_Tom said:
    Does lspci -nnk list which module (if any) it's using?

    root@rescue:/# lspci -nnk
    pcilib: Cannot open /proc/bus/pci
    00:00.0 Host bridge [0600]: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller [8086:0bf2] (rev 04)
    Subsystem: Intel Corporation Atom Processor D2xxx/N2xxx DRAM Controller [8086:2012]
    lspci: Unable to load libkmod resources: error -12
    00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller [8086:0be2] (rev 0b)
    Subsystem: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller [8086:2012]
    00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 1 [8086:27d0] (rev 02)
    00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 02)
    Subsystem: Intel Corporation NM10/ICH7 Family USB UHCI Controller [8086:2012]
    00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 02)
    Subsystem: Intel Corporation NM10/ICH7 Family USB UHCI Controller [8086:2012]
    00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 02)
    Subsystem: Intel Corporation NM10/ICH7 Family USB UHCI Controller [8086:2012]
    00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 02)
    Subsystem: Intel Corporation NM10/ICH7 Family USB UHCI Controller [8086:2012]
    00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 02)
    Subsystem: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:2012]
    00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev e2)
    00:1f.0 ISA bridge [0601]: Intel Corporation NM10 Family LPC Controller [8086:27bc] (rev 02)
    Subsystem: Intel Corporation NM10 Family LPC Controller [8086:2012]
    00:1f.2 SATA controller [0106]: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] [8086:27c1] (rev 02)
    Subsystem: Intel Corporation NM10/ICH7 Family SATA Controller [AHCI mode] [8086:2012]
    00:1f.3 SMBus [0c05]: Intel Corporation NM10/ICH7 Family SMBus Controller [8086:27da] (rev 02)
    Subsystem: Intel Corporation NM10/ICH7 Family SMBus Controller [8086:2012]
    01:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
    Subsystem: Intel Corporation 82574L Gigabit Network Connection [8086:2012]

  • Mr_TomMr_Tom Member, Host Rep

    Okay, different output to what I get on my system, so not sure it'll help.

    Might be worth mouting the root filesystem and checking no modules are blacklisted that shouldn't be (under the root not the rescue filesystem). The e1000e module should work for that adapter I believe.

    You could also check the logs under there to see why it's failing to bring up the network. Also probably worth checking it's not adjusted the network settings when upgrading - I had a VPS once that renamed the network device (from eth0 to ens1p as an example) and lost connectivity after an upgrade to Debian.

  • @Mr_Tom @zuby2402 Hi both, just wanted to give an update.

    Kimsufi's automatic monitoring logged a fault and they got someone to look into it and fixed the issue :)

    Date 2020-05-08 14:10:19 CEST (UTC +02:00), melvin F made Software diagnosis:
    The server gets stuck during the boot phase with the message : (grub rescue)

    The same behavior persists during subsequent boots.

    A reboot on a standard OVH kernel (bzImage) corrects the situation.

    The server is booted on OVH kernel and is on the login screen. Ping OK and services are up.

  • So are logged in now with ubuntu 20.04?

  • cyanogeniccyanogenic Member
    edited May 2020

    @suricloud said:
    So are logged in now with ubuntu 20.04?

    Yep, 20.04 working fine on the KS-1 now. Seems like the upgrade made some changes to grub or the kernel and caused it to go into grub rescue mode

  • GaldorGaldor Member

    @cyanogenic I had an issue similar to yours: Kimsufi KS-1 installed with ubuntu 16.04 then do-release-upgrade to 18.04, then do-release-upgrade -d to 20.04. After reboot, I was no longer able to log through ssh (connection refused on port 22 if I recall well).

    In my case, it seems that the issue could be "fixed" by answering "No" to the last question of do-release-upgrade -d (ie upgrade 18.04 -> 20.04) which asked as whether to delete unused packages (equivalent of apt autoremove). Part of those packages were linux-headers. I did not investigate the exact cause, but keeping those packages during the do-release-upgrade -d seemed to have allowed for correct reboot.

    From there, I was able to reboot again. And after that, I ran apt autoremove to remove the (presumely) same packages as do-release-upgrade was proposing to remove and I still was able to reboot!

    I now am on Ubuntu 20.04, witch all packages up-to-date!

Sign In or Register to comment.