This repository has been archived by the owner on Jan 16, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 72
Disk Resize might break FreeBSD #298
Comments
Output should look like this now after a resize is triggered on OpenNebula
|
dann1
added a commit
to dann1/docs
that referenced
this issue
Jun 2, 2023
dann1
added a commit
that referenced
this issue
Jun 7, 2023
dann1
added a commit
that referenced
this issue
Jun 7, 2023
dann1
added a commit
to dann1/docs
that referenced
this issue
Jun 7, 2023
rsmontero
pushed a commit
that referenced
this issue
Jun 7, 2023
tinova
pushed a commit
to OpenNebula/docs
that referenced
this issue
Jun 12, 2023
Improve resize doc
tinova
pushed a commit
to OpenNebula/docs
that referenced
this issue
Jun 12, 2023
Improve resize doc (cherry picked from commit 9b8f83b)
tinova
pushed a commit
to OpenNebula/docs
that referenced
this issue
Jun 12, 2023
Improve resize doc (cherry picked from commit 9b8f83b)
tinova
pushed a commit
to OpenNebula/docs
that referenced
this issue
Jun 12, 2023
Improve resize doc (cherry picked from commit 9b8f83b)
tinova
pushed a commit
to OpenNebula/docs
that referenced
this issue
Jun 12, 2023
Improve resize doc (cherry picked from commit 9b8f83b)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When issuing a
onevm disk-resize
to a FreeBSD VM, the image OS will corrupt the FS and the VM will no longer be usable. This can happen with both live and POWEROFF resize. When live resize is issued the contextualization will not trigger automatically, but it can be triggered withonevm updateconf
.The problem lies in the execution of
/etc/rc.d/growfs onestart
triggered by the contextualization service. The problem even happens when commenting out such code and adding it to the START_SCRIPT instead, which is executed lastly by the contextualization service. Looks like some sort of race condition.Executing this command manually inside the OS after a disk resize has been issued on the hypervisor doesn't seem to cause the FS corruption. The official FreeBSD documentation mentions this is a possibility.
Since there is a manual workaround and extremely high risk, the feature will be disabled for FreeBSD.
The text was updated successfully, but these errors were encountered: