In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Hey everyone, just getting caught up. I haven't gotten a reply from VF, but it is the weekend. It seems like the templates are a no go though right now. I did see some success with the people using the netboot option though which is interesting. Let me know if there are any items I need to test on the Hypervisor side.
@emperor said:
If anyone struggle with ipv6 setup on Ohio network, just set the prefixlen to 48 instead 64 . In Arizona was working fine with 64 prefixlen.
It is the same thing in TX, /64 doesn't work even though the panel tells you that. 48 will make the default router pingable, but traffic doesn't seem to go further than that though.
@Crab if you already set ipv6_defaultrouter in rc.conf can you try issuing this to see if its gonna work? I remember i needed to do it manual as something is broken and rc not setting it up as default only adding it as route.
route -6 add default ipv6_defaultrouter (replace ipv6_defaultrouter with the actual default route from linveo control panel )
@emperor said: @Crab if you already set ipv6_defaultrouter in rc.conf can you try issuing this to see if its gonna work? I remember i needed to do it manual as something is broken and rc not setting it up as default only adding it as route.
route -6 add default ipv6_defaultrouter (replace ipv6_defaultrouter with the actual default route from linveo control panel )
Interesting, that made it work! It has worked well elsewhere for me just by using rc.conf and without any manual route setting, so it didn't even cross my mind. I was automatically expecting something to be wrong in the environment. Thanks for the tip!
You are welcome. I don't think this will keep running after reboot (haven't made reboot yet), so adding simple rc.local file will fix broken ipv6 after reboot.
@emperor said: @Crab if you already set ipv6_defaultrouter in rc.conf can you try issuing this to see if its gonna work? I remember i needed to do it manual as something is broken and rc not setting it up as default only adding it as route.
route -6 add default ipv6_defaultrouter (replace ipv6_defaultrouter with the actual default route from linveo control panel )
I've never been a fan of how VF handles the /64 routes. It points to the gateway of the /48 parent block instead of creating a new one. It seems to work ok on Linux. I haven't tested on Windows though.
@linveo said: Let me know if there are any items I need to test on the Hypervisor side.
It's a bit hard to say as I don't really know what you can reasonably test on the Hypervisor side.
With NetBSD the current status is that the images work fine with a standard qemu (at least to the point that it successfully boots), but when trying to run them under VirtFusion, we seem to get a kernel panic (but without any console output) very early from the NetBSD kernel. So one thing that would be useful would be the exact qemu options VirtFusion is using (which might help in reproducing the issue and understanding what's responsible for the kernel panic). Another thing is that VirtFusion configures a serial port for the VM, but it's not clear where the output from that serial port ends up - if using the serial port as a console, the kernel panic will probably be written there (and knowing what NetBSD complains about would be extremely helpful).
Here might be an interesting NetBSD install method:
# From Linux to NetBSD, with SSH Only
remote NetBSD install with pivot root pivot_root
https://news.ycombinator.com/item?id=41041995
https://cloudbsd.xyz/
@Not_Oles said:
Here might be an interesting NetBSD install method:
# From Linux to NetBSD, with SSH Only
remote NetBSD install with pivot root pivot_root
https://news.ycombinator.com/item?id=41041995
https://cloudbsd.xyz/
@linveo I guess you would have said something if you heard back from Virtfusion. Should we conclude that there is no simple and easy way to get OpenBSD or NetBSD via Virtfusion?
FreeBSD is installed on my VM. I like FreeBSD. But installing also is fun! I wonder if there is a good way to go directly from FreeBSD to NetBSD or OpenBSD and back?
Alternatively, @linveo is it okay for me to change my VM to Debian so that I can try following the cloudbsd.xyz install?
FreeBSD works great on the Linveo instance and I'm very happy with its performance. Network is snappy and the node doesn't feel like it is crowded at all. Disk I/O is superfast. With both Root-on-ZFS and swap encryptions there's no noticeable performance loss. Even dd results are similar! Very impressive.
I definitely want to see OpenBSD and NetBSD both working here, but looks like we're at the mercy of VirtFusion. The problem must be something pretty simple and trivial since it is all just QEMU after all and it should support this just fine.
I believe after the core kernel loading it should start loading all the modules that are not compiled in and there it just throws the towel in either at the 9660.kmod or whatever it tries to load after that. My guess is that the 9660.kmod throws it off. Perhaps the virtio drivers are to blame...
@Not_Oles said:
Here might be an interesting NetBSD install method:
# From Linux to NetBSD, with SSH Only
remote NetBSD install with pivot root pivot_root
https://news.ycombinator.com/item?id=41041995
https://cloudbsd.xyz/
@linveo I guess you would have said something if you heard back from Virtfusion. Should we conclude that there is no simple and easy way to get OpenBSD or NetBSD via Virtfusion?
FreeBSD is installed on my VM. I like FreeBSD. But installing also is fun! I wonder if there is a good way to go directly from FreeBSD to NetBSD or OpenBSD and back?
Alternatively, @linveo is it okay for me to change my VM to Debian so that I can try following the cloudbsd.xyz install?
It's been radio silent on the BSD templates. It doesn't seem well supported. Sure you can use any template you want now. I was hoping to get some good results with the other versions, but I have retired the templates for now.
For anyone who doesn't mind playing: your mission, should you choose to accept it..
Using FreeBSD (as that's appears to be the easiest to get running), install webmin along with an appropriate firewall, with webmin working GUI.
On the face of it, I'd prefer ipfw but the webmin GUI has a severe memory leak/resource issue whenever it's selected. Perhaps it's just my installation.
Any words of wisdom, will be appreciated. Yup, I could mess around in a shell prompt but life's too short/other things to do.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
I noticed Linveo VirtFusion panel had changed its appearance, so I was wondering if a newer version was installed with potentially better support, but booting NetBSD and OpenBSD ISOs failed the same old way.
As I mentioned just above, From Linux to NetBSD, with SSH only looks really cool to me! Today I got a chance to watch the demo video on cloudbsd.xyz. I think I am really gonna try it on my Linveo VM and maybe also on a Hetzner dedi. There are quite a few steps in the procedure that I never used before. For example, there is a systemctl isolate command. I never used systemctl isolate. Is anyone else interested in trying this cool NetBSD install method?
@Crab said:
I noticed Linveo VirtFusion panel had changed its appearance, so I was wondering if a newer version was installed with potentially better support, but booting NetBSD and OpenBSD ISOs failed the same old way.
We did upgrade to VF 5.0 which brings a lot of changes. One of them to note for the FreeBSD crowd:
Added support for FreeBSD memory usage display.
There are some behind the scenes setting changes, so I am taking a look to see if there is anything to help with the current issues.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
I tried this out since I was curious about its implementation. By default it is trying to access /proc/meminfo which works fine in Linux but doesn't exist in *BSD out of the box. It actually uses freecolor for the memory information on FreeBSD and the VF panel shows the memory information just fine with it.
So people who might've done an ISO install, you'll need to install qemu-guest-agent and freecolor from packages to make it work.
I think I managed to extract the NetBSD kernel panic now. This is possible by using grub2 to read the memory where NetBSD formats the panic string. Essentially, what you need to do is look at either the netbsd.map file or the output of nm netbsd and look for the address of panicstr (but only use the lower 28 bits of that address - the memory contents there point to the address of the actual string, again only use the lower 28 bits of that address).
So, I boot a NetBSD kernel in grub2 via knetbsd, it immediately reboots and in grub I then do:
@Not_Oles said: Is anyone else interested in trying this cool NetBSD install method?
Goes off to break something..
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Somehow, after a few hiccups, I got NetBSD to boot and install, via Linux (Debian 11). This was on an idle Virmach VPS with plenty of resources - now to try the same on the Linveo one..
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
I'm kinda pee'd off 'cos after trying numerous failures, I didn't have the exact steps that finally got this to work, on the Virmach VPS. So now, I'm struggling to recreate it on the Linveo one. Primarily due to me making changes directly in grub boot, editing the default (Debian) boot, then hitting F10. :'(
It went along the lines of the following, though here, showing an addition to /etc/default/grub..
I'll see if I can glean some clues from the Virmach instance eg. bootlog
It was a simple process, at least on the Virmach VPS and didn't need any fakeroot or similar. The network didn't autoselect at first but I remained in the installation TUI and (re-)chose network setup, which did pick up the virtual NIC and subsequent DHCP.
Gawd, the benefit of hindsight.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Haven't found much more, though in /var/log/messages:
NetBSD 10.0 (INSTALL) #0: Thu Mar 28 08:33:33 UTC 2024 [email protected]:/usr/src/sys/arch/amd64/compile/INSTALL
Whereas post install/reboot:
NetBSD 10.0 (GENERIC) #0: Thu Mar 28 08:33:33 UTC 2024 [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Goes off to try the above with VirtFusion (again)..
.. retried with Linveo and the installation kernel doesn't startup (looping back to grub). So it looks as though there's a fundamental difference (perhaps a setting like pass-through) in Virtfusion, compared to both SolusVM and Proxmox hypervisors.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@AlwaysSkint said:
.. retried with Linveo and the installation kernel doesn't startup (looping back to grub). So it looks as though there's a fundamental difference (perhaps a setting like pass-through) in Virtfusion, compared to both SolusVM and Proxmox hypervisors.
@cmeerw said: That's what I have been talking about here all the time.
Apologies but it was a little bit too cryptic for my advancing years. Now that I re-read your posts, I can see how it fits in. I know, it has taken me a while to reach the same point, though in my defense, it was from a position of no experience with BSD. Thanks for your efforts, of course, and I'll perhaps give your fix a try - setting up for a custom kernel takes quite a bit of time/effort. It may be interesting/useful if @linveo divulged the VF settings used when defining a VM, as a fix at source strikes me as the way to go.
Has anyone got a VM that uses Virtfusion, at a different provider?
[Edit:typos - Grr, laptop keyboard]
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@cmeerw said: That's what I have been talking about here all the time.
Apologies but it was a little bit too cryptic for my advancing years. Now that I re-read your posts, I can see how it fits in. I know, it has taken me a while to reach the same point, though in my defense, it was from a position of no experience with BSD. Thanks for your efforts, of course, and I'll perhaps give your fix a try - setting up for a custom kernel take quite a bit of time/effort. It may be interesting/useful if @linveo divulged the VF settings used when defining a VM, as a fix at source strikes meas the way to
go.
Has anyone got a VM that uses Virtfusion, at a different provider?
BTW, as far as I understand the code, it also only affects Intel CPUs (AMD should be fine).
Ideally, NetBSD should be able to handle this case more gracefully, so I have brought it up on their tech-kern mailing list yesterday.
Makes sense that the two working VM that I have are both on (different) AMD CPUs.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@cmeerw said: I have now managed to install NetBSD 10.0 with such a modified kernel
Can your kernel be made available?
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
BTW, a relatively easy way to then install NetBSD is to put that (gunzipped) kernel file into a (relatively small) separate partition on the VM (not sure which filesystems the NetBSD loader supports - I had put it into a FFS partition). You can then use the installer image https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/amd64/installation/cdrom/boot.iso and in the NetBSD loader boot the patched kernel instead (but then select the installer CD as the root device). Once the installation is complete, you again need to tell the NetBSD loader to use the patched kernel again. Then just copy the patched kernel into /netbsd (and you can then re-use the separate kernel partition as swap)
Crikey! Glad that you didn't tell us a more difficult way!
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
It seems like there might be more success with AMD CPUs? If anyone wants to change their VM type from Intel to AMD let me know and I can switch it for you. I appreciate all of the feedback I've received so far.
@linveo said: If anyone wants to change their VM type from Intel to AMD let me know..
I'll go for it; makes no odds to me. :-)
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@cmeerw said: BTW, as far as I understand the code, it also only affects Intel CPUs (AMD should be fine).
@linveo said: If anyone wants to change their VM type from Intel to AMD let me know and I can switch it for you.
@linveo Thanks for offering migration! Assuming that the issue at hand would affect any method of NetBSD install under Virtfusion (because Virtfusion, or Qemu under Virtfusion, apparently doesn't report or doesn't correctly report data that the NetBSD kernel needs) I also am going to say yes to migrating to AMD.
Please simply wipe my existing VM without further notice and please send me login info for the AMD VM. Or whatever else works for you. Also, no rush.
If Phoenix is okay for AMD, then I'd love to stay in Phoenix, which offers the lowest latency for me. But any other location is equally great!
^ I've powered down and willing to start from scratch too. Given location is across The Pond, then anywhere will do ( though CA is never good due to the prominence of Asian traffic).
I would've too had I found a replacement job, post redundancy. Heat City, Arizona!
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@cmeerw said: BTW, as far as I understand the code, it also only affects Intel CPUs (AMD should be fine).
@linveo said: If anyone wants to change their VM type from Intel to AMD let me know and I can switch it for you.
@linveo Thanks for offering migration! Assuming that the issue at hand would affect any method of NetBSD install under Virtfusion (because Virtfusion, or Qemu under Virtfusion, apparently doesn't report or doesn't correctly report data that the NetBSD kernel needs) I also am going to say yes to migrating to AMD.
Please simply wipe my existing VM without further notice and please send me login info for the AMD VM. Or whatever else works for you. Also, no rush.
If Phoenix is okay for AMD, then I'd love to stay in Phoenix, which offers the lowest latency for me. But any other location is equally great!
Thanks again! Kindest regards!
There are AMD nodes in all the DCs, so I have migrated your VMs over to them as they were with the same IP. Hopefully this ends up being more fruitful.
Comments
Trying some older NetBSD installation images, and with 4.0.1 it gets a bit further up to:
Maybe newer versions have the same issue, but just reboot way earlier?
https://man.netbsd.org/NetBSD-10.x-BRANCH/boot.8 might glean some clues?
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Hey everyone, just getting caught up. I haven't gotten a reply from VF, but it is the weekend. It seems like the templates are a no go though right now. I did see some success with the people using the netboot option though which is interesting. Let me know if there are any items I need to test on the Hypervisor side.
linveo.com | Shared Hosting | KVM VPS | Dedicated Servers
If anyone struggle with ipv6 setup on Ohio network, just set the prefixlen to 48 instead 64 . In Arizona was working fine with 64 prefixlen.
ServerStatus , slackvpn , linux mirrors
Recommended Providers: Servarica(aff) | HostBRR(aff) | SolidVPS(aff) | RackNerd(aff) | KuroIT(aff) | AlphaVPS(aff) | HostDare(aff)
It is the same thing in TX, /64 doesn't work even though the panel tells you that. 48 will make the default router pingable, but traffic doesn't seem to go further than that though.
@Crab if you already set ipv6_defaultrouter in rc.conf can you try issuing this to see if its gonna work? I remember i needed to do it manual as something is broken and rc not setting it up as default only adding it as route.
route -6 add default ipv6_defaultrouter (replace ipv6_defaultrouter with the actual default route from linveo control panel )
ServerStatus , slackvpn , linux mirrors
Recommended Providers: Servarica(aff) | HostBRR(aff) | SolidVPS(aff) | RackNerd(aff) | KuroIT(aff) | AlphaVPS(aff) | HostDare(aff)
Interesting, that made it work! It has worked well elsewhere for me just by using rc.conf and without any manual route setting, so it didn't even cross my mind. I was automatically expecting something to be wrong in the environment. Thanks for the tip!
You are welcome. I don't think this will keep running after reboot (haven't made reboot yet), so adding simple rc.local file will fix broken ipv6 after reboot.
ServerStatus , slackvpn , linux mirrors
Recommended Providers: Servarica(aff) | HostBRR(aff) | SolidVPS(aff) | RackNerd(aff) | KuroIT(aff) | AlphaVPS(aff) | HostDare(aff)
I've never been a fan of how VF handles the /64 routes. It points to the gateway of the /48 parent block instead of creating a new one. It seems to work ok on Linux. I haven't tested on Windows though.
linveo.com | Shared Hosting | KVM VPS | Dedicated Servers
It's a bit hard to say as I don't really know what you can reasonably test on the Hypervisor side.
With NetBSD the current status is that the images work fine with a standard qemu (at least to the point that it successfully boots), but when trying to run them under VirtFusion, we seem to get a kernel panic (but without any console output) very early from the NetBSD kernel. So one thing that would be useful would be the exact qemu options VirtFusion is using (which might help in reproducing the issue and understanding what's responsible for the kernel panic). Another thing is that VirtFusion configures a serial port for the VM, but it's not clear where the output from that serial port ends up - if using the serial port as a console, the kernel panic will probably be written there (and knowing what NetBSD complains about would be extremely helpful).
I was able to get a screenshot of 9.4 just before the reboot and it was showing
WARNING: couldn't open /var/db/entropy-file
Loading /stand/amd64/9.4/modules/cd9660/cd9660.kmod
just before it crashes. Perhaps the kernel is not able to load the module and panics?
I wonder if that's maybe still coming from the loader (just before passing control to the kernel), not the kernel yet?
Here might be an interesting NetBSD install method:
@linveo I guess you would have said something if you heard back from Virtfusion. Should we conclude that there is no simple and easy way to get OpenBSD or NetBSD via Virtfusion?
FreeBSD is installed on my VM. I like FreeBSD. But installing also is fun! I wonder if there is a good way to go directly from FreeBSD to NetBSD or OpenBSD and back?
Alternatively, @linveo is it okay for me to change my VM to Debian so that I can try following the cloudbsd.xyz install?
FreeBSD works great on the Linveo instance and I'm very happy with its performance. Network is snappy and the node doesn't feel like it is crowded at all. Disk I/O is superfast. With both Root-on-ZFS and swap encryptions there's no noticeable performance loss. Even dd results are similar! Very impressive.
I definitely want to see OpenBSD and NetBSD both working here, but looks like we're at the mercy of VirtFusion. The problem must be something pretty simple and trivial since it is all just QEMU after all and it should support this just fine.
Sorry I forgot to reply to this earlier. It should be past the initial kernel loading as it shows the progress and ends at
18482656+671680+1425472 [871029+1254864+897200]=0x16e2aa0.
I believe after the core kernel loading it should start loading all the modules that are not compiled in and there it just throws the towel in either at the 9660.kmod or whatever it tries to load after that. My guess is that the 9660.kmod throws it off. Perhaps the virtio drivers are to blame...
It's been radio silent on the BSD templates. It doesn't seem well supported. Sure you can use any template you want now. I was hoping to get some good results with the other versions, but I have retired the templates for now.
linveo.com | Shared Hosting | KVM VPS | Dedicated Servers
For anyone who doesn't mind playing: your mission, should you choose to accept it..

Using FreeBSD (as that's appears to be the easiest to get running), install webmin along with an appropriate firewall, with webmin working GUI.
On the face of it, I'd prefer ipfw but the webmin GUI has a severe memory leak/resource issue whenever it's selected. Perhaps it's just my installation.
Any words of wisdom, will be appreciated. Yup, I could mess around in a shell prompt but life's too short/other things to do.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
I noticed Linveo VirtFusion panel had changed its appearance, so I was wondering if a newer version was installed with potentially better support, but booting NetBSD and OpenBSD ISOs failed the same old way.
As I mentioned just above, From Linux to NetBSD, with SSH only looks really cool to me! Today I got a chance to watch the demo video on cloudbsd.xyz. I think I am really gonna try it on my Linveo VM and maybe also on a Hetzner dedi. There are quite a few steps in the procedure that I never used before. For example, there is a
systemctl isolatecommand. I never usedsystemctl isolate. Is anyone else interested in trying this cool NetBSD install method?We did upgrade to VF 5.0 which brings a lot of changes. One of them to note for the FreeBSD crowd:
There are some behind the scenes setting changes, so I am taking a look to see if there is anything to help with the current issues.
linveo.com | Shared Hosting | KVM VPS | Dedicated Servers
^ I prefer the new layout, if nothing else.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
I tried this out since I was curious about its implementation. By default it is trying to access /proc/meminfo which works fine in Linux but doesn't exist in *BSD out of the box. It actually uses freecolor for the memory information on FreeBSD and the VF panel shows the memory information just fine with it.
So people who might've done an ISO install, you'll need to install qemu-guest-agent and freecolor from packages to make it work.
I think I managed to extract the NetBSD kernel panic now. This is possible by using grub2 to read the memory where NetBSD formats the panic string. Essentially, what you need to do is look at either the netbsd.map file or the output of
nm netbsdand look for the address ofpanicstr(but only use the lower 28 bits of that address - the memory contents there point to the address of the actual string, again only use the lower 28 bits of that address).So, I boot a NetBSD kernel in grub2 via
knetbsd, it immediately reboots and in grub I then do:This then gives me the hex dump of the panic message, which in my case is:
Guess I now just need to figure out what goes wrong there...
Congrats @cmeerw! Thank you so much for posting!
Goes off to break something..

In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
The Yeti has left the building.
The "obvious fix" of just adding:
seems to work and I have now managed to install NetBSD 10.0 with such a modified kernel.
But it looks like something is not being reported correctly (by the CPU/virtualised CPU) here.
Excellent discovery @cmeerw !
Looking at the kernel code at https://cdn.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/arch/x86/x86/cpu_topology.c lp_max means the maximum logical processors and core_max obviously maximum cores per package that it detects. If the former smaller value than the latter, kassert will issue a kernel panic.
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
FreeBSD detects 2 packages and 1 core which should be correct, but for NetBSD seems to detect it other way around.
Running cpuid in a Linux VM on that machine I get:
$ cpuid -1l1 | fgrep hyper-threadinghyper-threading / multi-core supported = falseSo lp_max = 1
$ cpuid -1l4 | fgrep "in pkg"maximum IDs for cores in pkg = 0xf (15)and core_max = 16
Somehow, after a few hiccups, I got NetBSD to boot and install, via Linux (Debian 11). This was on an idle Virmach VPS with plenty of resources - now to try the same on the Linveo one..
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Congrats on getting NetBSD up and running!
Wanna give us a hint, please, about the method you used to install NetBSD?
Maybe a link to a how to?
Maybe a sentence or two about the hiccups and what fixes you applied?
Thanks so much! Best wishes!
I'm kinda pee'd off 'cos after trying numerous failures, I didn't have the exact steps that finally got this to work, on the Virmach VPS. So now, I'm struggling to recreate it on the Linveo one. Primarily due to me making changes directly in grub boot, editing the default (Debian) boot, then hitting F10. :'(
It went along the lines of the following, though here, showing an addition to /etc/default/grub..
The uuid was taken from the existing Debian entries. The ramdisk.fs is intended to be a RAM-based installation kernel - though I wish I'd paid more attention to the exact one that worked.
My browser tabs include:
https://www.gnu.org/software/grub/manual/grub/grub.html#NetBSD
https://mirrors.mit.edu/NetBSD/NetBSD-10.0/amd64/installation/ramdisk/
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202409211400Z/amd64/binary/kernel/
I'll see if I can glean some clues from the Virmach instance eg. bootlog
It was a simple process, at least on the Virmach VPS and didn't need any fakeroot or similar. The network didn't autoselect at first but I remained in the installation TUI and (re-)chose network setup, which did pick up the virtual NIC and subsequent DHCP.
Gawd, the benefit of hindsight.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@AlwaysSkint
Thanks for the correction!
Thanks for the install info! More interesting stuff for me to try!
Haven't found much more, though in /var/log/messages:
Whereas post install/reboot:
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
..Much later. I created a new Debian 11 VM on my Proxmox server and booted it up.
'history'
!/bin/sh
exec tail -n +3 $0
This file provides an easy way to add custom menu entries. Simply type the
menu entries you want to add after this comment. Be careful not to change
the 'exec tail' line above.
menuentry 'NetBSD' {
load_video
insmod gzio
insmod part_gpt
insmod part_bsd
insmod xfs
insmod zfs
search --no-floppy --fs-uuid --set=root 2eb84507-bd74-432f-8bb3-c695f9xxxxxxx
echo 'Loading NetBSD ...'
knetbsd /netbsd-INSTALL.gz
}
As before UUID was copied from the default /etc/boot/grub.cfg entry.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Goes off to try the above with VirtFusion (again)..
.. retried with Linveo and the installation kernel doesn't startup (looping back to grub). So it looks as though there's a fundamental difference (perhaps a setting like pass-through) in Virtfusion, compared to both SolusVM and Proxmox hypervisors.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
That's what I have been talking about here all the time: https://lowendspirit.com/discussion/comment/186288/#Comment_186288 and https://lowendspirit.com/discussion/comment/186301/#Comment_186301
You'll need to compile the kernel with the change mentioned and use that kernel during installation.
Apologies but it was a little bit too cryptic for my advancing years. Now that I re-read your posts, I can see how it fits in.
I know, it has taken me a while to reach the same point, though in my defense, it was from a position of no experience with BSD.
Thanks for your efforts, of course, and I'll perhaps give your fix a try - setting up for a custom kernel takes quite a bit of time/effort. It may be interesting/useful if @linveo divulged the VF settings used when defining a VM, as a fix at source strikes me as the way to go.
Has anyone got a VM that uses Virtfusion, at a different provider?
[Edit:typos - Grr, laptop keyboard]
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
BTW, as far as I understand the code, it also only affects Intel CPUs (AMD should be fine).
Ideally, NetBSD should be able to handle this case more gracefully, so I have brought it up on their tech-kern mailing list yesterday.
Makes sense that the two working VM that I have are both on (different) AMD CPUs.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Can your kernel be made available?
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Yes: https://edge.cmeerw.net/netbsd-10.0-vm.gz
BTW, a relatively easy way to then install NetBSD is to put that (gunzipped) kernel file into a (relatively small) separate partition on the VM (not sure which filesystems the NetBSD loader supports - I had put it into a FFS partition). You can then use the installer image https://cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/amd64/installation/cdrom/boot.iso and in the NetBSD loader boot the patched kernel instead (but then select the installer CD as the root device). Once the installation is complete, you again need to tell the NetBSD loader to use the patched kernel again. Then just copy the patched kernel into /netbsd (and you can then re-use the separate kernel partition as swap)
Thanks @cmeerw!
Link for the curious:
https://mail-index.netbsd.org/tech-kern/2024/09/22/msg029737.html
Crikey! Glad that you didn't tell us a more difficult way!
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
It seems like there might be more success with AMD CPUs? If anyone wants to change their VM type from Intel to AMD let me know and I can switch it for you. I appreciate all of the feedback I've received so far.
linveo.com | Shared Hosting | KVM VPS | Dedicated Servers
I'll go for it; makes no odds to me. :-)
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
@linveo Thanks for offering migration! Assuming that the issue at hand would affect any method of NetBSD install under Virtfusion (because Virtfusion, or Qemu under Virtfusion, apparently doesn't report or doesn't correctly report data that the NetBSD kernel needs) I also am going to say yes to migrating to AMD.
Please simply wipe my existing VM without further notice and please send me login info for the AMD VM. Or whatever else works for you. Also, no rush.
If Phoenix is okay for AMD, then I'd love to stay in Phoenix, which offers the lowest latency for me. But any other location is equally great!
Thanks again!
Kindest regards! 
^ I've powered down and willing to start from scratch too. Given location is across The Pond, then anywhere will do ( though CA is never good due to the prominence of Asian traffic).
I would've too had I found a replacement job, post redundancy.
Heat City, Arizona!
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
There are AMD nodes in all the DCs, so I have migrated your VMs over to them as they were with the same IP. Hopefully this ends up being more fruitful.
linveo.com | Shared Hosting | KVM VPS | Dedicated Servers