Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support cloud-specific grub fragments #110

Closed
Tracked by #95
bgilbert opened this issue Jan 11, 2019 · 11 comments
Closed
Tracked by #95

Support cloud-specific grub fragments #110

bgilbert opened this issue Jan 11, 2019 · 11 comments
Assignees
Labels
cloud* related to public/private clouds jira for syncing to jira

Comments

@bgilbert
Copy link
Contributor

bgilbert commented Jan 11, 2019

Some clouds need particular kernel command-line arguments and grub commands, usually for configuring the console. On CL, this is used on AWS, Azure, GCP, and Packet.

@bgilbert bgilbert added the cloud* related to public/private clouds label Jan 11, 2019
@dustymabe
Copy link
Member

Do you have examples of what these values are in CL?

@dustymabe
Copy link
Member

For the console values.. would it help if the kernel supported something like this?

@bgilbert
Copy link
Contributor Author

bgilbert commented Jan 13, 2019

  1. AWS
    • Serial console primary
    • modprobe.blacklist=xen_fbfront net.ifnames=0. I'm not sure whether this is still important.
  2. Azure
    • Serial console primary, plus an earlyprintk option for unclear reasons
  3. GCP
    • Serial console primary
  4. Packet
    • Serial console primary on non-default port
    • coreos.autologin, which could be handled via a different mechanism
    • GRUB gfxpayload variable, which may or may not be important

So yes, the multi-console patch would help. It's possible that most of the other bits can be dropped now, though Packet's use of ttyS1 will still be relevant.

@bgilbert bgilbert added jira for syncing to jira and removed jira for syncing to jira labels Jan 13, 2019
@bgilbert
Copy link
Contributor Author

According to the Packet folks, gfxpayload is not needed.

Each Packet machine generally has a randomized root password which is made available through the Packet API. Container Linux uses coreos.autologin instead. Fedora CoreOS could opt for the randomized password approach, if desired.

@dustymabe
Copy link
Member

should we discuss implementation details? Today for the firstboot parameter we have:

We could do something similar (set a grub var that updates the kernel command line based on a placed file specific to what oem we are targeting) for this work? Would we even need a separate file?

In https://github.com/coreos/ignition-dracut/issues/39 we actually were discussing changing the firstboot workflow to just use grub env vars and not require a file, but that would need some investigation.

@bgilbert
Copy link
Contributor Author

On Container Linux, the OEM partition has a grub.cfg fragment which is sourced by the main GRUB config at runtime. Those are the files linked in #110 (comment). The fragment is pretty much limited to setting or appending to variables used in the kernel command line, such as $linux_console or $linux_append.

We could do something similar here, but it may not be necessary, since (unlike in CL) the base image knows about all of the supported platforms. We could have conditionals in the base config that set variables based on the platform ID, which GRUB already knows.

See also #47 (comment).

@bgilbert
Copy link
Contributor Author

Per #114 (comment) we won't be enabling a coreos.autologin-like parameter on Packet.

@jlebon
Copy link
Member

jlebon commented Aug 25, 2021

This was discussed in today's community meeting:

13:18:24 < bgilbert> #agreed we will pursue a static approach to cloud-specific bootloader configs, where grub
                     commands and kargs are templated at image build time and by coreos-installer install
                     --platform at install time.

@jlebon jlebon removed the meeting topics for meetings label Aug 25, 2021
@dustymabe
Copy link
Member

@bgilbert
Copy link
Contributor Author

Yup, that should do it.

@dustymabe
Copy link
Member

I'm going to close this out. The initial use of this was used to implement #567

@dustymabe dustymabe removed the status/pending-next-release Fixed upstream. Waiting on a next release. label Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cloud* related to public/private clouds jira for syncing to jira
Projects
None yet
Development

No branches or pull requests

3 participants