Re: X/wdm/console debian policy for hurd...
On Mon, Sep 26, 2005 at 08:59:40PM -0600, Javier-Elias Vasquez-Vivas wrote:
> I finally could see a debian hurd with network connectivity, and then
> I tried X. It worked more or less (can't copy/paste through double
> button mouse).
Congrats :)
> Then I went ahead and installed wdm. This combination sort of worked
> out. If I kill wdm and therefore X and any session then I can reboot
> without problem. When I reboot from X, with X and wdm alive still,
> then somehow the root partition grub uses gets screwed, an upon reboot
> a check of the partition is required. This can be reproduced all
> times.
Hrm.
> As I haven't found a way to get out of X (used to be
> ctrl-alt-backspace on linux, but on hurd I have no idea),
ctrl+alt+backspace should work, I use it all it the time. Although I
only start X via startx, not wdm.
> 1.- Why not having the console startup only after all checks are
> done? I mean using a init.d script with some debian policy instead of
> using directly libexec/runsystem? This would allow console push later
> than all required checks and possible fixes.
Which required checks are you talking about here? Currently, the Hurd
console should be started after /etc/rcS.d and /etc/rc2.d are executed.
> 2.- Why not delaying through debian policy wdm even more, to make
> sure it's guaranteed to show up after console has shown up? If we do
> 1, of course we have to guarantee wdm comes later than console.
The answer to both questions is: I tried and failed. If you manage to
do it, please send patches. I was not able to reliably start up the
console from an init script (or any other script executed by runsystem,
for that matter), last I tried.
I agree that starting the Hurd console from /etc/init.d would be a much
cleaner solution.
> 3.- I think if we acomplish 2 then we're done with this 3 because the
> debian policy is kind of push/pop, but here it goes. When going down
> the pipe on halt/shutdown/reboot we must guarantee X/wm/wdm and all X
> related processes are killed previous to anything else to avoid
> problems, then the console can safely be killed and then all other
> things not console dependant...
Well, if this leads to reproducible file system corruption, then this is
a bug which should be fixed.
cheers,
Michael
--
Michael Banck
Debian Developer
mbanck@debian.org
http://www.advogato.org/person/mbanck/diary.html
Reply to: