Remove rpm depency from packagesystem! - #1130
Conversation
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
|
Hi @krolmiki2011. Thanks for your PR. I'm waiting for a coreos member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
|
hello can someone help me, because tests not working |
|
Hello, its anyone here? |
|
Hello? |
|
Is there anyone here? |
|
Hi @krolmiki2011. We have reduced capacity for going through From a very brief glance, why keep the legacy code files? Investigating the failing CI will take a more thorough investigation, but it does seem related to these changes. Are we maybe missing something to filter out only bootloader components here? |
|
One more point, though again it may just require a deeper look from my part, but #468 (comment) would lead me to believe this should be possible without making changes to files other than |
Okay, so I view this notebook as a place to keep things in case the code turns into spaghetti, but also as something to delete once the code is stable. Regarding your second question—a good point—I noticed that BIOS and Legacy EFI (OSTree boot) both use RPM; while BIOS is handled by |
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
…to packagesystem.rs query_ostree_boot_legacy() Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
Signed-off-by: krolmiki2011 <mikolajziolkowski504@gmail.com>
|
So, trying to understand this a bit better, as TBH I'm still learning about We want to make Quick overview of the data that gets stored: ContentMetadata structpub(crate) struct ContentMetadata {
/// The timestamp, which is used to determine update availability
pub(crate) timestamp: DateTime<Utc>,
/// Human readable version number, like ostree it is not ever parsed, just displayed
pub(crate) version: String,
/// Transfer version into Module struct list
pub(crate) versions: Option<Vec<Module>>,
/// The default bootloader to install if at install time no bootloader option is
/// provided
#[cfg(efi_arch)]
pub(crate) default_bootloader: Option<Bootloader>,
}Note that the descriptions for Example bootupd-state.json{
"installed": {
"BIOS": {
"meta": {
"timestamp": "2026-06-09T16:53:24Z",
"version": "grub2-tools-1:2.12-60.fc44.x86_64",
"versions": [
{
"name": "grub2",
"rpm_evr": "1:2.12-60.fc44"
}
]
},
"filetree": null,
"adopted-from": null
},
"EFI": {
"meta": {
"timestamp": "2026-08-13T14:37:10.461466856Z",
"version": "grub2-1:2.12-60.fc44,shim-16.1-5",
"versions": [
{
"name": "grub2",
"rpm_evr": "1:2.12-60.fc44"
},
{
"name": "shim",
"rpm_evr": "16.1-5"
}
]
},
"filetree": {
"children": {
"BOOT/BOOTX64.EFI": {
"source": "shim/16.1-5/EFI/BOOT/BOOTX64.EFI",
"size": 1026520,
"sha512": "sha512:0dc3725da36f3183b5cb5af0ba982caccc35019b35f8c80ee29545b7f9fa0672aa09aac4f5693f250ca603910aa4249538d45991595cae198f897ee2f406bb27"
},
"BOOT/fbx64.efi": {
"source": "shim/16.1-5/EFI/BOOT/fbx64.efi",
"size": 119280,
"sha512": "sha512:46bf07b2212b2042f2c3eb44b0fc94527443ebd405204fd09014c55b4f3fd5d590007d78a5662f79570cfdb90e5c8ed5d794d7fa85ed8914d4c60b1d6ee9441d"
},
"fedora/BOOTX64.CSV": {
"source": "shim/16.1-5/EFI/fedora/BOOTX64.CSV",
"size": 110,
"sha512": "sha512:0c29b8ae73171ef683ba690069c1bae711e130a084a81169af33a83dfbae4e07d909c2482dbe89a96ab26e171f17c53f1de8cb13d558bc1535412ff8accf253f"
},
"fedora/grubx64.efi": {
"source": "grub2/1:2.12-60.fc44/EFI/fedora/grubx64.efi",
"size": 4145576,
"sha512": "sha512:1f86c5f4824cf292a9e36314186309977a8d92834c48b70ac128f7ec2289a544acddce16ea1b7d2457426cdd2fd5dfc65beab727f171c2fe443f8fc4ba19d684"
},
"fedora/mmx64.efi": {
"source": "shim/16.1-5/EFI/fedora/mmx64.efi",
"size": 874352,
"sha512": "sha512:d63aafcab70aeedcf1e083fda32130d9ba997ad04f8466c0d058f5d364a48d554b7160c0a4f17441f19797d39dfd785516078d3bd841714df2c2aa3327f3fa9f"
},
"fedora/shim.efi": {
"source": "shim/16.1-5/EFI/fedora/shim.efi",
"size": 1026520,
"sha512": "sha512:0dc3725da36f3183b5cb5af0ba982caccc35019b35f8c80ee29545b7f9fa0672aa09aac4f5693f250ca603910aa4249538d45991595cae198f897ee2f406bb27"
},
"fedora/shimx64.efi": {
"source": "shim/16.1-5/EFI/fedora/shimx64.efi",
"size": 1026520,
"sha512": "sha512:0dc3725da36f3183b5cb5af0ba982caccc35019b35f8c80ee29545b7f9fa0672aa09aac4f5693f250ca603910aa4249538d45991595cae198f897ee2f406bb27"
}
}
},
"adopted-from": null
}
},
"pending": null,
"static-configs": {
"timestamp": "1970-01-01T00:00:00Z",
"version": "0.2.35",
"versions": null
}
}Side note, but this also shows that the timestamps are inconsistent - BIOS is giving the build time of the RPM, whereas EFI (which I guess is using the filetree of This patch is currently changing the approach for BIOS to directly query and parse
Since currently this returns something like For the Worth also noting that the I think the first approach I would have thought of for this is to just parse version outputs from the main package managers (e.g. Another approach that pops to mind is to use something like file hashes for versioning instead. So equal hashes of the file content means no update, not equal means update. That loses downgrade detection, but maybe that's fine for a bootloader updater. The EFI filetree already has hashes for each file, and for BIOS we could just hash the grub binary instead? I'm sure there's issues that I'm not foreseeing with this though. The script approach probably means the least amount of work and changes for And thanks for working on this @krolmiki2011. I'd say let's decide on a solution first before we continue iterating. I'll try to follow up with others to see how to proceed, and maybe bring it up in a community meeting. |
|
@Rolv-Apneseth thanks for the reply and comment, and i kinda noticed, that grub2-install --version in fedora is 2.12, so less of topic i made pull request: https://src.fedoraproject.org/rpms/grub2/pull-request/246 to fix version |
|
Oh, and i open for another solutions |
| let grub_version_output = Command::new(&grub_bin_path) | ||
| .arg("--version") |
There was a problem hiding this comment.
Per discussion in the issue I think this is a bit too naive by default. It doesn't handle shim either.
One thing that would clearly help is to make the rpm stuff a build-time feature so it's more pluggable.
We can fall back to --version style stuff if the rpm feature is off.
Thanks to these changes, it will be possible to eliminate the rpm dependency from bootupd and become more distribution-independent!
KEY CHANGES:
BIOS:
In the case of BIOS, ContentMetadata is created just as it is for UEFI; for BIOS,
grub2-install --versionand themtimeare used.EFI (ostree-boot):
The situation is similar for ostree-boot in BIOS mode, except it iterates through files, and the version format is: legacy-ostree-boot-{mtime}
NOTE:
The old code, before the modification, is in the {bios, efi, packagesystem}_legacy.rs
Oh, and 'grub2-install --version' need package maintainers to patch grub2 upstream version to package version
This patch was inspired by issue: #468