Bug 1997805
| Summary: | coreos install boot order | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Vincent Rouleau <viro> | ||||||
| Component: | RHCOS | Assignee: | Benjamin Gilbert <bgilbert> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Michael Nguyen <mnguyen> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 4.8 | CC: | dornelas, jligon, miabbott, mrussell, nstielau, rfreiman, travier | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | 4.9.0 | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2021-08-31 17:19:11 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Vincent Rouleau
2021-08-25 20:09:22 UTC
Created attachment 1817572 [details]
journal -b of installation
Please fill out the entire form from the new bug template. coreos-installer is not used for RHCOS update thus I'm not sure I understand your use case. What are those reinstalled scripts for? updated description What's the problem you're trying to solve when re-installing RHCOS for updates? RHCOS is able to update itself and you do not need to reinstall using a newer version during OCP updates. It is recommended to only use the version used for the initial installation for node installation as the nodes will auto-update on first boot to the latest version. Mind you. this is for our internal regression testing suite, where we re-install over and over via Jenkins suite. So on a daily basis, we have about 6 cluster where we run installation regression. This was tipically managable, but in this case we have 2 branches with 2 different RHCOS baseline (4.6/4.8). So we would like to be able to continue issuing our jenkins installation build that can be 'randomly' 4.6 or 4.8 installation Setting to low Priority; this will have to be evaluated/addressed for a future release, but is unlikely to make 4.9. (There is no future release past 4.9 that can be targeted at this time) I'm afraid that this could be a EFI firmware bug where the firmware would remember an older boot entry. RHCOS does not setup EFI boot entries and relies on the default paths for booting up. RHCOS does create an EFI boot entry, but not in coreos-installer. On the first boot, shim is invoked as the fallback bootloader and it creates the entry: https://github.com/rhboot/shim/blob/main/README.fallback On first boot, we currently randomize the disk's GUID and the filesystem UUIDs of / and /boot, but we do not randomize partition GUIDs. The image build process does, however, so each distinct OS release will have a different partition GUID for the ESP, and that GUID is included in the EFI boot variable. That seems like an awkward middle ground. We can't randomize the partition GUID on first boot (because it'll break the boot entry shim just created) and the current behavior (one GUID per OS revision) doesn't really make sense. So one possible fix for this BZ is to hardcode a particular partition GUID for the ESP in all FCOS/RHCOS OS images, ensuring that reinstalls don't spawn additional boot entries. That will undoubtedly cause trouble if two disks have RHCOS installed, but there are already other reasons the OS won't boot successfully in that case. Vincent, can you confirm that the firmware is not somehow configured to prioritize network boot over local boot? Also, could you post the output of `efibootmgr -v`? This is indeed a UEFI issue. We tried to automate as much as possible, but at some point, there are cases were things should be done manually, or on a per vendor case. We have worked around this by using the Dell utility racadm to reset the boot order in those case. Also, this is a lab issue on our side, no a product issue in the field. I will close this case. Thanks It's currently not an issue in the field because clusters always provision nodes using their original boot images. However, there are plans to change that, at which point reprovisioning of existing nodes will start spawning duplicate boot entries. I'll leave this issue closed, but I've opened https://github.com/coreos/fedora-coreos-tracker/issues/946 to track the problem upstream. Thanks for reporting. *** Bug 1977983 has been marked as a duplicate of this bug. *** |