Recent searches

No recent searches

Search options

Only available when logged in.
eupolicy.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
This Mastodon server is a friendly and respectful discussion space for people working in areas related to EU policy. When you request to create an account, please tell us something about you.

Administered by:

Server stats:

223
active users

eupolicy.social: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.1

#xcp

0 posts0 participants0 posts today
Paco Hope #resist

Anybody out there in #homelab land using #TrueNAS Scale with VMs?

I've built a nice, reliable NAS. And then I noticed that it could do VMs. Great! I thought. I have a couple different VMs running some important things like #HomeAssistant.

What I have discovered is that their VM support is terrible. Unless I misunderstand, I literally cannot do any of these things:

  • backup a VM
  • restore a VM
  • export a VM
  • import a VM
  • snapshot a VM

If I treat each VM like a full #linux host, I can back it up using something else (e.g., rsync). But if this was #xcp with Xen Orchestra, I'd have this whole thing solved in seconds.

I'm thinking about creating a big VM, running a nested hypervisor (XCP) and then running my VMs there. But that sounds like a huge faff. And even then, while I could snapshot the child VMs, that parent VM running the hypervisor would be hard to backup/restore.

I have plenty of RAM and spare CPU cycles on my NAS. But I've only recently understood how bad this VM support is. If I lost my HomeAssistant VM I'd cry.

Anybody have thoughts on this?
#selfhosting #selfhosted

Paco Hope #resist

If any #homelab folks have some spare disk space and bandwidth and want to help #resist, you can #selfhost an instance of ArchiveTeam Warrior as a VM.

The VM appliances are downloadable off of GitHub and then you just launch the VM and let it work.

If you use #xcp as your #xen hypervisor, and #xenorchestra to manage it, you might think you can just give it the GitHub URL and import. Sadly, no. I got an error. But the VM is only 165M, so if you download it to your laptop and then upload it via the XO web interface, it's trivial to launch.

wiki.archiveteam.orgArchiveTeam Warrior - Archiveteam
Replied in thread
LeoDJ

There's still a lot left to do.
I need to implement the #XCP stuff into the STM32 firmware, so it can run the #startergenerator stand-alone.
Stuff like:
- Checking the firmware version on the ECU, so it doesn't poke the wrong memory address
- Reading and parsing the status of the motor
- And actually controlling the motor properly instead of just sending it a hardcoded 1 Nm torque request :D

And then also cleaning it up enough, documenting and testing it thoroughly, so it can be published.

Replied in thread
LeoDJ

I spent many dozens of hours losing track of time in #Ghidra (I swear, it's worse than #Factorio)

Until I had figured out the #CAN message handling, signal parsing and where and when which #DTC codes get set.
With that knowledge I could figure out, slowly but surely, what the #startergenerator needs to run.
Even #FBS4 was pretty trivial to circumvent (a single 1 written to the right memory location via #XCP)

And after implementing the ~25 CAN messages in my STM32 code I finally got this today:

Replied in thread
LeoDJ

There is the CAN #XCP protocol (Universal Measurement and Calibration Protocol) which does pretty much what it sounds like. But it's usually locked down for production.
Fortunately, this was not the case for the BSG :D
I had to hack together my own XCP dump script and it took about 20 minutes to dump the first contiguous memory segment before the BSG reset the session. (CAN is slow ^^")
Now I had exactly 2 MiB worth of some kind of data, maybe/probably the flash contents.

TrendingLive feeds
About