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
--
Mailing list: https://launchpad.net/~curtin-dev
Post to : curtin-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~curtin-dev
More help : https://help.launchpad.net/ListHelp
