Stefan Hundhammer changed bug 1227887
What Removed Added
Resolution --- WORKSFORME
Status REOPENED RESOLVED

Comment # 3 on bug 1227887 from Stefan Hundhammer
Well, we have the same problem since forever when we have to debug anything in
the inst-sys; and it's even worse: We typically have to ssh to the machine, scp
some files from our development environment to /tmp on the RAM disk (because
the rest is mounted read-only) and bind-mount individual files from there to
their real destination.

As you can imagine, that is a royal PITA. If something shoots down that
carefully hand-crafted environment just like that, everything was in vain
because the RAM disk dies with it.

Still, we have to make do with that; one thing that we really don't want to do
is to expose those gory details to the normal end user, e.g. in the
confirmation dialog when the user hits the "Abort" button.

Worse, we'd even have to carry all those details over to the installation
workflow because the ssh installation is a rare scenario, not the normal case,
and we really don't want to confuse the hell out of all those users who have
the normal case.

For a normal user, aborting the installation really means that it's time to
reboot to get back to a well-defined state. And we also don't know what caused
the user to abort, and what would be appropriate to get things going again.
Restarting from there is definitely something for advanced users.

For cases where we really, really want to make sure that we don't get forced to
reboot and get our hand-crafted inst-sys devel environment on the RAM disk
killed, some of us also use the "startshell=1" boot parameter in addition to
"ssh=1 sshpassword=foo".

That one goes to linuxrc as well and starts another shell (on the system
console) that it falls back to, but it's sometimes a bit awkward to handle; and
in the good case (no abort, installation went through) it doesn't reboot right
away, but you have to end that shell with Ctrl-D before the installation
continues, i.e. it reboots into the freshly installed system.

That can be helpful sometimes, but I tend not to do it unless I know that i
have to do exhaustive bind-mounts in a very complex devel environment.


Choose your poison. Nobody ever said being a YaST developer working in the
inst-sys is fun. And when you do things like this, for all intents and purposes
you elevated yourself to that status. ;-)


You are receiving this mail because: