0

This VPS was more or less idle during the days when this happened. The host (Scaleway) did not perform any maintenance or upgrades during this time, nor did I interact with the VPS directly or through the control panel. Automatic updates are disabled. The OS is Debian 10.

To me it looks like a networked filesystem was mounted for my VPS to access and enabled through some auto-discovery or similar, but I might be wrong. Is it perhaps the other way around, that the hypervisor/host somehow initiated my VPS to provide its storage over network for them to access? I understand they own the storage and can already access it in other ways.

This is what popped up in dmesg:

[3240105.606997] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel@redhat.com
[3240107.026053] SGI XFS with ACLs, security attributes, realtime, no debug enabled
[3240107.066073] JFS: nTxBlock = 8192, nTxLock = 65536
[3240107.129470] QNX4 filesystem 0.2.3 registered.
[3240107.220733] raid6: sse2x1   gen()  5791 MB/s
[3240107.296739] raid6: sse2x1   xor()  4571 MB/s
[3240107.364749] raid6: sse2x2   gen()  9875 MB/s
[3240107.432744] raid6: sse2x2   xor()  5724 MB/s
[3240107.508740] raid6: sse2x4   gen() 11442 MB/s
[3240107.576734] raid6: sse2x4   xor()  6423 MB/s
[3240107.644738] raid6: avx2x1   gen() 11982 MB/s
[3240107.720722] raid6: avx2x1   xor()  6473 MB/s
[3240107.788733] raid6: avx2x2   gen() 13211 MB/s
[3240107.856730] raid6: avx2x2   xor()  7007 MB/s
[3240107.928766] raid6: avx2x4   gen() 14601 MB/s
[3240107.996734] raid6: avx2x4   xor()  7916 MB/s
[3240107.997462] raid6: using algorithm avx2x4 gen() 14601 MB/s
[3240107.998403] raid6: .... xor() 7916 MB/s, rmw enabled
[3240107.999125] raid6: using avx2x2 recovery algorithm
[3240108.008931] xor: automatically using best checksumming function   avx       
[3240108.111246] Btrfs loaded, crc32c=crc32c-intel
[3240108.129825] fuse init (API version 7.27)

Edit: title and premise is probably a misunderstanding on my behalf. What appears to be happening is that either the kernel for some reason suddenly loaded a few storage-related modules, or perhaps new hardware was connected to the host server while running.

  • 1
    I don't see any mounting here. Various modules getting initialized, nothing else. And nothing network-related at all. – Nikita Kipriyanov Mar 11 '23 at 14:12
  • @NikitaKipriyanov OK, but how and why? I presume they manifested suddenly on the running kernel at 37 days of uptime for a reason. – Speed Dial Dave Mar 11 '23 at 14:15
  • Is this some kind of a container-based system? Then *other* container (probably "root" system) might be doing something, but since all containers share the kernel, whole system has only one set of modules, when the module gets loaded, all containers suddenly realize it appeared. In properly set up system you simply can't see dmesg from non-privileged containers, because it's not your business. – Nikita Kipriyanov Mar 11 '23 at 14:18
  • @NikitaKipriyanov As far as I understand it's not container-based, but I cannot be sure. dmesg mentions: "efi: EFI v2.70 by EDK II", "DMI: Scaleway SCW-DEV1-MICRO, BIOS 0.0.0 02/06/2015", "Hypervisor detected: KVM" and other non-container-y things. – Speed Dial Dave Mar 11 '23 at 14:33
  • You won't see that in dmesg. As I said, they share the kernel, so there is just one kernel log (which you see with dmesg), and all the containers see the same thing. You must just know. And VPS's almost always container-based which is **not** a virtualization, so there is no concept of hypervisor and the like. The whole question seems to me a very off topic, at least, in a way it is formulated. – Nikita Kipriyanov Mar 11 '23 at 14:35
  • @NikitaKipriyanov I can update and reboot to whichever kernel version I want. This is Debian 10 with all regular updates provided on "main" branch/repository. It's not locked to launch from some "boot script" with specific host-provided kernel. If this matters. – Speed Dial Dave Mar 11 '23 at 14:47
  • There's still nothing interesting in that log. There's no mounting going on. It's initialization of modules. – vidarlo Mar 11 '23 at 17:32
  • If you own this system, you need to determine why some modules were initialized so late after boot. Usually this kind of initialization happens during boot; we can't know what was going in your system, but it's possible to trigger by just loading modules anytime using insmod or modprobe. In any case, the log you provided is **not related to mounting** and **not related to network**, there is nothing in common with the question title. If you want to have useful answers, please, ask the coherent question. Your hypotheses need to be at least in theory related to what you see. – Nikita Kipriyanov Mar 11 '23 at 17:45
  • Again, this could be expected in VPS, because those are usually containers and you don't control what's going in root namespace of the system. If you're not the owner/operator of the *hardware*, dmesg is none of your business. It's wrong even that you are able to see it, and this automatically means any question about what you can see in it while only having an access to the VPS is incorrect and won't be answered here. – Nikita Kipriyanov Mar 11 '23 at 17:46

0 Answers0