Well... maybe let me guide you step by step then?
I just went to ovh, picked up their current black friday "Value" sale, one step above "Starter".
Lists as "1 vCore / 2GB RAM / 40 GB SSD NVMe / 250 Mbps" with a lot of asterisks. Debian 12 as my usual, because you can't say "no OS, please".
After going through all the upselling and ovh-typical frustrating wait for provisioning, the VPS was there. "Model: VPS vps2020-value-1-2-40".
Clicked the three dots under "Boot" heading, "Reboot in rescue mode". Once again, frustrating of wait.
Clicked three dots under "Name" heading, "KVM".
Used the IP/password displayed on the rescue console to connect in via SSH.
[RESCUE] root@vps-xxxxxxxx:~ $ cat /proc/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=959232k,nr_inodes=239808,mode=755,inode64 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,noexec,relatime,size=196528k,mode=755,inode64 0 0
/dev/sda1 / ext4 rw,relatime,discard,errors=remount-ro 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,inode64 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k,inode64 0 0
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
bpf /sys/fs/bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12798 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0
debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0
mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0
tracefs /sys/kernel/tracing tracefs rw,nosuid,nodev,noexec,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,nosuid,nodev,noexec,relatime 0 0
configfs /sys/kernel/config configfs rw,nosuid,nodev,noexec,relatime 0 0
ramfs /run/credentials/systemd-sysctl.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-sysusers.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-tmpfiles-setup-dev.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
ramfs /run/credentials/systemd-tmpfiles-setup.service ramfs ro,nosuid,nodev,noexec,relatime,mode=700 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
[RESCUE] root@vps-xxxxxxxx:~ $ dmesg | grep -e 'sd[ab]'
[ 1.854823] sd 2:0:0:1: [sdb] 83886080 512-byte logical blocks: (42.9 GB/40.0 GiB)
[ 1.854839] sd 2:0:0:0: [sda] 6144000 512-byte logical blocks: (3.15 GB/2.93 GiB)
[ 1.854871] sd 2:0:0:0: [sda] Write Protect is off
[ 1.854873] sd 2:0:0:0: [sda] Mode Sense: 63 00 00 08
[ 1.854881] sd 2:0:0:1: [sdb] Write Protect is off
[ 1.854882] sd 2:0:0:1: [sdb] Mode Sense: 63 00 00 08
[ 1.855207] sd 2:0:0:1: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.855256] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.856573] sda: sda1
[ 1.856692] sd 2:0:0:0: [sda] Attached SCSI disk
[ 1.858396] sdb: sdb1 sdb14 sdb15
[ 1.858587] sd 2:0:0:1: [sdb] Attached SCSI disk
[ 2.344029] EXT4-fs (sda1): mounted filesystem with ordered data mode. Quota mode: none.
[ 3.170151] EXT4-fs (sda1): re-mounted. Quota mode: none.
[RESCUE] root@vps-xxxxxxxx:~ $
In rescue mode, /dev/sda is temp/throwaway disk with the rescue linux, /dev/sdb is your VPS's persistent disk.
It comes pre-partitioned like this:
[RESCUE] root@vps-xxxxxxxx:~ $ fdisk -l /dev/sdb
Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 999A3CBF-CB61-9F43-9EB1-2590F7B73A7D
Device Start End Sectors Size Type
/dev/sdb1 262144 83886046 83623903 39.9G Linux root (x86-64)
/dev/sdb14 2048 8191 6144 3M BIOS boot
/dev/sdb15 8192 262143 253952 124M EFI System
Partition table entries are not in disk order.
[RESCUE] root@vps-xxxxxxxx:~ $
Let's zero it out...
[RESCUE] root@vps-xxxxxxxx:~ $ dd if=/dev/zero of=/dev/sdb bs=1M count=1024 status=progress
1071644672 bytes (1.1 GB, 1022 MiB) copied, 3 s, 357 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.30095 s, 325 MB/s
[RESCUE] root@vps-xxxxxxxx:~ $ fdisk -l /dev/sdb
Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
[RESCUE] root@vps-xxxxxxxx:~ $
Download and unpack the CHR .img...
[RESCUE] root@vps-xxxxxxxx:~ $ apt install unzip
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
zip
The following NEW packages will be installed:
unzip
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 166 kB of archives.
After this operation, 388 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bookworm/main amd64 unzip amd64 6.0-28 [166 kB]
Fetched 166 kB in 0s (6,654 kB/s)
Selecting previously unselected package unzip.
(Reading database ... 46775 files and directories currently installed.)
Preparing to unpack .../unzip_6.0-28_amd64.deb ...
Unpacking unzip (6.0-28) ...
Setting up unzip (6.0-28) ...
[RESCUE] root@vps-xxxxxxxx:~ $ wget https://download.mikrotik.com/routeros/7.16.1/chr-7.16.1.img.zip
--2024-11-22 17:03:53-- https://download.mikrotik.com/routeros/7.16.1/chr-7.16.1.img.zip
Resolving download.mikrotik.com (download.mikrotik.com)... 2a02:610:7501:3000::251, 159.148.147.251
Connecting to download.mikrotik.com (download.mikrotik.com)|2a02:610:7501:3000::251|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 40319518 (38M) [application/zip]
Saving to: ‘chr-7.16.1.img.zip’
chr-7.16.1.img.zip 100%[==========================================================>] 38.45M 2.48MB/s in 16s
2024-11-22 17:04:09 (2.46 MB/s) - ‘chr-7.16.1.img.zip’ saved [40319518/40319518]
[RESCUE] root@vps-xxxxxxxx:~ $ unzip chr-7.16.1.img.zip
Archive: chr-7.16.1.img.zip
inflating: chr-7.16.1.img
[RESCUE] root@vps-xxxxxxxx:~ $
Write it to disk...
[RESCUE] root@vps-xxxxxxxx:~ $ dd if=chr-7.16.1.img of=/dev/sdb bs=1M status=progress
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 0.323675 s, 415 MB/s
[RESCUE] root@vps-xxxxxxxx:~ $ fdisk -l /dev/sdb
Disk /dev/sdb: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 34 65569 65536 32M 83 Linux
/dev/sdb2 65570 258047 192478 94M 83 Linux
[RESCUE] root@vps-xxxxxxxx:~ $
Make sure everything is committed to disk (yes, unnecessary superstition...)
[RESCUE] root@vps-xxxxxxxx:~ $ sync
[RESCUE] root@vps-xxxxxxxx:~ $ sync
[RESCUE] root@vps-xxxxxxxx:~ $ reboot
and then because it reboots back into rescue, close the KVM window and go to OVH control panel. You may need to refresh the page.
"Boot" header, "Reboot my VPS", confirm, and then
keep repeating the "three dots next to name -> KVM" menu until the KVM connects.
If you will be quick enough you'll even catch the QEMU BIOS and then Mikrotik bootloader messages, with the CHR auto-resizing itself from 128MB to 40GB on first boot.
Soon you will reach a "MikroTik Login:" prompt, immediately type "admin" and empty password.
If it doesn't seem to take your keyboard, click into the KVM screen first.
It will freeze for a few seconds because ROS is still initializing, then will ask if you want to see the license (say N to skip!) and then ask you to set new password.
Set a new password better than 1234 instantly, but you must rush it so maybe don't make it 40 characters super complex yet!
Then you'll be dumped into the main shell and "system, critical, login failed for admin via ssh" and "... via api" will almost for sure be already spamming your screen because bots are just /that/ aggressive.
Do
/int/eth/disab ether1 to stop that, then check /user/active/print and /log/print for any hints that something else than yourself successfully connected.
("You" will be visible in /user/active/print as "VIA: console", and in /log/print as "... user admin logged in via local".)
If yes, uh, honestly, reboot back to rescue, erase the full disk (skip the count= parameter when dd'ing from /dev/zero) and try again. Let's not risk it.
If it seems you won the race, do some very basic initial securing/setup - disable web/api/etc that you don't need, set up two basic firewall rules to drop everything than your own IP, then reenable ether1 and connect via ssh or winbox to continue with a bit more comfort.
To summarize - all you need to run in rescue mode should be:
dd if=/dev/zero of=/dev/sdb bs=1M count=1024
apt install unzip
wget https://download.mikrotik.com/routeros/7.16.1/chr-7.16.1.img.zip
unzip chr-7.16.1.img.zip
dd if=chr-7.16.1.img of=/dev/sdb bs=1M
sync
and then you reboot into your fresh CHR and race against the hackbots.
If you still can't succeed to make it work - please boot into OVH rescue mode and give me output of:
fdisk -l /dev/sda
fdisk -l /dev/sdb
dmesg
please.
G'luck.
