|
yeah, no love, but have something interesting to report, after rebooting and failing to start X, ( no screens found from Xorg.0.log)
I go more the sgfxi generated xorg.conf file, and then attempt to have aticonfig -initial make one for me, and it says pastebin.com/raw.php?i=KnKdm4yr oh, and I am using this post to learn how to use pastebin, sorry Back to top |
|
there's a new xorg log file created every time you start xorg, leave that one alone.
You will establish a baseline with the cleaner xorg.conf file that allows you to debug any failures, the stuff is too messy as is to do any actual debugging on, first the core issues have to be resolved, like the now fixed sgfxi adaption to new amd / fglrx file names, and your broken xorg.conf file.. amd never offered support for kernel 3.7 in 13-4 driver, somewhat astoundingly. Always keep in mind that current amd fglrx should be expected to be between 2 and 4 or even more kernel versions behind current stable kernel. For example, release notes of 13-4 said that it supported only 3.5, although I believe that's false, but that was their claim. I have not read the release notes of 13-6 beta, they are largely not worth reading as a habit, better to check phoronix forums to see what kernels it actually supports without patches. I believe I set sgfxi to assume that 13-6 will support 3.8 kernel, not sure, but I think I did. While I like some debian based distros, I no longer use anything other than actual debian on my systems, although I do use packages from some distros, like www.siduction.org which offers a fine sid/testing kernel, for example. kali looks interesting too, as a tool, there's another new debian based distro, talls, that seems to replace the hyper secure openbsd live cd as a good secure browsing option, for those who need such things. Back to top |
|
I never use aticonfig for anything, at least nothing i've found I needed.
Unfortunately it is not possible to debug derived distros, you have to basically setup the same system on the same hardware with debian before assuming any debian error in my opinion. By the way, the siduction.org live cd gives you a chance to do things like test install fglrx on the livecd, but you have to black list radeon in grub on boot first otherwise sgfxi will insist on a reboot after it blacklists radeon if radeon kms is running. Your system has too many unknowns to support unfortunately, sorry. I had to drop support for derived distributions for this type of reason, it's simply not possible to know what is different, learning that lies 100% on the distro support group, www.siduction.org again is a good example of how that is done well. For example, you can't use wheezy fglrx because that is matched to wheezy kernel, which is I believe 3.2 with the kali kernel, you can't randomly alter core parts of stable debian then expect dependencies etc to work, that breaks the core concepts of debian stable. I do however appreciate the actual sgfxi bug issue report, and those are now fixed, that's as far as I can take it from my end. Back to top |
|
glad I was able to post something useful. I just tried to use sgfxi to write out a nice xorg.conf for the intel graphics and it pretty much does the same stuff as the ati xorg.conf.
I believe that you are on target with the whole mess with the stable arrangment of things, and be prepared for things to not work. I might see about just building a stable wheezy, getting the graphics to work, then adding the Kali stuff a little at a time to see what I can get working... thanks for all your help, I'll be using smxi from now on to get the little stuff cleaned up and working great Dan Back to top |
|
I want to note, re stable releases, sgfxi should always work on them, because the core of the release does not change, ie, if catalyst or nvidia drivers worked today on wheezy, they will work 2 years from now, because wheezy xorg and kernel have not changed.
New fglrx or nvidia will also work generally by the way, so if you encounter an issue with true wheezy, that is of concern because stable releases should be working. Unstable and testing is what is often way ahead of particularly amd fglrx, so failure there is not only not unexpected, it's the norm over time. AMD is getting slower and slower releasing supported drivers for newer kernels and xorg versions, it's getting quite noticeable, but that's what happens when you lay off a bunch of your linux developers... I doubt you'll see any issues with wheezy default install, if you do, it's a sgfxi bug probably, or an fglrx bug, and then it can be traced down without huge difficulty since there are only two variables. Your xorg.conf file concerns me because that is seriously wrong, and from my days of working on distros as a team member, I know that the xorg auto config scripts installers use can and do fail, the mepis one for example was such a mess that sgfxi actually has features/options to junk it and download a good one, but those options are obsolete now and I should remove them, but they were added specifically because mepis config stuff simply had never caught up to current debian as warren, mepis founder and main dev, lost interest in the project. Back to top |
|
H2, I'm feeding off of your earlier comments about possible AMD interns let loose and running wild - or them having perpetual psychotic episodes.
Debian Testing is fun. I have had success forcing the Beta driver, until just last weekend. They should go with a new stable 13.8 driver in the next week or so, but you never know. I would let it ride, but a new kernel is out in Testing, and I'm looking to force-fit their Beta. Getting a wget error. Here's my last run that I let ride with the "old" kernel: :: Code :: =========================================================
START sgfxi LOGGING: ========================================================= Script started: 2013-08-14-08:53:15 Video Card Information: Advanced Micro Devices, Inc. [AMD/ATI] Turks XT [Radeon HD 6670/7670] Video Card Type: 1002 Video Card Number: 6758 Xorg Version: 1.12 Installing driver to kernel: 3.9-1-amd64 sgfxi script version: 4.20.53 sgfxi start options: -B -! 6 SYSTEM_BASE: debian SYSTEM_CODENAME: testing DISTRIB_CODENAME: debian DISTRIB_ID: linuxmint DISTRIB_RELEASE: 1 SIS: linuxmint-debian-64 BITS: 64 FG_DISTRIB_CODENAME: sid FG_DISTRIB_ID: Debian APT_TYPE: apt-get ========================================================= X is Running: true Current Runlevel: 2 Connection is live (0=true): 0 ========================================================= INSTALL_TO_KERNEL: KERNEL_FULL: 3.9-1-amd64 KERNEL_BASE: 3 KERNEL_NUMBER: 3.9 KERNEL_MATH: 9 B_IS_XEN: true Function: create_x_conf - Primary: Start xorg is present with xorg.conf file Function: create_x_conf - Primary: End Function: check_package_manager_updated - Utility: Start sizeWorking: 32 Function: check_package_manager_updated - Utility: End Function: check_supported_driver - Utility: Start Function: check_supported_driver - Utility: End Function: set_cpu_data - Utility: Start BITS: 64 - arch: amd64 Function: set_cpu_data - Utility: End Function: set_driver_install_version - Primary: Start Function: check_supported_driver - Utility: Start Args: last-check Function: check_supported_driver - Utility: End Function: print_information_continue - Utility: Start Args: info You are using the following options: -B - Use Beta Driver (nVidia only. Only if available) -! 6 - You are using an advanced Testing option. Only use this if you know what you are doing! Function: print_information_continue - Utility: End Function: print_information_continue - Utility: Start Args: standard The graphics installer will be installing the fglrx driver: 13.8-beta1 (beta) This is the latest fglrx Beta driver for your card type. Function: print_information_continue - Utility: End Installing this driver: 13.8-beta1 (beta) Function: set_driver_install_version - Primary: End Function: driver_support_tests - Utility: Start Args: supported-driver Function: driver_support_tests - Utility: End Function: check_kernel_headers - Utility: Start Function: check_package_status - Utility: Start Args: linux-headers-3.9-1-amd64 i Package Version: 3.9.8-1 Function: check_package_status - Utility: End Function: check_package_status - Utility: Start Args: linux-headers-3.9-1-amd64 c Package Version: Function: check_package_status - Utility: End headerName: linux-headers-3.9-1-amd64 headerInstalled: 3.9.8-1 headerAvailable: headerFile: Function: check_kernel_headers - Utility: End Function: check_run_package_tools - Primary: Start Function: check_run_package_tools - Primary: End Function: set_download_info - Primary: Start download url: http://www2.ati.com/drivers/beta/ - driver file: ati-driver-installer-13.8-beta1-beta-x86.x86_64 Function: set_download_info - Primary: End Function: download_extract_driver - Primary: Start Args: http://www2.ati.com/drivers/beta/ ati-driver-installer-13.8-beta1-beta-x86.x86_64 Function: pre_extract_clean_set_up - Utility: Start Args: ati-driver-installer-13.8-beta1-beta-x86.x86_64 Function: pre_extract_clean_set_up - Utility: End ERROR: (197) The graphics driver installer: ati-driver-installer-13.8-beta1-beta-x86.x86_64.run failed to download - wget error. I tried messing with the download link within the script, but I'm not talented enough to pull it off. When I try to go to www2.ati.com/drivers/beta, I get a web page 404 - Not Found. But if I take out "beta", it looks like it might work - so it may not be a problem when 13.8 goes stable. With the 3 month driver production cycle now creating problems, is there a way to modify the sgfxi script to point to a manually downloaded zip file? If it won't work with the latest Xorg/Xserver or kernel at any point in time, no problem. I'm just trying to resolve the stupid downloading site/location problem. This looks like a problem that's here to stay. Thanks for the consideration. The AMD driver quarterly release change is definitely presenting problems with Debian Testing. Back to top |
|
I didn't add the 13.8 beta because I read some bad feedback on it, ie, the system didn't work running it for some users.
I can add it, but because of the idiotically random file name/paths for their betas, I can't add multiple betas, so i was leaving in the last beta, 13.4 or whatever it was, if I add in the new beta, the old one won't work. Re the option to force a download, it's hard, because sgfxi does a lot of testing, and sometimes, patching, of drivers for various xorgs and kernels, it also assigns for amd download paths etc depending on what driver it is. I believe 13.8 supports xorg 1.14 if I remember right, not sure about kernel 3.10 I can add that in however. amd makes generating the paths for amd downloads a real pain in the butt, in fact, if they set out to make it hard to script and automate as their goal they would have a hard time coming up with something more convoluted than what they do now. I basically have to recheck all the paths for almost every new beta driver because they can't make up their minds what to do with paths, file names, and locations, it's totally obvious nobody competent runs that group, it's all very low end and random. Back to top |
|
The immediate problem is that the script wants to download and install the 13.8 beta driver, even though your have not added it (and replaced the 13.6 beta).
I opened up the 08/05/13 script and saw 13.6. And even though you have not replaced 13.6 with 13.8, 13.6 is still there: www2.ati.com/drivers/beta/amd-driver-installer-catalyst-13-6-beta-x86.x86_64.zip If you hit that link, you can still download 13.6. Given that the script is written to download it, it's weird that it attempts to download and install 13.8 - that has a new/screwy file name: www2.ati.com/drivers/beta/amd-catalyst-13.8-beta1-linux-x86.x86_64.zip Given that the 08/05 script will try to download and install 13.8 (which produces a wget error), the beta sgfxi -B -! 6 command is not functional at this point. The 13.8 beta does support the 3.10 kernel. To bypass 13.8 (latest), is there something else I need to add to the command to install 13.6 (or an older beta)? If so, this will be helpful in the future. Thanks again. Back to top |
|
you see what I mean about their constant changing of paths? This is why I am increasingly inclined to just forget about amd, they are simply incompetent, that is absolutely clear to me.
However, I will add yet another path change handler, though I am not sure how much longer I will bother supporting amd, it has been FAR too many years now of this BS with them, I know they are not competent, I know not to buy any hardware that needs their drivers, so it's not easy to motivate to try to track their cr#p. They must be a horrible place to work for. When you compare amd to the total professionalism of nvidia it's not even funny. Supporting nvidia at very worst involves adding a patch once or twice a year for a driver, period. Back to top |
|
what's going on there is that sgfxi checks beta driver on live site for nvidia/amd, then uses that if it's newer than the local one in sgfxi, but this of course only works if the morons at amd stop changing their f#ck paths at EVERY SINGLE f#ck RELEASE of a driver.
Back to top |
|
All times are GMT - 8 Hours |