Fernando Meira schreef: > Sorry.. I was not sure if the quoting was right.. gmail just got crazy!! > I repeat! > > On 6/19/05, *Holly Bostick* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> > wrote: > > Not necessarily, if the internal default for this setting is ON (which I > don't know), but in any case, when commented settings revert to their > internla default, so in this case it might be better to explicitly set > it to "Off". > > > So I set Option UseFBDev to Off, and now I get this: "MergedFB does > not work with Option UseFBDev, MergedFB mode is disable." and I'm > unable to start X. >
All right-- I don't know what any of this means, but it is in fact much more information that what we previously had. What in the name of sanity is MergedFB, and where can we turn it off? Why is UseFBDev trying to turn *on* when your setting is *off* ? But in any case, it's time to go back to the sources, clearly. All you've posted is the X.log.0, here are the errors: > (WW) The directory "/usr/share/fonts/CID/" does not exist. This one is not important (doesn't stop X from starting). > (WW) Open APM failed (/dev/apm_bios) (No such file or directory) I don't use APM, as this is a desktop, not a laptop. However, you seem to have a laptop, so while I would not necessarily think that this would stop X from starting (it might, though), this seems distinctly "double-plus-ungood" and needs to be fixed ASAP in any case. But that's a kernel issue (APM support would seem to be uncompiled). > (WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode > disabled Oh-- *that's* what MergedFB mode is... dual-head! Which you clearly don't even have (unless your second monitor is just broke). So this should be turned off, but still shouldn't be stopping X from starting. The actual showstopper seems to be here: > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: Open failed > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: open result is -1, (Unknown error 999) > drmOpenDevice: Open failed > [drm] failed to load kernel module "radeon" > (II) RADEON(0): [drm] drmOpen failed > (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. Basically, the 'radeon' module (the kernel opensource drivers) are not able to initialize 3D hardware acceleration (afaik, the 'radeon' drivers cannot do this for the Mobility chipsets; you would need the fglrx drivers)-- and if you are using KDM or GDM or Entrance to start X (rather than just 'startx' from a console), you need this functionality (GNOME or KDE, ime, won't start without some form of acceleration, be it ATI, MESA or whatever). So I'd like to know how your kernel is configured, and what your xorg.conf looks like. > Well, of course they do-- you're using the 'defaults' option, which > implies (among other things) 'noexec'-- which means scripts may not be > run (no executables may be run) from the partition. You might want to > add the 'exec' option *after* the 'defaults' option (so that it > overrides the 'noexec' included by 'defaults', if you put 'exec' before > defaults, the 'noexec' witll override the exlplicit 'exec', which is > not > what you want). > > You maybe got confused, because 'defaults' use 'exec' and not > 'noexec'. But, for clear doubts, I double set 'exec' and tried again, > with no success... I still can't create a user properly! And this > problem spreads to X startup.. what can be wrong? > You're right, according to man mount.... but I know from hard experience that there is *some* option that sets nodev nosuid and noexec *as well as* the explicit option when you set it.... ah, it's ------------------------- user Allow an ordinary user to mount the file system. The name of the mounting user is written to mtab so that he can unmount the file system again. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid). ---------------------------- So I had the wrong option, sorry. But I don't understand why settings in /etc/fstab would affect user creation, or X startup of all things.... unless what you're saying is: 1) Because your /home partition is FAT32, when you try to create a user, the default files cannot be copied to create the user's home folder because the permissions are wrong..... But this doesn't make any sense (to me), because root is creating users, and root *does* have permission; and 2) You cannot start X because your user does not have permission to various files (like .Xauthority), but this also doesn't make sense to me, because a) X is failing to start long before a user is involved (the basic X server is not able to start enough to read user files) and b) the user should have read permissions to their own home folder even if your mounting is all messed up in some way, and afaik, you just need read permissions to start X-- you need write permissions to do anything else, so if you don't have them, you get the 'your session lasted less than 10 seconds' error, but X should be starting. Which it is not. So I think the problem is in the kernel and X.org configs, for what it's worth. I also think that the radeon driver is the wrong one for you to be using, and you should be using the fglrx driver (check the release notes, but I'm pretty sure it's compatible with the Mobility now). However, if you want to keep using the radeon driver, you should check your DRM configuration in the kernel (it should be "off" for fglrx, "on" for any other driver), as well as confirming that you've added support for your motherboard's chipset in the kernel. You'd probably also want to check your APM options and compile them in if they are not. Alternatively, you change your xorg.conf to load straight VESA and see if X would at least start under those conditions. I would also wonder if all the necessary modules are being loaded during boot; check the output of lsmod against dmesg (anything that should have loaded but didn't?) and the contents of /etc/modules.autoload.d/kernel-2.6. If something necessary is missing, try adding it to modules.autoload.d. I have a sense that we've got the tiger by the wrong end, but don't have enough information to figure out which end is which :) . Holly -- gentoo-user@gentoo.org mailing list
