curtin-dev team mailing list archive

[Michael Hudson-Doyle <mwhudsonlp@xxxxxxxxxxx>]

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

** Changed in: subiquity
       Status: New => Triaged

** Also affects: curtin
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of curtin
developers, which is subscribed to curtin.
https://bugs.launchpad.net/bugs/1876626

Title:
  'toram' kernel parameter does not work with subiquity

Status in curtin:
  New
Status in subiquity:
  Triaged

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1876626/+subscriptions