kernel command line is not easily customizable

Bug #1044503 reported by Scott Moser on 2012-08-31
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
High
John A Meinel
maas (Ubuntu)
High
Unassigned
Quantal
Undecided
Unassigned
Raring
High
Unassigned

Bug Description

kernel command line for pxe boot is done by
 /usr/share/pyshared/provisioningserver/pxe/config.py

That renders files in /usr/share/pyshared/provisioningserver/pxe/

$ ( cd /usr/share/pyshared/provisioningserver/pxe && ls *.template -w1)
config.commissioning.template
config.local.amd64.template
config.local.i386.template
config.local.template
config.local.x86.template
config.template

The problem is that those files are in /usr/share and not in /etc/. As far as I can tell, there is no local way to modify kernel parameters.

Related branches

Gavin Panella (allenap) wrote :

Got to be done for 12.10, not so important for SRU I think.

There's already a comment in provisioningserver.pxe.config that mentions that the template directory needs to be configurable.

Changed in maas:
status: New → Triaged
importance: Undecided → High
Julian Edwards (julian-edwards) wrote :

Right, we should move the templates out to contrib_v2/ to be near the preseed ones.

Julian Edwards (julian-edwards) wrote :

(and then make packaging put them in /etc)

Julian Edwards (julian-edwards) wrote :

On second thoughts, this will make upgrades either ask questions, change the config or leave the user without packaging changes to it. The right way is to have a run-parts directory that's included by a master template.

Francis J. Lacoste (flacoste) wrote :

Bug #1045390 is very similar, maybe even a duplicate.

Changed in maas:
milestone: none → 12.10
Andres Rodriguez (andreserl) wrote :

I believe we should be able to add an attribute to the Node model. This way, we can define a global config that will apply to all nodes. If a particular node needs to change the attributes, it should be possible to do that independently.

Dave Walker (davewalker) on 2012-10-10
Changed in maas (Ubuntu):
status: New → Triaged
importance: Undecided → High
milestone: none → ubuntu-12.10

On 10 Oct 2012 20:15, "Andres Rodriguez" <email address hidden> wrote:
>
> I believe we should be able to add an attribute to the Node model. This
> way, we can define a global config that will apply to all nodes. If a
> particular node needs to change the attributes, it should be possible to
> do that independently.

We need to think about sets of machines, as identified by tags or whatever,
rather than individual nodes. The templates that generate the PXE
configurations are already arranged for that kind of thing, but it has
proven to be complicated in practice. We should be as smart as we can and
do everything we can before giving users a free-form field in which to
enter extra bits of the command line.

Julian Edwards (julian-edwards) wrote :

On Wednesday 10 October 2012 19:25:24 you wrote:
> On 10 Oct 2012 20:15, "Andres Rodriguez" <email address hidden> wrote:
> > I believe we should be able to add an attribute to the Node model. This
> > way, we can define a global config that will apply to all nodes. If a
> > particular node needs to change the attributes, it should be possible to
> > do that independently.
>
> We need to think about sets of machines, as identified by tags or whatever,
> rather than individual nodes. The templates that generate the PXE
> configurations are already arranged for that kind of thing, but it has
> proven to be complicated in practice. We should be as smart as we can and
> do everything we can before giving users a free-form field in which to
> enter extra bits of the command line.

I think doing it by tags is the smartest way, as it offers the most
flexibility, fits with the existing UI and doesn't require more special cases.

The *implementation* of where the data is stored for nodes with that tag,
however, is up for grabs. Per node? A tag/kernel_opt table?

Scott Moser (smoser) wrote :

> We should be as smart as we can and do everything we can before giving
> users a free-form field in which to enter extra bits of the command line.

I generally disagree with this.
I like the "be as smart as ew can" part, but after that it goes sour.

Accept that you can't know the right parameters for hardware. Make it
configurable via some sort of "free form field".

Other thing to note here, is we want kernel parameters for a node to copy
to the installer's preseed. so that after the installer the system boots
with those parameters.

Example:
 I just did an install where I hacked the cmdline of the
ephemeral/commissioning and install via modifying
  config.commissioning.template and config.install.template
I added 'console=ttyS1,115200'. Those parameters at least possibly should
make it into the preseed data so that the install also gets them. At the
moment that doesn't happen.

Scott Moser (smoser) wrote :

On Fri, 12 Oct 2012, Scott Moser wrote:

> I just did an install where I hacked the cmdline of the
> ephemeral/commissioning and install via modifying
> config.commissioning.template and config.install.template
> I added 'console=ttyS1,115200'. Those parameters at least possibly should
> make it into the preseed data so that the install also gets them. At the
> moment that doesn't happen.

I just realized that per installer documentation anything after a '--'
will be copied to the installed system cmdline.
So, I could have (and have tested) that just adding:
 -- console=ttyS1,115200

will get that onto the installed system.

Changed in maas:
milestone: 12.10 → 12.10-stabilization
Changed in maas:
milestone: 12.10-stabilization → none
Changed in maas:
assignee: nobody → John A Meinel (jameinel)
Scott Moser (smoser) wrote :

Can someone explain the solution that is being pursued here? I see "by tag" as the way to specify kernel parameters, but I dont know what that really means. I'd like to see a general explanation of how the end user would use this before an implementation is done that might not be sufficient to actually solve a problem.

Martin Packman (gz) wrote :

With the landing of the rollup branch, all the parts needed for this should now be on trunk:
<https://code.launchpad.net/~jameinel/maas/land-kernel-opts-in-trunk/+merge/133434>

Changed in maas:
status: Triaged → Fix Committed
no longer affects: maas/1.2
Changed in maas (Ubuntu Quantal):
status: New → Invalid
Changed in maas:
status: Fix Committed → Fix Released
Changed in maas (Ubuntu Raring):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers