[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#408437: cdebconf-gtk-udeb: Rescue mode doesn't work with g-i

On Sun, Jan 28, 2007 at 11:47:46AM +0100, Attilio Fiandrotti <attilio.fiandrotti@gmail.com> wrote:
> Frans Pop wrote:
> >tags 408437 + pending
> >thanks
> >
> >On Thursday 25 January 2007 21:22, Mike Hommey wrote:
> >
> >>Everything is in the subject: the Rescue mode fails with g-i. See the
> >>attached screenshot. Maybe it should use openvt to run the shell and
> >>chvt to come back to g-i after the shell exits.
> >
> >
> >I'm not sure how you got to that screenshot. If I choose either of 
> >the "start a shell" options in the graphical installer, the installer 
> >effectively hangs while trying to open that shell (you can still switch 
> >to another VT though).
> >
> >I have committed a patch to rescue mode that suppresses the "execute a 
> >shell" options if the gtk frontend is used. I'll also document this 
> >limitation in the installation guide and suggest that users switch to VT2 
> >or VT3 and use chroot instead.
> >Unfortunately it is not possible anymore to add a decent informational 
> >message in the installer itself before RC2.
> >
> >The openvt and chvt commands are not available in the installer, but if 
> >anyone can supply a working solution to start a shell from the graphical 
> >installer, that would be most welcome. It is already a TODO item for 
> >post-Etch.
> I wrote a chvt similar app some months ago, but the final choice was not 
> including it in the installer; anyway if someone wants it, the 
> sourcecode is still available as an attachment in the bug tracker [1].

openvt -s -w is probably better than chvt. It could be used to create a
new vt where the rescue shell will run, and once the shell is exited
(no need to change what the rescue info says) gets back to the original
(g-i) console. This could even be used with text backed d-i.

> Looking for a more solid solution to this issue, i've been investigating 
> about patching a console widget like libvte or libzvt not to depend from 
> X anymore, so that we can includeit ans an udeb in the g-i and provide a 
> graphical shell from within the GTK frontend.
> Nowadays libvte is much popular than libzvt, but libzvt is smaller and 
> may find a niche for those non X applications like the g-i.
> Pherhaps libzvt author would be interested in working on this with the 
> d-i team.

Having a console widget in the gtk frontend would be neat.

> Finally, should this bug be merged with 339855 (cc'ed)?

Sounds reasonable.


Reply to: