X/wdm/console debian policy for hurd...
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).
As it sort of worked then I tried fluxbox (my wm of preference), and it worked.
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.
Problem doesn't end up there. Upon partition fix, it looks like wdm
is pushed before the console is pushed, and then we get into trouble
because the mouse and keyboard repeaters are issued only upon console
startup. And then the X freezes.
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), I have no
other option than a hardware reboot, which will keep me in the loop
until I reboot on linux and correct screwed partition. Then when
rebooting with hurd the console shows up and only after that wdm and
everything is OK...
A work around I've found is to kill wdm from X, so that X gets killed
and then reboot (I say reboot because my machine is unable to halt, it
always gets stuck on halt and again the partition always gets screwed,
so no halt/shutdown at all) to perform a hardware shutdown on bios
startup.
This brings me to several points (sorry for the long description):
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.
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.
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...
Of course something can be done so that rebooting from X is not that
painful, but a debian policy work around sounds easier right?
Thx,
--
Javier-Elias Vasquez-Vivas
Reply to: