|
Thanks a lot for your extensive feedback!
Now the strange part... I didn't use "aticonfig --initial" during the last installation and LMDE didn't has a any xorg.conf after installation. So I can't show you one. At least I haven't one on my root partition backup. That's the reason why sgfxi ask me every time to create a new xorg.conf file. Of course I chose 1) Create a new one. That means, the xorg.cong I uploaded is created by the X conf creator command out of the script. These files are currently in /etc/X11...(I restored me OS) default-display-manager rgb.txt X Xreset Xsession Xsession.options XvMCConfig Xwrapper.config :: Quote :: Did you click something in mint that says, select or create xorg.conf?no :: Quote :: Did your desktop boot into graphics mode correctly when you first installed mint?yes Due to the fact that I haven't any xorg.conf at the moment should I still do sgfxi -z -B? :: Quote :: Please tell me EXACTLY what you have done, versus what the system was defaulted to, in this process.Actually I did nothing beside installing LMDE. Best, SteffoMint Back to top |
|
Ok, piece by piece.
yes, do use: sgfxi -z -B if there is no xorg.conf it will make one. After that runs, show me then your /etc/X11/xorg.conf file As you can see in xorg.conf: Screen 0 "aticonfig-Screen[0]-0" 0 0 this was created by aticonfig, my dread is that the amd idiots now are automating the xorg.conf generation and forcing aticonfig broken xorg.conf files to be generated when you run their installer. If that's the case I may consider once and for all dropping fglrx support in sgfxi because over the years it has caused me nothing but pain and wasted days of unpaid and no fun time. Given their new beta now is also changed fundamentally re file name, zip file contents, etc, that's another major problem which I will have to look at as well, though I know a solution to that one. But let's see how this test goes before anything else. run sgfxi -z -B then paste the xorg.conf file no matter what happens. Your feedback is great so thank you for that, but what I am seeing is very worrying, profoundly so. Back to top |
|
kk here we go...
1. Sart sgfxi -z -B 2. Create new xorg.con - check 3. Chose card (ATI or Intel) - no I aborted! (Maybe it's interesting to see what the xorg command do in my case) Here is the xorg.conf after the x org command (whiteout driver install): pastebin.com/pGam8UrS There are still 7 Cards?! I'm confused... Back to top |
|
excellent thinking, to remove one variable. So the xorg itself is creating 7 devices, repeating the 1 and 2 bus cards.
Then however, aticonfig may be also triggered during the actual driver install since it clearly signed the final xorg.conf, but it's possible that doesn't matter since it didn't add or remove anything that I see, it just can't work because of the intial corruption. I would really like to see on a straight debian testing system install if this issue occurs. If it does not occur, a clean debian can be created via smxi or just do the base install, though the debian installer creates a very bloated system if left to its defaults. techpatterns.com/forums/about1085.html&highlight=businesscard that's some very old directions to do that install, but I think maybe the business card iso isn't available anymore, but the netinstall one is for sure. Anyway, I'd like to see if this issue is coming from debian xorg or if it's an ubuntu/mint issue. Let's see what mint is really using. This is from a straight debian system, sid. :: Code :: # run this command and paste in the output.
dpkg -l | grep -iE 'xorg|xserver' ii x11-xserver-utils 7.7+1 i386 X server utilities ii xorg-docs 1:1.7-1 all Miscellaneous documentation for the X.org X Window System ii xorg-docs-core 1:1.7-1 all Core documentation for the X.org X Window System ii xorg-sgml-doctools 1:1.11-1 all Common tools for building X.Org SGML documentation ii xserver-common 2:1.14.4-1 all common files used by various X servers ii xserver-xorg 1:7.7+4 i386 X.Org X server ii xserver-xorg-core 2:1.14.4-1 i386 Xorg X server - core server ii xserver-xorg-input-evdev 1:2.8.2-1 i386 X.Org X server -- evdev input driver ii xserver-xorg-input-kbd 1:1.7.0-1+b1 i386 X.Org X server -- keyboard input driver ii xserver-xorg-input-mouse 1:1.9.0-1+b1 i386 X.Org X server -- mouse input driver ii xserver-xorg-video-vesa that will show the xorg package versions, if you see anything with ubuntu in there, mint is inserting bad packages into debian. Something is fundamentally wrong there, and it may explain all those mysterious inxi outputs of drivers failed in Xorg.0.log, with output like that, of course the drivers, which should never be loaded, failed. However, given that sgfxi is used a lot, and about 1/3 of uses are for amd/fglrx, I find it unlikely that all systems using it are having this issue. But it is starting to explain somoe primarily ubuntu issues in inixi and loaded xorg drivers not being right, along with failed xorg driver loads in Xorg.0.log I can't spend much more time on this today, but you are doing a great job providing feedback so be sure to understand you are in no way at fault in this failure, the trick is to figure out what is. Back to top |
|
Here is my output:
:: Code :: $ dpkg -l | grep -iE 'xorg|xserver'
ii x11-xserver-utils 7.7+1 amd64 X server utilities ii xorg 1:7.7+4 amd64 X.Org X Window System ii xorg-docs-core 1:1.7-1 all Core documentation for the X.org X Window System ii xorg-sgml-doctools 1:1.11-1 all Common tools for building X.Org SGML documentation ii xserver-common 2:1.14.3-5 all common files used by various X servers ii xserver-xorg 1:7.7+4 amd64 X.Org X server ii xserver-xorg-core 2:1.14.3-5 amd64 Xorg X server - core server ii xserver-xorg-input-all 1:7.7+4 amd64 X.Org X server -- input driver metapackage ii xserver-xorg-input-evdev 1:2.8.2-1 amd64 X.Org X server -- evdev input driver ii xserver-xorg-input-mouse 1:1.9.0-1+b1 amd64 X.Org X server -- mouse input driver ii xserver-xorg-input-synaptics 1.7.1-2+b1 amd64 Synaptics TouchPad driver for X.Org server ii xserver-xorg-input-vmmouse 1:13.0.0-1+b1 amd64 X.Org X server -- VMMouse input driver to use with VMWare ii xserver-xorg-input-wacom 0.23.0+20131011-1 amd64 X.Org X server -- Wacom input driver ii xserver-xorg-video-all 1:7.7+4 amd64 X.Org X server -- output driver metapackage ii xserver-xorg-video-ati 1:7.2.0-1+b2 amd64 X.Org X server -- AMD/ATI display driver wrapper ii xserver-xorg-video-cirrus 1:1.5.2-1+b1 amd64 X.Org X server -- Cirrus display driver ii xserver-xorg-video-fbdev 1:0.4.4-1 amd64 X.Org X server -- fbdev display driver ii xserver-xorg-video-intel 2:2.21.15-1+b2 amd64 X.Org X server -- Intel i8xx, i9xx display driver ii xserver-xorg-video-mach64 6.9.4-1+b1 amd64 X.Org X server -- ATI Mach64 display driver ii xserver-xorg-video-mga 1:1.6.2-1+b1 amd64 X.Org X server -- MGA display driver ii xserver-xorg-video-modesetting 0.8.0-1+b2 amd64 X.Org X server -- Generic modesetting driver ii xserver-xorg-video-neomagic 1:1.2.8-1 amd64 X.Org X server -- Neomagic display driver ii xserver-xorg-video-nouveau 1:1.0.10-1 amd64 X.Org X server -- Nouveau display driver ii xserver-xorg-video-openchrome 1:0.3.3-1 amd64 X.Org X server -- VIA display driver ii xserver-xorg-video-qxl 0.1.0-2.1 amd64 X.Org X server -- QXL display driver ii xserver-xorg-video-r128 6.9.1-1 amd64 X.Org X server -- ATI r128 display driver ii xserver-xorg-video-radeon 1:7.2.0-1+b2 amd64 X.Org X server -- AMD/ATI Radeon display driver ii xserver-xorg-video-savage 1:2.3.7-2 amd64 X.Org X server -- Savage display driver ii xserver-xorg-video-siliconmotion 1:1.7.7-2 amd64 X.Org X server -- SiliconMotion display driver ii xserver-xorg-video-sisusb 1:0.9.6-2 amd64 X.Org X server -- SiS USB display driver ii xserver-xorg-video-tdfx 1:1.4.5-1 amd64 X.Org X server -- tdfx display driver ii xserver-xorg-video-trident 1:1.3.6-2 amd64 X.Org X server -- Trident display driver ii xserver-xorg-video-vesa 1:2.3.3-1+b1 amd64 X.Org X server -- VESA display driver ii xserver-xorg-video-vmware 1:13.0.1-2 amd64 X.Org X server -- VMware display driver Meanwhile I'm thinking about changing the OS to a "clean" / "natural" & stable Version of Debian. For now I'm unsure if this would be the right decision for me. You have to know, I'm not that Linux pro. I came from opensuse, I like the Cinnamon desktop and the idea to use Debian as base. But it seems that LMDE isn't ready?! :: Quote :: I can't spend much more time on this today, but you are doing a great job providing feedback so be sure to understand you are in no way at fault in this failure, the trick is to figure out what is.Hey don't worry! You can't imagine how grateful I'm, cause I found someone who tries to help me! So I'm glad and proud that I can help with my feedback. ;) If you like let's give another try tomorrow. Anyway, here is time to sleep, one hour before zero... *yawning* see u tomorrow & thanks again. Back to top |
|
You can try this ancient option, made for mepis, that had similar issues with massively corrupted xorg.conf files.
I cannot guarantee this will work, but give it a try, it downloads a static copy of xorg.conf but it may be out of date: sgfxi -! 30 I may update that xorg.conf with a new one that is stripped down and basic. then proceed with normal sgfxi install, now if a corruption occurs, it's certainly caused by aticonfig. Note: that may mess up your mouse, but don't worry about it, just see if the screen loads after running sgfxi. If it works, I'll update the file to be more current default. Give that a try, if it doesn't work, no loss, just: rm -f /etc/X11/xorg.conf no risk there. Back to top |
|
Well, nice try and the xorg.conf looks much better, but the issue is still there. After installing and rebooting my computer I got again the strange green signs in the top left corner.
Here is the new built xorg.conf :: Code ::
# xorg.conf (X.Org X Window System server configuration file) # # This is a replacement xorg.conf file designed to work around various # automated xorg.conf errors sgfxi users have been seeing, from things like # aticonfig, nvidia-config as well as possibly distro config tools. # # Please check your original xorg.conf found here: /etc/X11/xorg-conf-orig-sg # to make sure your keyboard and mouse data are correct. # # Download URL: http://smxi.org/sg/data/dm-1-xorg-conf # # Edit this file with caution, and see the xorg.conf manual page. # (Type "man xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # dpkg-reconfigure -phigh xserver-xorg ###**EOF**### Section "ServerLayout" Identifier "aticonfig Layout" Screen 0 "aticonfig-Screen[0]-0" 0 0 EndSection Section "Module" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" EndSection Section "Monitor" Identifier "Monitor 0" EndSection Section "Monitor" Identifier "aticonfig-Monitor[0]-0" Option "VendorName" "ATI Proprietary Driver" Option "ModelName" "Generic Autodetecting Monitor" Option "DPMS" "true" EndSection Section "Device" Identifier "Device 0" Driver "fglrx" BusID "PCI:1:0:0" EndSection Section "Device" Identifier "aticonfig-Device[0]-0" Driver "fglrx" BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen 0" Monitor "Monitor 0" DefaultDepth 24 SubSection "Display" Depth 8 EndSubSection SubSection "Display" Depth 15 EndSubSection SubSection "Display" Depth 16 EndSubSection SubSection "Display" Depth 24 EndSubSection EndSection Section "Screen" Identifier "aticonfig-Screen[0]-0" Device "aticonfig-Device[0]-0" Monitor "aticonfig-Monitor[0]-0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Section "Extensions" Option "Composite" "enable" # Option "RENDER" "disable" EndSection My question is: :: Code :: BusID "PCI:1:0:0"Is this the correct spelling or do I have to change this into 01:00.0? With or without PCI in front? Back to top |
|
it's correct, xorg internally changes the . to a :
We have now removed some suspects, aticonfig is innocent, the original error is in the X config file generator. use pastebin.com to post your /var/log/Xorg.0.log again. Back to top |
|
I"m curious, just try commenting out, with # marks, the ati config blocks, for Device, and for Screen, then try restart X:
:: Code :: Section "Device"
Identifier "aticonfig-Device[0]-0" Driver "fglrx" BusID "PCI:1:0:0" EndSection that would look like this: :: Code :: #Section "Device"
# Identifier "aticonfig-Device[0]-0" # Driver "fglrx" # BusID "PCI:1:0:0" #EndSection As you can see, aticonfig seems to be running after the driver install, and since as usual with amd stuff, it's badly programmed, it's failing to find the existing Device 0 and Screen 0, and making new ones. Or maybe comment out the non ati Device and Screen blocks, and see what happens then. This is all messed up though, I've no real idea why things are doing what they are doing, I would really like to hear from a Debain fglrx user to see if these issues exist on debian, with dual cards. If they do not exist on debian, I may finally just drop mint support once and for all, I benefit in NO way trying to support them, but I will follow this up until I can with absolute certainty state that the issue is caused by mint/ubuntu and not something totally non related. The advantage of supporting ubuntu/mint is that corner cases are exposed and tightened up, which usually ends up benefiting debian users long term, and it tends to make sgfxi more robust overall, but if issues crop up with only mint users, and if I can't get those issues resolved, i'll have to at some point call it quits in respect of my time. If it turns out this is a mint specific issue, I believe I will cease all mint support, along with ubuntu, it's never been worth my while, and it's always caused me headaches, except for one brief moment when the original lmde developer, ikey, worked on it, then it was actually helpful to collaborate with them, because they tracked down issues like this and helped me resolve them, fairly quickly. Both ubuntu and mint are made for profit at a certain level, and I have no real interest in spending my time helping them to be honest. But if this is an actual straight debian issue too, of course, I want to get it resolved. Back to top |
|
The absolutely best case scenario with your case would be you to do a test install of debian testing on the same exact machine, and then see what happens with sgfxi and fglrx. ie, is the problem intrinsic to the software being used, or is something else involved. However, I do appreciate liking something like cinnamon, that's a real thing that is native to mint, one of the few things actually.
Here's the secret with debian, it's not very complicated: you know how regular distros always get all excited about their new releases? In debian, like arch and gentoo, you install once then update it. Different idea, different skill set required to maintain it, but in general a real debian system does not need to be reinstalled, with one exception, the case where you switch from 32 to 64 bit, then it's probably best to reinstall. Xserver is failing to find screen 0, the xorg logs show it clearly. Back to top |
|
All times are GMT - 8 Hours |