I found the issue I had.
sgfxi -! 40 calls line 4902 of sgfxi
sgfxi $otherDriver -R -A -k -K $i
And I was running in single user mode so it gave a command not found error:
./sgfxi: line 4902: sgfxi: command not found

sgfxi -K <kernel> works fine in single user mode and can be used instead.
Back to top

I will have sgfxi check for single user mode maybe and toss out an error, it's not meant to support that, the behaviors and paths are too unpredictable...or... I can have it set a full $PATH.. yes, that will work, this wasn't a bug, just you doing something nobody does, which is why nobody has reported a bug, it's not a bug, it's something I would never have thought anyone would even do, since generally in single user mode networking doesn't even work.

So I'll just set PATH explicitly at least in sgfxi on startup, we do that in inxi too, for the same reason.

The path /usr/local/bin is not generally avaiable by default in single user mode, that's all.
Back to top

Ok.
I have the habit to use single user mode when I know I'll have to reboot anyway instead of going to the desktop (like with an installation I have here which isn't the one I use regularly). Debian doesn't have level 3 and in single user mode I login as root directly.
Just saying.
Back to top

I've had a problem with smxi for some time. If I take the kernel removal option, I enter a loop where the option to remove old kernel sources or not keeps returning, whichever option (1 or 2) I take. The only way out seems to be Ctrl-C and reboot -n.
Is there a fault in smxi, or is there something I need to do?
Back to top

post the url for a pastebin of your /var/log/smxi.log

there is no issue in the current smxi cleanup tool that I can reproduce, it works fine as expected.

I have heard this issue reported off and on, but I can see nothing that would make it happen in the code, usually that kind of looping is absolute, ie, it always happens because I made a typo in the option name string.

CLEAN UP OPTIONS :: Module Version: 2.10.11 :: Last Updated: October 18 2010

make sure your smxi shows that, you can vefify this in terminal, in x, as root: smxi -G

G is for 'gui mode', the features of smxi you can safely run in X, that is, that's a new option.

then go to the cleanup section and make sure you have the right library file number, but that should update always so failure to do so would be very very strange.

I did find a nice feature I'd forgotten about, selecting the option I usually don't select, remove kernel only, and loop through the other non installed kernel download directories and decide one by one whether to remove them or not. That can present the illusion of a loop, I thought it was at first, but it was correct, I just had some kernels I'd forgotten to cleanup the download directories of, and smxi correctly looped through them and asked me if I wanted to keep or dump them.

Again, usually failure to exit a loop is caused by a bad syntax/typo, that is absolute. Failure to update the lib cleanup file would be some corruption somewhere.
Back to top

<cleaned up smxi.log, in future please post a URL to the pasted file, otherwise the stuff gets too clogged up here with useless data>
Back to top

I tried smxi -G and it worked fine. I still had one spare kernel on board and it removed the kernel and source without any problem.
If nobody else has my problem, don't worry. I'll do another smxi run (without the -G) in a few days, upgrade my kernel and try removing the old one. If I have the same problem, I'll let you know.
I like the look of smxi -G and it's a good trick to have up my sleeve.
Thanks.
Back to top

paleoflatus, I've seen this before, I think there was one kernel string somewhere that for some reason triggers a bug or issue in smxi, but I've never been able to find it, the only way to detect it is if you paste your log file from the actual session of smxi that contains that loop, which would have been logged.

There are more logs, check the .0 and .1 log for that loop, maybe I can one day figure out that bug, but it's I think related to a kernel bug maybe, where the kernel uninstaller itself, the one in the kernel package, had a bug in it, that's all I can guess, because smxi itself just follows what is present in your system, so if a kernel image doesn't get fully removed, but lingers, then smxi would show a loop not because it's wrong but because something in the apt removal didn't complete the removal, that's my guess anyway.
Back to top

hi

pls ignore if not a true bug

date for me is 21 November

and smxi info is #### version: 8.12.19
#### Date: November 8 2010

1) In the upgrade section there is a warning to accept the maintainer's version of grub2.

but grub2 was updated but I never got a dpkg-reconfigure style dialog box asking me what I wanted to do .....like keep current version or accept maintainter's

any clues?

2) I have booted up ....so not a big deal.

regards
Back to top

if you do not see that message it means simply that your local grub config file was not altered, if it's not altered from default, then nothing is noted since no change that will affect the system has taken place.

In general the core config files should not be altered, because if they are not altered, you will not see this message. This was the idea behind those .d/ sub files for configs, the main ones are altered, but user customized ones in .d/ directories override them.

However, the bug in this case is that that message is very old.
Back to top