Open fake-name opened 1 year ago
This is due to the userspace tools from Fusion-io (fio-sure-erase, fio-format, etc.) which don't know about modern kernels. Since the userspace tools are not open/visible source, we have no way of updating them.
The workaround (and I admit it's a pain) is to boot to a lower kernel, run the tools, then boot back into your OS.
This is where the whole concept of keeping these cards alive is going to hit a brick wall.
My suggestion for folks who are just trying to run some sort of rig to do X, is go back to an older kernel. Unless you need the latest kernel for your project, why go to it? 5.15 is actually EOL before 5.10 as 5.10 is considered more of a long term release.
Ah, good to know.
This is kind of a silly project, so I'll just switch to Debian 10 for the OS.
My suggestion for folks who are just trying to run some sort of rig to do X, is go back to an older kernel. Unless you need the latest kernel for your project, why go to it? 5.15 is actually EOL before 5.10 as 5.10 is considered more of a long term release.
Apparently the Proxmox people are shipping 5.15 on top of Debian 11, which caught me out a bit. I believe Debian 11 is supposed to be based off 5.10, but I didn't really consider the platform as much as I probably should have.
Apparently the Proxmox people are shipping 5.15 on top of Debian 11, which caught me out a bit. I believe Debian 11 is supposed to be based off 5.10, but I didn't really consider the platform as much as I probably should have.
and Here I am on PVE kernel 6.1 due to my hardware being EPYC and the performance is there for EPYC, I dont have my fio drive in it however, just adding my 2 cents, its an opt-in kernel, might wanna poke the bear if you really wanted to see if your mem issue goes away
The userspace tools are doing things the newer kernels don't like. I doubt that the kernel devs are going to go backwards in security. The expectation is that apps get rewritten. But the userspace tools are not ours to rewrite.
FYI, I got usercopy: Kernel memory overwrite attempt detected to SLUB object 'fusion_user_ll_request'
error using Debian "Bullseye" which had kernel 5.10.0-26-amd64
. Wondering how far back I need to go to get a working fio-sure-erase
. I previously built an image using "Bookworm" which has a 6.x kernel but after finding this issue tried a 5.10 kernel but still no-dice.
@bdurrow if you want the "safest" option use CentOS 7 combined with the more or less vanilla driver source branch. For vsl that would be fio-3.2.16.1732
and for vsl4 fio-original-4.3.7.1205
.
It's not just kernel version dependent, but depends on if the CONFIG_HARDENED_USERCOPY
flag has been set during compilation of the kernel. This varies per distro and version it seems. Kernels prior to introducing the flag, or distributions that have the flag turned off work.
@snuf , Thank you. You probably just saved me another day of frustration, maybe two. My goal is to roll a bootable iso so that I can use the tools. Do you know of one that already exists? If not I'll see about hosting my work so others can use it in the future. Would you like to link to it if I do that?
@bdurrow we were kicking around the idea of creating one for a while, but it's not manifested itself yet. Probably due to life, the universe and everything. I have most of the bits and pieces to go into it I guess, but keep overthinking it probably.
If you have something, and a link I think that would help some folks :)
Bug description
From the title. I'm trying to recover a ioDrive2 with a missing LEB map:
How to reproduce
Built from the current HEAD: f3a056d56e2ff3353cf5fb9c0e2a48f0fb0aebd7 using DKMS
The erase then seems to either take a LONG time, or not make any progress (it's still at 0% after about an hour).
Possible solution
No idea
Environment information
Please excuse the host name, I'm trying to redneck a flash-SAN out of (mostly) used bitcoin miner parts (it's cheap!). The name amuses me. FWIW, it's a cheap way to get 5 PCIe 8x slots, particularly when it's $43 with the CPU on ebay.
Yes, there are 2 ioDrives in this system. I'm dealing with
/dev/fct1
here.The host OS is actually Proxmox 7.3.