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
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
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!
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
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
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]
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
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
@cyanogenic I had an issue similar to yours: Kimsufi KS-1 installed with ubuntu 16.04 then
do-release-upgrade
to 18.04, thendo-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 ofapt autoremove
). Part of those packages were linux-headers. I did not investigate the exact cause, but keeping those packages during thedo-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 asdo-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!