Hi again, it is in a path and I run it as root, I don't utilise sudo:


Regular user has /usr/local/bin in PATH too, but I don't think that would be an issue, because I run smxi as root.

After install I ran smxi and now I invoke smxi as smxi -G, like you recommend.

Wget failure won't be a case, I guess, either, because script did successfully download kernel zip. Internet is fine and working.

This is whole run, when I try reinstall already downloaded kernel:
next post...

< Edited by osp :: Dec 14, 13, 11:10 >
Back to top

This is link to pastebin:
pastebin.com/cYkrLk6v
Back to top

there's a problem somewhere in your system I believe, though I can't be sure.

The script is trying to source/include the file and it does not exist in the directory smxi is in, or should be in.

If it does exist, ie, in /usr/local/bin then I cannot explain it.

I did fix one bug, smxi should not have been creating backup copies grub 2 /boot/grub/grub.cfg files since those are dynamically generated by grub, so it won't do that anymore, but that's not related to your issue.

The only way I can track this down on your specific system is to add more logging to confirm where smxi thinks it is on your system.
Back to top

Ok, so what can I do for you now? You'll post modified version?

If that helps, my distribution is CrunchBang 11 Waldorf, which is debian wheezy.

All scripts are in /usr/local/bin:

Back to top

I honestly can't tell you, 100s of people do this every week, and have for years, many years, and this is the first ever case like you describe.

As you can see from the ls /usr/local/bin, all the files are present.

And as I can see from your pastes above, smxi correctly included sm-lib-kernel and sm-lib-kernel-install before trying to include sm-lib-misc-tweaks, so there is no reason for that last include to have failed.

Your /boot is almost full (should make /boot much larger to avoid having to worry about it), but it looks like there's enough room left for one more kernel there so that should not have caused issues.

I don't know why the staff group owns /usr/local/bin, that's unusual.

But that should not matter because by the time smxi gets to that place, it's already included 4 files, or 3, can't remember, so there's no reason for the 4th to make it suddenly fail, all the paths are the same, the way it gets the files is the same, nothing changes.

I think I'm going to leave this as a mystery, if hundreds of people didn't use this every week I'd look into it more, but I have to assume there's something totally specific to your system that neither you nor I know that is causing the failure, so I doubt I will be able to help you figure it out.

Smxi is used by Crunchbang people a fair amount I believe, so I suggest you post on their forums and see if anyone else has had this problem, maybe with a few more user data sets something will appear to explain your failure, but I don't believe I will be able to solve it for you, unless there is something incredibly obvious I've missed, but as I noted, smxi has already by the time it hits that misc-tweaks include already included files several times immediately before doing so.

What has changed? Hard to say, your /root disk is not full, /boot being full, even if it happens, should not prevent bash from including another small text file in / so there's not a lot else I can say.

I'll add one line of logging to the actual include point just to confirm that smxi is where it expects to be, but again, any failure like that would have shown up many years ago so I don't think that's an issue.
Back to top

i took a closer look and realized it is possible that in one single case smxi would think it was in the wrong place to source a file at that step, so I added some protection in, but I have no idea how this could not have been reported for this long since that would have been a first run bug that should do what it did to you every time.

However, rather than take a chance, I just added in more explicit paths, so we'll see if that fixes it.
Back to top