|
:: techAdmin wrote :: I'm not sure, but it looks like you have a package with a bad post/pre install script, where exactly do you see that sed error?
If you can pinpoint the exact location I'll see if it's smxi, but my first guess is it's a bad package script in apt. It shows up at the end of the pre-upgrade tasks. here's the context: :: Quote :: Testing hold/install list package status...
Changing lsb-base package status in dpkg to: hold ------------------------------------------------------------------ It looks like your kdm runlevels got changed by accident. Resetting to default 5 5 now... sed: -e expression #1, char 3: unterminated `s' command update-rc.d: using dependency based boot sequencing update-rc.d: using dependency based boot sequencing update-rc.d: warning: kdm start runlevel arguments (5 5) do not match LSB Default-Start values (2 3 4 5) update-rc.d: warning: kdm stop runlevel arguments (none) do not match LSB Default-Stop values (0 1 6) ------------------------------------------------------------------ Finished with the pre-upgrade tasks. Back to top |
|
go to line 507 of: /usr/local/bin/sm-lib-du-fixes
and make sure it says: stopLevels=$( sed "s/$INIT_LEVEL//" <<< $stopLevels ) that's the only sed there, also that function should have only triggered one time, after the kde4 upgrade from kde 3.5, though it might now and then trigger if debian defaults are used for kdm. The sed there should not generate any error, as you can see, the s is not unterminated, it's normal. I've now added another safety test there in case you have a null init level for some weird reason, but that would show a different error in any case, but now it will skip it. update-rc.d may have a bug in it. Back to top |
|
As I said, I installed the drivers already, one in the traditional way and the other with the -K option.
sgfxi detected both new kernels when I first tried the -! 40 option but couldn't run a certain command. Maybe there's some extra package needed? Do you still want me to run sgfxi -! 40 even with the drivers already installed? I suspect something may have failed in sgfxi because I installed the kernels directly with apt-get and not with smxi. One thing that reinforce this suspicion is that I later purged the kernel I was using and sgfxi still gave an option for it. I'm using one of the new kernels right now. Back to top |
|
it's not possible to diagnose with the information you supplied.
I am assuming, as I said, some glitch in a package somewhere, but it's not possible to say anything further. I can find no issues with sgfxi. Now, if you installed a kernel manually, and didn't install the kernel headers, then you'd see a failure of course, because the -! 40 loops doesn't do a lot of the checking sgfxi does. saying it 'couldn't run a certain command' unfortunately does me or you no good at all, since that is about as vague as you can get. Next time, take a piece of paper and write down the error so you can help me help you, verbatim, or you can copy it in console if you have gpm, and paste it into a text file, there's a lot of ways to help find issues and fix them, but zero information isn't one of those ways. What you have to do is what I said, then post the actual errors, not a faint memory of them. If you don't want to do that simple test, ie, install the beta driver if you have a newer nvidia card, then, in X, run the -! 40 command so you can see the actual error, copy it, and post it here, that's fine, but then I cannot help you at all, how could I? with no actual error information to go on? By the way, I did find one oversight in sgfxi while testing this, which was that the -! 40 command did not have good error messages in some cases, and it didn't handle the -B option, like: sgfxi -! 40 -B I fixed that issue. Also, the -! 40 option does not install by default the driver you have installed, it installs the default driver sgfxi would install based on the card detection. The -o <driver number> or -B option is required to install another set of modules, as I discovered while testing sgfxi. I won't type this suggestion again, so if you chose to not do it, please realize you have not given me any information to debug the issue you are seeing, which is almost certainly some oddity in your specific installation. sgfxi doesn't care how you installed the kernels. Back to top |
|
I'm not complaining. I pointed it out because I thought it could be better than nothing. I also thought sgfxi would log the errors but it seems that as it actually didn't even start the installation (only performed the extra kernels detections but for some reason failed to proceed to the installation) then it didn't start the log.
One other thing that may have influenced is that I had never booted to those kernels before as I had just installed them. I had a Liquorix kernel and installed with apt-get the newer version and also the Debian version. I installed both image and headers for both (Liquorix pulls the headers automatically). Now I have purged (with apt-get) image and headers for the previous Liquorix I was using. The drivers are installed in both currently available kernels and it seems sgfxi -! 40 would work fine. I didn't install the beta but from the messages below all seem to be working well (it detected that I have the driver already and aborted). The only "glitch" is that it still searches for the older kernel in /boot/grub/grub.cfg but obviously doesn't find it. It must be because APT didn't remove the directory for it in /lib/modules/. EDIT - never mind, I see it's just a check. The output of sgfxi -! 40 :: Code :: root@debian:/home/temp# sgfxi -! 40
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Confirming full kernel list from /lib/modules... Checking 2.6.32-5-686 in /boot/grub/grub.cfg.... Confirmed Checking 2.6.35-5.dmz.1-liquorix-686 in /boot/grub/grub.cfg.... Invalid - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - OK, installing modules to all confirmed kernels now... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sgfxi :: version: 4.15.7 :: last updated: September 24 2010 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - graphics card information: series: nVidia NV44A [GeForce 6200] (rev a1) vendor: XFX Pine Group Inc. ram: 256M (note: not accurate for built in graphics) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - You are using the following options: -A - Autorun is selected -k - building nvidia kernel module using previously installed driver -K - You are installing a graphic driver onto the kernel: 2.6.32-5-686 The graphics installer will be building a module for the nvidia driver: 256.53 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Starting nvidia module build process checks for kernel: 2.6.32-5-686 Checking for driver run package NVIDIA-Linux-x86-256.53.... File Exists Checking for distribution nVidia driver packages.... None Detected Checking for installed nVidia driver.... Driver Installed Checking installed driver 256.53 matches requested driver 256.53.... Drivers Match Checking to make sure Xorg has not been updated since last nVidia install.... Xorg Not Updated Checking for previous nVidia driver module for 2.6.32-5-686.... PRESENT ERROR: (170) An nvidia module already exists for 2.6.32-5-686 at path: /lib/modules/2.6.32-5-686/kernel/drivers/video/nvidia.ko You must either remove this manually, or install a new driver with sgfxi. Installing a driver will remove all previous modules, then you can rebuild them with the -! 40 option (see sgfxi -h for more information on that method). Log file is located here: /var/log/sgfxi/sgfxi.log Exiting script now. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hey, did it work? Great! Bye for now. root@debian:/home/temp# Next time I install a newer kernel I'll try to run sgfxi -! 40 again, see how it goes and if needed write down any eventual errors. Back to top |
|
thanks for the follow-up.
Back to top |
|
Works.
I just installed the latest Liquorix (I have the metapackage 2.6-liquorix-686), run sgfxi -! 40 and it correctly installed the module for it.
Back to top |
|
my guess is this: you were missing something on one -! 40 install, and when you then ran the install for eacy kernel manually, that something was added, now -! 40 works.
Ideally we'd know what that something was, so sgfxi could maybe test for it, but it might be testing for it for all I know, so we'll leave this one marked, watch for further issue reports that remind me of this one to see if there is a subtle issue that needs improvement. Thanks for tracking this and providing follow up, that's helpful. Back to top |
|
Ah, however, I note, you use metapackages.
Not all smxi features work when you use kernel metapackages, some things you have to make sure are right yourself, the full features are triggered when users do NOT have metapackages, because I cannot test for some things unless those are not used. Back to top |
|
Ok, for now.
Actually I at first had no metapackages and set liquorix as the default kernel in smxi so smxi would check for the updates (I found this way smxi would work better, as you just confirmed). But that's a newbie option so to speak. It makes running smxi slightly slower (checks kernels) and also it reruns initramfs update and update-grub after a kernel install/removal even if that's already done by APT. I guess that's necessary in some cases but I'm experienced enough to look at messages like "you may need to run your boot loader again". So I let smxi without a default kernel and installed the metapackages (but I think I'll settle with this version of Liquorix's - my hardware is old enough - and just keep the metapackage for Debian's kernel). So that time I had made those changes to smxi, installed manually both the metapackages and the then latest liquorix version and ran sgfxi -! 40. With all that at once and add to that that it was the first time I had run the -! 40 option... But it's working fine now (today I even cleaned up the old folders in /lib/modules/) and so life goes on. Back to top |
|
All times are GMT - 8 Hours |