Page: 1, 2, 3 ... 22, 23, 24  Next

smxi sgfxi svmi :: bug reports
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3737
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
The title says it all. Please include the log file from your most recent run through with the script that had the bug. Use the convenient pasting site, paste.debian.net then just copy the url into your bug report.

Post bugs in this thread if you can, the forum doesn't have merge thread features, so for most bugs that are minor, it's useful to keep things neat. For major issues, a new thread is probably not a bad idea.

Log files:
smxi - /var/log/smxi.log
svmi - /var/log/svmi.log
sgfxi - /var/log/sgfxi/sgfxi.log

Usually I can tell what happened from the log, and if I can't, I can add more logging data until I can.

Please don't copy and paste the logs here, they are too big and long. And do not assume you have the correct part of the log and just paste part of it, that defeats the purpose of using logs.

Make the pastebin service keep the log for as long as possible, 3 or 4 days.
Back to top
Missing warning section file: status
nfortier
Status: New User - Welcome
Joined: 20 Jan 2009
Posts: 2
Reply Quote
Got the above message running smxi (sidux 2008-04)
Log:
paste.debian.net/26469
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3737
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
Yes, that means smxi failed to get a small file it needs to test the status of the dist-upgrades.

That means one of two things, the smxi server had a temporary failure (VERY UNLIKELY), or that your connection got too slowed down, or failed in some other way unknown to us.

The solution is to retry smxi. The message is not an error, it's a statement of fact, smxi could not download a file it needs in order to proceed, and the failure to download is almost always the result of some local ISP or router issues, and very very very rarely might be caused by a momentary failure in the smxi servers.

By the way, thanks for reading the bug reporting procedure and using paste.debian.net to paste your smxi.log file, which makes debugging the issue far easier, and for posting here, in the proper thread.
Back to top
nfortier
Status: New User - Welcome
Joined: 20 Jan 2009
Posts: 2
Reply Quote
I retried smxi and it worked fine. My Internet connection was working but indeed rather slow this morning.
Thank you for your quick response!
Back to top
smxi: binary NVIDIA driver not complete (GLX fails)
Crypto1971
Status: Guest
Reply Quote
Hi,

on my sidux notebook when using smxi for installing latest apt-get kernel and re-installing binary NVIDIA driver afterwards (without re-boot), installing the driver works but glx installation is not working.

I have to reboot, run smxi again and re-install binary NVIDIA driver to get nvidia glx working.

Regards,
Crypto.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3737
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
I've heard of this issue off and on but have never been able to reproduce it, usually because the error is actually caused by something slightly off in the user system.

If I remember right, the cause of the error was sometimes a bad menu.lst, or having grub installed in the wrong place, and was totally unrelated to smxi, which sends sgfxi the kernel to install to as long as you haven't exited smxi before the graphics install question.

check list: single boot system? grub on mbr?

if not, where is grub? some users have actually managed to install grub both in partition and in mbr, and so new kernels don't actually get added where you think they will.

When you say nvidia glx, I am assuming you are referring to the standard nvidia run package binary install, not the debian method install. nvidia-glx is the name of the debian nvidia driver package, I think.

Beyond this, you'll have to take a very close look at your system to find why it's not working, and I suspect once you do that, listing all relevant details, it will become quite obvious why it didn't work.

For example, sgfxi tells you what kernel it's installing the driver to, that information is logged in /var/log/sgfxi/sgfxi.log
and smxi shows what command it sent sgfxi in /var/log/smxi.log

when you rebooted, you'd check to s

Also, you need to see if you're using that dmakms stuff, or whatever it's called, sgfxi doesn't look for that yet, it's something I didn't really want to interact with yet, so sometimes that junk might cause highly unpredictable problems as well.
Back to top
Re:
Crypto1971
Status: Guest
Reply Quote
:: techAdmin wrote ::
I've heard of this issue off and on but have never been able to reproduce it, usually because the error is actually caused by something slightly off in the user system.

If I remember right, the cause of the error was sometimes a bad menu.lst, or having grub installed in the wrong place, and was totally unrelated to smxi, which sends sgfxi the kernel to install to as long as you haven't exited smxi before the graphics install question.

check list: single boot system? grub on mbr?


grub is installed in mbr. Have never used anything else apart from that. All kernel updates are registered in the menu.list file and can be launched via grub. Also, kernel removal works as well.

It is a sidux-system that has Windows XP installed on one NTFS partition as well. I can run Windows from grub without problems.

[...]

:: techAdmin wrote ::

When you say nvidia glx, I am assuming you are referring to the standard nvidia run package binary install, not the debian method install. nvidia-glx is the name of the debian nvidia driver package, I think.


Yes, exactly. I meant the glx driver that is installed by the binary NVIDIA driver setup. Not the apt-get package, if there's one.

:: techAdmin wrote ::

Beyond this, you'll have to take a very close look at your system to find why it's not working, and I suspect once you do that, listing all relevant details, it will become quite obvious why it didn't work.

For example, sgfxi tells you what kernel it's installing the driver to, that information is logged in /var/log/sgfxi/sgfxi.log
and smxi shows what command it sent sgfxi in /var/log/smxi.log


OK, I have found something in the sgfxi.log file:
:: Quote ::

=========================================================
START sgfxi LOGGING:
=========================================================
Script started: 2009-06-26-14:36:15
Video Card Information: nVidia Corporation C51 [GeForce Go 6100] (rev a2)
Video Card Type: 10de
Video Card Number: 0247
Installing driver to kernel: 2.6.30-0.slh.5-sidux-686
sgfxi script version: 4.6.22
sgfxi start options: -B -c -j 1 -D -X -P apt-get
SYSTEM_BASE: sid
=========================================================
INSTALL_TO_KERNEL:
KERNEL_VERSION: 2.6.30-0.slh.5-sidux-686
KERNEL_BASE: 2.6
KERNEL_THREE: 2.6.30
KERNEL_THIRD: 30
[cleaned up unneeded log data]


Maybe that error message is useful for tracking down the problem?

About the dmakms stuff I am not sure if that is being used. I have used the smxi script for updating kernel and graphics driver hoping it would take everything relevant into account, which it did (mostly).

Thanks for your help,
Crypto.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3737
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
the commands clearly show no manual installed kernel was present, which means that sgfxi was installing to your current kernel.

If you use kernel metapackages smxi does not know when you have upgraded a kernel.

I assume that's what it is, or that you exited from smxi. Everything is working correctly in the log you showed, unless that's the log from the reboot install, then you need to see the previous one.

Use paste.debian.net to upload the logs if you need to show more, but as it stands, nothing is wrong, it's working exactly as it's supposed to.

If you use manual smxi kernel install it sets a script global with the new kernel you installed, then passes that to sgfxi with the -K <kernel name> option. sgfxi will then tell you clearly that it is installing the driver to <kernel name> where it tells you to hit enter to continue or exit.

If it doesn't tell you this, it's installing to the current kernel, which is the default.

If you are using metapackages, remove them using the metapackage remover tool in smxi, which is why it's there, those just create problems and are a general pain, especially for non free driver modules.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 3737
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
If you did use the manual smxi kernel install method, please use paste.debian.net to paste your /var/log/smxi.log file and I'll see what the problem is, the only actual bug is if the global fails to set after a manual kernel install with smxi, no exits, then on to graphics driver install. Failing to set that global is a bug, if that is what happened, otherwise it's all working as expected.
Back to top
Crypto1971
Status: Guest
Reply Quote
:: techAdmin wrote ::
If you did use the manual smxi kernel install method, please use paste.debian.net to paste your /var/log/smxi.log file and I'll see what the problem is, the only actual bug is if the global fails to set after a manual kernel install with smxi, no exits, then on to graphics driver install. Failing to set that global is a bug, if that is what happened, otherwise it's all working as expected.


I have used the option in smxi to update the kernel using the latest apt-get kernel. Hope that means I have used the manual smxi kernel install.

The file I pasted here (sorry for me not using the paste.debian.net) is the full length sgfxi.log, so no need to paste it ;-)

I was indeed doing that (manual) kernel install, then no exit, then onwards to graphics driver install. If you look that the header of the log file then there is

:: Quote ::

Installing driver to kernel: 2.6.30-0.slh.5-sidux-686


which to me looks like the script correctly found the kernel for which it should install the graphics driver. This kernel version number is not handed over to the line afterwards which is empty:
:: Quote ::

INSTALL_TO_KERNEL:


which seems to me it can only be a bug with some global, as you mention it.

Thanks anyway for the fast response!

Kind regards,
Crypto.
Back to top
Display posts from previous:   
Page: 1, 2, 3 ... 22, 23, 24  Next
All times are GMT - 8 Hours