Replies: 4 comments 4 replies
-
|
cc @bk201 @davidcassany @mudler This will only affect you if:
|
Beta Was this translation helpful? Give feedback.
-
|
Doesnt seem that great tbh, there is no way to override anything without a complex yip file and random mounting/unmounting the state partition which yuck... Another approach would be:
This allows us to have some static files in there AND allow overriding by end users easily. Not a great approach but at least we cna streamline this. |
Beta Was this translation helpful? Give feedback.
-
|
yes, I was afraid of the amount of changes that could imply, specially in our tests. Another probably not straight forward approach could be providing a new elemental-cli command for these files. So we could add some additional logic to prevent insane approaches or having to instruct users to do crazy remounts. For variables we could also van changes for certain ones and full freedom only for new ones. A command that could be used in both after-install hooks and in init stages. At least of the grubenv I believe this could be useful and make sense, not entirely sure for the custom config file though. Imagine something like How does it sounds? |
Beta Was this translation helpful? Give feedback.
-
|
blergh, sounds bad to be honest. Having a command to remount the state partition just for a single line change...I dont want to think what could go wrong, plus the whole remounting RW and cleaning up...so much stuff could go wrong. IMHO the less we touch the RO partitions the best, thats why I hate it by going with the override via OEM sounds the best approach. Not that I like it thougth.... 😿 |
Beta Was this translation helpful? Give feedback.
-
|
I see your point, probably as @kkaempf suggested we should step back and define our implementation goals (such as prevent as much as possible searching for files) and our feature set (include additional stuff in grub.cfg). Then probably having this clarified we can discuss about backward compatibility contstraints. I'll try to do such an exercise in this discussion later in the morning. |
Beta Was this translation helpful? Give feedback.
-
|
yes, good point. Will close the current open PR until we can discuss this and clarify everything. |
Beta Was this translation helpful? Give feedback.
-
|
We need:
We want:
I think having the default files on STATE, even if empty its good. Then we can let the users override by having the same files on the OEM partition, but instead of searching for them blindly, first load STATE then test if those files are also in OEM and load those. Although I don't really like that end users can easily break the system by writing to the OEM partition (RW by default) as that could make the whole thing flimsy. Probably need to investigate further but its a real possibility that you cannot boot anymore if you break the grub menus/configs somehow ¬_¬ At least you can probably insert a USB with a COS_OEM partition and have them load it from there 🤣 At a minimum I would do the load default from STATE, then check for overrides on OEM instead of the actual "it will load from whenever it finds them and does a random search for those files, no matter your disk layout". Would even leave the rest as is, then afterwards merge the files. That would meet our needs for no searching and give the process a bit more stability while keeping the overridable feature and enhancing the user docs |
Beta Was this translation helpful? Give feedback.
-
|
I believe the main question to answer here is how to handle a grub configuration that allows grub2 customization at the same time we keep a simple and immutable or almost completely static grub configuration. Tried to dump and organize here all the ideas I have around this topic. About use cases (feature set)For that I would divide customization use cases into three categories:
About implementation goals
Eventual constraints
In terms of compatibility:
Ideas for implementation
For that I would set a # Set defaults
set timeout=10
set display_name="Elemental"
set fallback="0 1 2"
# Load system env file (includes label variables set during install)
# no need to include device in path, default device is already the state partition
# also the $root variable could be exported from the EFI config
# see https://www.gnu.org/software/grub/manual/grub/grub.html#export
set system_env="/grub2/system_grubenv"
load_env -f "${system_env}"
# Load user env file
set user_env="/grub2/user_grubenv"
search --no-floppy --label --set=oem_blk "${oem_label}"
if [ "${oem_blk}" ] ; then
load_env -f "(${oem_blk})${user_env}"
# Reload state to prevent overloads from OEM
load_env -f "${system_env}"
fi
# Save default
if [ "${next_entry}" ]; then
set default="${next_entry}"
set selected_entry="${next_entry}"
set next_entry=
save_env -f "(${env_blk})${user_env}" next_entry
else
set default="${saved_entry}"
fi
insmod all_video
insmod loopback
insmod squash4
menuentry "${display_name}" --id cos {
# state label is taken from system env
# no need to set the active label, more over its not even needed to boot,
# having the image path and state label is sufficient it this was redundant
set img=/cOS/active.img
loopback loop0 /$img
source (loop0)/etc/elemental/bootargs.cfg
linux (loop0)$kernel $kernelcmd ${extra_active_cmdline}
initrd (loop0)$initramfs
}
menuentry "${display_name} (fallback)" --id fallback {
...
}
menuentry "${display_name} recovery" --id recovery {
...
}
# Load extra config, custom_blk defined in system_env
# I think this should be at the bottom to ensure the fallback variable is
# consistent with the number in case new menu blocks are added here
if [ "${custom_file}" ]; then
source "${custom_file}"
fiThen the set kernel=/boot/vmlinuz
# This could also boot squashfs images [^_^]
# ${default_args} could be set at install time (system_env) and include
# some defaults like "console=tty1 console=ttyS0 fsck.mode=force fsck.repair=yes"
set kernelcmd="root=LABEL=$state_label cos-img/filename=$img panic=5 rd.cos.oemlabel=$oem_label ${default_args}"
set initramfs=/boot/initrdWe could consider making With this setup:
Onwards compatibility contsraintsThis setup defines three defacto contracts to keep compatibility across updates:
Gray areasI believe the only relevant gray area is how the boot assessment needs to be adapted to this setup:
|
Beta Was this translation helpful? Give feedback.
-
Coming from rancher/elemental-cli#373
We have an issue when searching for files from grub in some server FW which makes the search take 30 minutes.
The idea here would be to on install with elemental-cli create those files if they dont exists so the search is not stuck.
After some discussions it also come to light some better approach to our grub.cfg configurations:
Beta Was this translation helpful? Give feedback.
All reactions