https://bugzilla.suse.com/show_bug.cgi?id=1227887 https://bugzilla.suse.com/show_bug.cgi?id=1227887#c3 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|REOPENED |RESOLVED --- Comment #3 from Stefan Hundhammer <shundhammer@suse.com> --- 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: You are on the CC list for the bug.