BYOI and multiple disks: unused disks may prevent boot#8837
BYOI and multiple disks: unused disks may prevent boot#8837outtersg wants to merge 1 commit intoovh:developfrom
Conversation
In the warning about RAID, tell about unitialized unused disks potentially preventing boot (see https://community.ovhcloud.com/community/fr/freebsd-en-cloudinit-marchait-en-mars-ne-marche-plus-en-decembre?id=community_question&sys_id=da84c34985353654476bb1da92914b4f for details) Reorder the RAID warning starting with the (short) hardware RAID section, and detail the complex case of soft RAID at the end
sbraz
left a comment
sbraz
left a comment
There was a problem hiding this comment.
Thanks for the contribution, I'll report back as soon as I've been able to perform more tests on old legacy boot boards like yours.
| > | ||
| > - Hardware RAID is supported, if your server supports it, because it is configured before the image is deployed on disk. | ||
| > - If you stay with BYOI, the image will only get deployed to the first disk, other disks will be left unmodified.\ | ||
| > However some motherboards will not boot with uninitialized disks: if your server does not respond to pings, please verify that your unused disks are minimally partitioned.\ |
There was a problem hiding this comment.
I'd like to perform more tests before adding that sentence to the doc. I'll try to do it this week if I can.
There was a problem hiding this comment.
Hi @outtersg, I'm sorry I haven't had time to look into this yet. I haven't forgotten the PR or the issue you raised. I will look into it as soon as possible.
There was a problem hiding this comment.
Thanks for the following up!
Meanwhile I wreaked the machine twice, trying to make the second disk a gmirror of the first, and the third a rescue OS, in theory all 3 bootable: this didn't worked well, and I ended up with a (now stable) machine with only the data partition of disk1 gmirrored, and avoiding an ESP on disk3 (that seemed to prevent booting too).
The good news is I became somewhat "fluent" in using parted / gpart to quickly recover the machine (with the help of a customized MFSBSD image, HTTPS-hosted on my other Kimsufi and thus iPXE-reachable, that served as a FreeBSD rescue OS).
So even if the diagnosis is still difficult, at least the medication works well.
| > - Bring Your Own Image (BYOI) does not support software RAID configuration at install-time, but you can use the service [Bring Your Own Linux (BYOLinux)](/pages/bare_metal_cloud/dedicated_servers/bring-your-own-linux) for that. Choose the custom image method that fits your needs: [Bring Your Own Image (BYOI) / Bring Your Own Linux (BYOLinux), a comparison sheet](/pages/bare_metal_cloud/dedicated_servers/bring-your-own-image-versus-bring-your-own-linux). | ||
| > | ||
| > - Hardware RAID is supported, if your server supports it, because it is configured before the image is deployed on disk. | ||
| > - If you stay with BYOI, the image will only get deployed to the first disk, other disks will be left unmodified.\ |
There was a problem hiding this comment.
That was definitely missing from the doc, thanks!
Y0Coss
added
Test required
3 participants
What type of Pull Request is this?
Description
As shown in a Community discussion with @sbraz about a BYOI install not working anymore,
the RAID-ready secondary disks that are left unmodified in a BYOI installation may prevent booting, with no hint on what is stuck (on a non-KVM machine).
This PR adds the minimal info to help detect and solve this problem.
Hesitations
<sup><sub></sub></sup>) were not as clean as one would hope: do OVH Docs have a way to reduce some paragraph's text size?Mandatory information
The translations in this Pull Request have been done using:
OVHcloud integrated translation LLM
Systran
Other tool (my hands and brain)
This Pull Request didn't require any translation.
This Pull Request can be merged as soon as possible.