'toram' kernel parameter does not work with subiquity

Bug #1876626 reported by Johan Ehnberg
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
curtin
Fix Released
Undecided
Michael Hudson-Doyle
subiquity
Fix Released
High
Unassigned

Bug Description

When starting the installer with the 'toram' kernel parameter, the installation fails on probing multipath for /dev/shm with curtin command curthooks at curtin/util.py:141:
Unknown device "/dev/shm": Inappropriate ioctl for device

Working 'toram' autoinstallations are handy for servers that do not have netboot, IPMI nor USB, but can boot from the same storage as normally and that storage can be written to out of band. In other words, installation starts from the same device as will be installed to.

Since d-i is no longer available, netboot images that were suited for this can no longer be used.

Use cases know to me include at least rented servers with hosting-provided rescue. There are a few other approaches such as manual bootstrapping, kexec and imaging that work. However, the toram approach would allow the same install method as with other types of servers and requires less manual effort.

Related branches

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

So the command that is failing is

udevadm info --query=property --export /dev/shm

which is being executed because /dev/shm is in /proc/mounts. I guess we could fix this by getting casper to choose a different name (afaik the "from" label has no significance when mounting a tmpfs) but to get new curtin to work with existing media we'll need to fix curtin too.

Changed in subiquity:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :
Dan Watkins (oddbloke)
Changed in curtin:
status: New → In Progress
assignee: nobody → Michael Hudson-Doyle (mwhudson)
Revision history for this message
Server Team CI bot (server-team-bot) wrote :

This bug is fixed with commit f4bd38f4 to curtin on branch master.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=f4bd38f4

Changed in curtin:
status: In Progress → Fix Committed
Changed in subiquity:
status: Triaged → Fix Released
Revision history for this message
Johan Ehnberg (johan-ehnberg) wrote :

I confirm the fix works well. And for automatic installs, adding the following will pull in the fix before the error triggers:
  refresh-installer:
    update: yes

Revision history for this message
Ryan Harper (raharper) wrote : Fixed in curtin version 20.1.

This bug is believed to be fixed in curtin in version 20.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in curtin:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.