When you say a manual kernel install, are you talking thru smxi or some other way?
Back to top

metpackages install kernels automatically, manual means you have removed the metapackages and use smxi to install the kernels by your decision, manually that is.

hoodwink, I also forgot to ask you to post a link, use paste.debian.net to your /var/log/smxi.log and /var/log/sgfxi/sgfxi.log files from the failed install.

The logs let me see what's happening internally, otherwise it's too hard to guess.

Note that the logs get rotated automatically to 0,1,2... in the file name, so you might have to look one or two logs back.

Most important to see is what smxi generated internally versus what sgfxi received as an argument for the install, so I need to see both the smxi log from that time and the corresponding sgfxi log.
Back to top

I never had a clue and still don't. Why would I want that (or not), and how did I get it?

Is the metapackage remover you referred to one of the options somewhere in smxi?
Back to top

metapackages are the default for sidux now. That's why the first thing smxi asks you when you run it and it finds metapackages is if you want to remove them.

Yes, the option to remove is in smxi, I think it's in kernel advanced options.

Again, post links to the smxi and sgfxi logs and I can maybe figure it out, don't post them and I definitely will never figure out what's going on.

Sounds like something is maybe getting half set internally, but I need to see what the smxi/sgfxi logs say about that.

Please find the requested logs and post links to them on paste.debian.net that usually saves me about 10x the time than trying to figure it out like this, guessing etc, I should have asked for that right away, but i'm still not used to the smxi/sgfxi stuff having full logging so I forget.

personally I see no use for metapackages for most people, especially if you use smxi, it's just a way to handle making people do kernel updates automatically who don't track the stuff I guess, or something, but I use smxi to let me know, then I chose when and if to install a new kernel. I probably install at most 1/10 of the kernels sidux releases, if that.
Back to top

Ok. it's posted on your debian.de link.

Some more questions, and perhaps you should consider some more explanatory text for smxi, since there must be others as dumb as I.

1. WTF is kernel metapackages?
2. Why would I want it or not?
3. How does this affect sidux as opposed to any of the other debian choices?
4. How will my system be affected if I have it now and if I turn it off.
Back to top

I guess it's because I have installed smxi so many times on so many computers that I have memorized the opening dialogs and options for everything. My point is that it's all there. There is also documentation on this site for smxi operations although I've never actually read it all. Of course once you've set it up there's the problem of changing things with smxi dash this or that:ie: 'smxi -M' for the mirrors. You could always sneak a look at the smxi script too!
Back to top

hoodwink, you have to upload the relevant file to the paste site, then click the submit button, then you get a link to paste to.

Then you have to post that link here, otherwise it's not possible to find.

Kernel metapackages are just that, metapackages that call in new kernels and kernel parts whenever the kernels update.

This is what triggers the errors you see on your system.

If you should ever decide that you want to reinstall them, I think smxi might even have a reinstall option for those, though I never use it, but I seem to remember it's there.

Had you answered 'remove metapackages' many months ago, you would never have had this issue. But if it's a bug, we'd never learn about here either, heh...

A metapackage in debian is simply a package that lists a bunch of packages to install, or a new version. Removing it simply gets rid of that single package, nothing else, and since it's meta, it's not an actual binary package of files, it's just a set of instructions of what to install or update. Not at all exciting.
Back to top

I found the paste, from what I can see, you had already installed the kernel in question during that session I assume, it was in grub, when you installed it again for some reason.

This made the test for one thing get confused, but I don't see any issues that look that odd.

I still think you have something wrong with your system to be honest hoodwink, your assumption that it's all fine doesn't quite fit with what I'm seeing your system do off and on, which does not look fine to me.

However, there's also a chance here that you're simply installing the kernel after the metapackages, if present, had installed it, I really can't say, this problem appears to be unique to your system.

If it happens again, make sure to post the full link to the paste of /var/log/smxi.log as soon as it happens, copy it before you do anything else so i can see what the session did that seemed to fail.
Back to top

Just to make this clear, when I do a full upgrade, including a new kernel with nvidia drivers, this is what the steps are:

1. start smxi
2. see the system info part
3. see the latest kernel install option, install apt kernel
4. install the kernel
5. at end, see note about reinstalling nvidia
6. continue on
7. upgrade step
8. post upgrade, whatever
9. graphics install, directly to new kernel, not yet booted into.
10. start sgfxi, install nvidia, offers to reboot, I reboot.
11. starts to new kernel with new driver.

This has never failed for me on any test system I run it on. the nvidia driver installs to the new kernel, I reboot, and that's that.

If something other is happening, then there is something wrong but I can't say what it is.
Back to top

On my system smxi runs differently - don't know why.

1. start smxi (remote version reloads if changed)
2. aptitude update
3. option to d-u, or skip
4. aptiutude d-u installs many packages including kernel + modules if available.
5. As per your description for the remaining steps, and the nvidia relink now usually fails.

The steps you list are how things used to work on my system. I don't know what caused the changes. How do I get back to the desired behavior?

The only thing I've done in months (other than updates every 1-2 weeks) is to add aptitude to the smxi.conf.
Back to top