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 [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
