Boot space too small #55
Conversation
This reverts commit 66dd8d4. If there is an extra boot partition and it's too small we are not able to install the migration system and the customer will not be able to use the migration concept. The image is usually around ~300MB of size and that can often be too much for an extra boot partition which is often designed to be small
The live migration image gets installed to the system again because of the space limitation on /boot. This affects the menuentry created on grub side in a way that we can't use the pre-allocated pointer to the boot device but have to search the root partition like in a real grub root entry. This patch adds the needed code changes to locate the root part, insert the needed filesystem module and initializes the root variable to allow the loopback loading of the image. This Fixes #54
schaefi
force-pushed
the
boot_space_too_small
branch
from
4427f84
to
72378fb
Compare
|
This should work but hasn't been tested on all clouds. There is a case where it will not work and this is if the used filesystem is not supported by grub or cannot be read for other reasons e.g because root is encrypted. So we are limiting the concept here which should be clear to everybody. However the limitation of the boot partition being too small will happen more often than the case that the rootfs can't be read by grub. Thoughts |
I agree with being clear about it, but do we want to deal with filesystems that are not supported by grub ?
It makes sense to me to cover the more common scenario. |
As of today there are none. But regarding xfs and also btrfs grub was late supporting them. So there might be the situation that a filesystem becomes popular and is supported on the kernel side but has no native support from the bootloader side. This scenario was often supported in the past by distributions. From a support point of view the answer is yes I see the trouble more in the area of rootfs encryption. With the design before we would have kept the opportunity to upgrade such systems as well because /boot is never part of the encrypted area. There would still be the question how to ask for the password but at least a possible path to success exists. Once we merge this we are no longer able to support it. We have no customer for this scenario yet but at least Azure invests into encrypted instances
Same here |
|
I know I'm constructing corner cases but as we write documentation about the upgrade concept we should list what is possible and what not. The standard way "put the shiny CD in and run through the process" surely supports upgrade of encrypted systems. Our way would not support it and that is definitely worth a note in the documentation |
|
If we agree to merge this I would add a short note in the #41 to remember |
|
FYI SLE no longer supports /boot on s separate FS. But we obviously still build images that way, so we need to support this. |
This patch is two fold:
Add rootpart detection to grub activation script
The live migration image gets installed to the system again because of the space limitation on /boot. This affects the menuentry created on grub side in a way that we can't use the pre-allocated pointer to the boot device but have to search the root partition like in a real grub root entry. This patch adds the needed code changes to locate the root part, insert the needed filesystem module and initializes the root variable to allow the loopback loading of the image.
Revert location change from /usr/share to /boot
This reverts commit #66dd8d4943d38f121f4b16b70bf0ab8d0b2ec82d. If there is an extra boot partition and it's too small we are not able to install the migration system and the customer will not be able to use the migration concept. The image is usually around ~300MB of size and that can often be too much for an extra boot partition which is often designed to be small
This Fixes #54