Re: udev fixed, but not xorg

[Indigo <pointofavailability@xxxxxxxxx>]

I never did have any problems with udev, just thought it could be the
cause of the xorg problems, as it's now a dependency since xorg 1.8...
was following this thought, troubleshooting:
https://wiki.kubuntu.org/X/InputConfiguration -- and it seemed
plausible.  For my own situation, it may be related to virtualbox
having it's own video card emulation that is VESA compliant, but needs
guest additions to handle anything more... but that being said, vbox
doesn't have a problem with higher resolutions until slim takes over.
Also, this is a common issue I see on IRC.  Having thoroughly read the
tazx script, I tried 'Xorg -config :1' just to read the file
generated, and something is definitely wrong.  I will look at the
dependencies you suggested and let you know, tomorrow.

As for the udev issue, setting loglevel="err" (or "debug" for even
more), it appears there definitely is a reason it's failing on boot...
it's just that the process respawns, so it's not a big deal in the
end.  If it's not causing any problems, the status message wouldn't
need to be supressed - we could just fake it, make it say 'success' no
matter what.

Thank you for your quick response - I'll be back at this in the morning.

On Thu, Dec 23, 2010 at 6:37 PM, Rohit Joshi <rj.rohit@xxxxxxxxx> wrote:
> Hi Indigo,
>
> ===Xorg===
> I believe you are missing one of the dependency:
> mesa/mesa-intel-*/linux-drm/linux-agp. Xorg should detect everything
> automatically and you should not be reuired to edit xorg.conf manually.
>
> If xorg works with vesa and crashes with intel and you have an intel driver,
> it should indicate a missing dependency. "lsmod" should help. Also check
> "LOAD_MODULES" in rcS.conf.  I think your problem should not be related to
> udev. Also make sure your user is in "Video" group.
>
> ===Udev===
> Second, we have purposely moved udev above mounting. We don't need to push
> it back. Udevadm trigger will autodetect when things are started. So, even
> though you see udev status message as failed, udev actually is working
> correctly. The boot status message is misleading. Maybe we should just
> suppress "status" check in rcS. Hotplugging and coldplugging both works
> correctly as far as I have tested. What is the exact problem with udev you
> had? Maybe we can help you out in resolving it.
>
> Thanks
>
> Rohit
>
> On Thu, Dec 23, 2010 at 7:51 PM, Indigo <pointofavailability@xxxxxxxxx>
> wrote:
>>
>> After much too long spent figuring out what was happening, it turns
>> out that the fix for the udev fail on boot in an installed system is
>> simply to edit /etc/init.d/rcS and start udev right after the
>> filesystem is remounted read-write.  There is no need for devtmpfs
>> (which caused other problems)... but unfortunately, fixing udev has
>> not fixed xorg - for me, at any rate.
>>
>> I am not sure, at this point, if the problem is in
>> /etc/init.d/hwconf.sh, or possibly tazx... I am still stuck with
>> 800x600 resolution using the vesa driver, as I'm running slitaz in
>> virtualbox and have not installed guest additions (I've read the forum
>> posts) - so, even when I run tazx and install the intel driver, xorg
>> config says vesa, and changing this to intel just causes it to crash.
>> According to the xorg log, the larger resolutions are available, and
>> the hardware is getting recognized - even vga=791 works until slim
>> takes over - but the xorg.conf.d folder still has only generic,
>> default values.  Also, uncommenting the xserver_args line in slim.conf
>> causes it to crash.  Is this just a limitation to the vesa driver?  I
>> have found that 'Xorg -config :1' creates the /root/xorg.conf.new file
>> that's then used to populate /etc/X11/xorg.conf.d -- but I don't see
>> how the specifics are supposed to be filled in.  The log seems to show
>> that xorg is aware of the capabilities of my display, but the
>> configuration files don't reflect this...
>>
>> Any help with this, even links would be appreciated.  I could edit the
>> files manually, but I'd like to see this working the way it's supposed
>> to...
>>
>> ---
>> SliTaz GNU/Linux Mailing list - http://www.slitaz.org/
>>
>
>

---
SliTaz GNU/Linux Mailing list - http://www.slitaz.org/