hi
feel free to move if not a bug....Its more of a feedback cum request suggestion ok? 1) today's smxi failed with an error 100 for the update of the debian pdiffs b) the suggestion to try running by downloading the smaller stuff failed 2) I am not sure why....but I have being doing smxi for donkey years and I suspect it is a small change in squeeze mirror for my aussie site? Here is my new debian list deb ftp.au.debian.org/debian/ unstable main contrib non-free 3) The script had an option to change the debian list but gave me an error along the lines of.....this script does not recognise the format of your sources list 4) (blushes) Not sure but I had an hash symbol and an old link to my old ISP's mirror of debian as the first line As I said ...smxi has always worked with sid....and sid still exists in that aussie link....so I am stumped So, my suggestion is maybe the script can have an option to build a completely new debian.list? 5) I solved my issue by following the aussie link to see what my new mirror was called.....the old one was called sid and I changed to unstable but not sure if that was the only reason or not I use partimage....so if you need a full log of this issue I can restore the old image and old file....and link to it if needed regards Back to top |
a lot of times when you get that apt update error it's because a keyring is expired, opera for example requires manual renstall of their keyrings, which is why that is an option in non free package install, update opera keyrings.
That's the usual cause for errors, or a temporary glitch in the repo. Back to top |
|
when smxi/sgfxi read sources.list files it ignores any line starting with # so that's not the issue.
Not recognizing the format simply means it isn't this format: http: //ftp.xx.debian.net/.... i never tried to make that repo changer handle the other repos because they come and go, and it's too hard. I just use mirrors.kernel.org and leave it at that, with approx so I only have to grab the new packages once for my test systems. all the scripts were updated to wheezy/sid detection some weeks ago, soon after squeeze went stable. Back to top |
LinuxMint 10 fully updated, installed and ran sgfxi
This is for 'goer' a regular Mint 10 user, he came into #smxi the other day and had difficulties with the instructions, it was noted at the time that the 173.14.28 nvidia driver may be the issue. Today he had the time to try again and this is the result. first attempt in tty , the logs after... 1.sgfxi.log pastebin.com/SCPrwsCP 1.smxi.log pastebin.com/mwHCcdKa 1.Xorg.0.log pastebin.com/hhkK4VsC rebooted, Then got black screen - I ctrl+alt+F1 and logged in. Then ran sgfxi again (to get rid of nouveau, as instructed by script) 2.sgfxi.log pastebin.com/M3e5JbFP 2.smxi.log pastebin.com/c8Pp2gKd 2.Xorg.0.log pastebin.com/6CaLgV6v Rebooted and black screen.. entered vesa in grub (before nomode) and rebooted. Then got black screen again, ctrl+alt+F1 worked Then reboot in safe mode so I could select graphics - start X in normal mode 3.Xorg.0.log pastebin.com/whdjayGi 3.Xorg.failsafe.log pastebin.com/YTeSwWgD So he is now in a low rez X session. Note previous attempts at this the other day, showed running sgfxi did not fix the issue if run yet again at this stage.. System: Host goer-desktop Kernel 2.6.35-22-generic i686 (32 bit) Distro Linux Mint 10 Julia CPU: Dual core Intel Pentium D (-MCP-) cache 2048 KB flags (lm nx sse sse2 sse3) bmips 11999.5 Clock Speeds: (1) 3000.00 MHz (2) 3000.00 MHz Graphics: Card nVidia NV34 [GeForce FX 5500] X.Org 1.9.0 Res: 1024x768@0.0hz GLX Renderer N/A GLX Version N/A Direct Rendering N/A Audio: Card Intel 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller driver Intel ICH at ports d800 dc00 BusID: 00:1f.5 Sound: Advanced Linux Sound Architecture Version 1.0.23 Network: Card Realtek RTL-8139/8139C/8139C+ driver 8139too v: 0.9.28 at port b400 BusID: 02:05.0 Disks: HDD Total Size: 1160.2GB (65.8% used) 1: /dev/sda SAMSUNG_HD160JJ 160.0GB 2: USB /dev/sdb 10EACS_External 1000.2GB Partition: ID:/ size: 8.0G used: 2.8G (38%) fs: ext4 ID:/home size: 51G used: 71M (1%) fs: reiserfs ID:swap-1 size: 2.29GB used: 0.00GB (0%) fs: swap Info: Processes 142 Uptime 14 min Memory 205.7/2011.8MB Runlevel S Client X-Chat 2.8.8 inxi 1.4.12 Back to top |
I also need to see his /etc/X11/xorg.conf
file to see what happened. the reboot logs shows a cleared nouveau, ie, it's not running, ie, that means the blacklisting is working, thank god. does ubuntu mint use gdm or gdm3? in other words, if you type in console: service gdm restart does it restart gnome? Then second set of logs shows vesa was correctly installed and should have been running and starting his desktop in low res vesa mode, and it shows that the nvidia 173 driver was installed without error, as far as I can see anyway. Also need to confirm that nvidia card is actually on pci bus: NVIDIA GPU GeForce FX 5500 (NV34) at PCI:1:0:0 (GPU-0) you can confirm that by: lspci -nn | grep VGA and also look in the xorg.conf file to make sure it matches that. Basically my initial guess, given that vesa is failing to start x at all, and vesa is a safe default low res driver that should always work, especially for legacy cards, is that the hardware is defective. Unless the pci busid is off or wrong in xorg.conf which could be a sgfxi error, this error is not related as far as I can see with sgfxi at all. Normally I would say post a bug report to nvidia, but if vesa also failed to start (make sure though, but xorg log shows vesa starting in Xorg on the reboot if I read it right) then the problem does not lie with vesa or nvidia driver in my opinion. If we all valued our time slightly, we'd simply realize that the time we are spending here, unless this is a reproducing bug on all user systems, ie, all nvidia 5000 series cards are failing, both in vesa and nvidia mode, we're not going to get very far is my guess. There's a few other options it could be, for example, if on reboot black screen appears, with xorg.conf using vesa driver, and if then one moves xorg.conf like so: mv /etc/X11/xorg.conf /etc/X11/xorg.conf-bu4 and then does: service gdm restart and x starts, then the problem may lie in a new xorg syntax issue re xorg 1.9, but again, that would be showing up for all users of new mint/ubuntu + sgfxi + X -configure generated xorg files. Total failures to start x, ie, blackscreen, without corresponding /var/log/Xorg.0.log error messages, means either the driver itself is failing or hte hardware is failing, and since you tried restart with vesa and with nvidia, and both failed, that really suggests hardware failure, unless restart with no xorg.conf file by moving the current one somewhere works, then it suggests that some xorg.conf syntax is making it fail. Back to top |
Just finished setting up Debian Sid KDE. Ran smxi for the first time on it everything worked great till I got to the graphic section. Went to install my Nvidia driver I notice that I did not see any text saying that it was blacklisting nouveau. I know recently I built 2 other Debian system that showed that nouveau was blacklisted and I had to shutdown before installing my Nvidia driver. Where can I check to see if nouveau was blacklisted or not ? And if not blacklisted what do I need to do to blacklist it. All 3 systems were built on same computer not sure why smxi blacklisted nouveau on 2 out 3.
Back to top |
smxi / sgfxi (sgfxi is what blacklists, smxi just launches sgfxi) blacklist nouveau if you request an nvidia non free install and if nouveau is detected as running.
If lsmod does not show nouveau, then sgfxi does not blacklist, but if it is running, then it will. so I would expect that for whatever reason, nouveau was not running, or you found a bug in sgfxi, but I think nouveau was not running, since if it was, and if it weren't blacklisted, the nvidia non free install would have failed. Basically, when sgfxi receives the 'failed' signal from rmmod nouveau command, it implements all the blacklist steps, since nouveau cannot in fact be removed as of this stage of linux kernel development. You remember, a pain, like in windows? Maybe not for the distro driver though, not sure about that. distro driver is like the nvidia-glx or other packaged drivers, I don't do much testing on those so there may be failings to blacklist, or they may do that themselves, I don't know. Back to top |
A Successful install of a nvidia 8200MG driver on Mint10 32bit
Mint10 32bit , fully updated (night before), installed smxi scripts. tty as su , ran sgfxi , ERROR: (214) Cannot create your new /etc/X11/xorg.conf because X cannot be killed. pastebin.com/p5MUDamE (sgfxi.log) re-ran script as xserver was closed, checked f7, script died because I had no net (wifi shutdown) connected ethernet, tried again, and it ran. Installing the 260.19.44 (untested I used .36 before). Interesting that I wasn't offered any options, just strait into installing this particular driver!! nouveau errors, reboot, says run sgfxi again. Rebooted into X , no issue, xorg.conf pastebin.com/anvxCEY5 sgfxi.log pastebin.com/414k40dZ tty ran sgfxi again... NO reboot necessary, just select start xsession and the nvidia driver worked no issues.. sgfxi.log pastebin.com/MH3iiYFy xorg.conf pastebin.com/N2WLAQPs my inxi -F pastebin.com/PdYWSgnn[/u] Back to top |
sgfxi always installs the correct driver, there are no options, you can pick alternates as extra start options but by default the command: sgfxi
will install the correct non free driver for your system, and the command: sgfxi -n will install the basic free driver sgfxi -N nouveau will install nouveau, once that is stable it will become the default for nvidia. sgfxi -N vesa strips out everything then starts with safe mode vesa driver, which usually works for everyone, except goer system. Back to top |
All times are GMT - 8 Hours |