I always use liquorix kernels and have never seen anything like this.

I successfully installed the debian kernel via smxi. It updated fine, and I installed the nVida driver to the kernel. Rebooted and there was no debian kernel in grub2

Booted back and ran smxi again, this time making Debian the main kernel for smxi.

reload of smxi and it does not see the previously installed debian kernel, so I successfully re installed it and the nvida drivers also.

Rebooted again still no debian kernel in grub2. Started smxi and it did not see the debian kernel it had just installed so I successfully installed it again, but still nothing in grub2...

This is just a little bit strange and unusual to me... Help!

Will send anything you need.

Thanks
Back to top

that's an old problem, usually caused by incorrect grub installation, which means, usually, that the grub that is actually booting your system is not the grub that is getting the new kernel information.

If it 's not that, it means maybe that your grub 2 configuration is off. For example, turned off updating feature, could be a bunch of things.

See our grub forums for specific grub information and help.

In my experience new kernels getting installed and not showing up on grub is almost always a grub installation error.
Back to top

Interesting that on the same system any liquorix kernel installs and grub works fine for it but not a debian kernel?

It is not a grub issue.
Back to top

hi

if you have the time try this

BTW I use liquorix kernels as well ;)

download a debian kernel and a liquorix kernel manually install them by



I suspect the post install messages you will see for liquorix will show grub2 being updating but no post messages for what ever version of that debian kernel you have.

b) I suspect its a minor gremlin because I have used deb kernels in the past and I am sure the debian builders normally have a post install script inside the deb file

I am suggesting it is likely an oversight for one debian kernel and not all.
Back to top

aus9 - Thanks for that... That is most likely the scenario, I us e the same grub as a master for 4 different distros and none wih any issues like this one.

Later, I will be installing a distro with a debian kernel on another partition and will use the same grub and should update normally, from that one I will use smxi and use debian as my only kernel source and see what happens from there.

I appreciate it...

@techAdmin - I did not mean to come across that rudely, I had not had my coffee yet, that is no excuse... please accept my apologies.
Back to top

vastone, I'd misread your posting and thought all kernels were not showing, sometimes I skim stuff too fast, so no worries.

All I can say is you don't want to see me before my first AM caffeine.
Back to top

Thanks @techAdmin for understanding..

Confirmed that it is an issue specifically with the latest Debian kernel. I just did a biz card Debian install with an iso from a month ago that has 3.2.0-2.amd64 as the latest kernel... It showed up fine on the same grub2 master.

I chose this iso because interestingly enough, there are currently issues with the latest iso of biz card and netinstall that are having issues with finding the /target/ for grub install and are failing the entire install.

Not sure if it is related, and certainly nothing to do with smxi...

Noting it for information purposes only.

I will install smxi to this install and use debian only and try to bring it to the latest kernel and of course report back
Back to top

well now I'm confused anyway.

If you installed the debian kernel, that should act like any other kernel, so I'm going to return to what I said, either grub is misconfigured and is not updating, but that is not likely if you also dont' see the debian kernel listed, or grub was not installed where you thought it was in this case.

Sounds to me like a misconfigured something, maybe a /boot is done wrong, I can't say.

you're not using /dev/sdxy in /etc/fstab are you?

So many ways this can slip up.

Now if liquorix works and shows up on grub, ignore what I said, but that I find not very likely, I've never seen one kernel work and another not work.

You can see which kernels smxi sees by going to the post du cleanup section, kernel remover, and see which ones it lists for removal after installing a kernel, if you don't see the kernel you just installed listed before you reboot, then it didn't actually install anywhere that debian is aware of.

I've seen this type of issue many times, but have to scratch my head.

For my benefit, state the following categorically:

If you install the debian kernel it does not appear in grub and it does not seem to be seen by debian?

If you install a liquorix kernel, it does/does not appear in grub? and it does/does not have the nvidia driver on it when you reboot?

Do you have multiple kernels installed now, and you see them in grub, or do you have only one, the original one?

If any new kernel of any type appears in your grub, it's not a grub issue I believe. Nor would it be a /boot type partition error issue.

If no new kernel appears, that's the actual question then.



that old bug, I can't believe debian hasn't locked down this stuff after so many years, lol, these bugs just linger on and on, these were issues way back when, in 2006 I remember them, 2007.

I used to use old business card install disks for that same reason by the way, though the last ones I used worked ok.

Show: inxi -pluo

and paste in /etc/fstab

let's make sure that what you think is happening in your system is actually what IS happening.

so we can see what partitions you have on your system and stop speculating.

diagnosing grub 2 is a pain in the a#s
Back to top

Here is the output and some explanations.

sda3 is the MBA but not a /boot setup, it shows Boot Grub Drive just as a label. I distro hop and have several partitions setup for testing.

I setup Fedora, install grub to it's own partition on the install and not to the MBA

I setup #!, install grub to it's own partition on the install and not to the MBA

I setup aptosid, install grub to it's own partition on the install and not to the MBA

I setup a Debian Sid Netinstall, install grub to it's own partition on the install and not to the MBA

After each of these installs or any kernel updates, I then login to my main Debian install on /sda5 and run sudo update-grub.

On every one of those installs grub2 works flawlessly. It is only on /sda5 where I have installed the latest debian kernel does grub2 not detect ONLY that kernel.

As I stated, I just installed a new Netinstall to /sda7 and the MBA and grub2 found it and put it there and worked perfectly.


Back to top

If I understand this right, you should revise your methods, I've done a lot of heavy multiboot stuff for smxi/sgfxi testing, and you don't want to ever use the method you are using, what you want to do is chainloading, with one master grub to control them all, I use the most stable or main distro to run the master, and all others are chainloaded to their partition root installed grubs, which have nothing to do with the master grub at all.

You should never need to run update grub except when you add another distro onto the pile.

chainloading is always the best way, because that way you avoid the thing of needing to update grub every kernel update, a thing I learned early on when slh or kano would release new kernels every day or so.

You're right that there is almost certainly a bug in the debian business card installer with grub, for some reason, that logic has been horribly difficult for the debian installer guys to actually figure out, and the grub installer has always been particularly hostile to installing grub to partition root, not mbr, an attitude I find frankly tiresome from the debian grub guys, since it works totally fine to do that, and always has worked totally fine. And it's the only way to do real multiboot in the first place.

The grub forums here have examples.

If this is in fact what you are doing, then try to be utterly explicit in your wording. I find usually if one can't be explicit about the technical methods used, it's often because one is actually not clear on those methods.

Make sure to also paste in /etc/fstab from the debian bc install that is not updating the kernel stuff.

To be explicit: all secondary installs have their grub installed to their partition root. Those partition root grubs all update fine when you install a new kernel. Or not.

One master OS runs the master mbr installed grub, which has CHAINLOADER entries in it. Chainloading never happens automatically in grub, you have to do it yourself. If you have not set up chainloading, which I have to assume you have not since you have not used the term once in this thread, then you can stop, do not pass go, fix that, then proceed.

grub 2 made chainloading a royal pain in the butt, it used to be trivially easy to do in grub 1.

search these forums for chainloader and then look at the grub forum items.

Now, if' I'm still not understanding you right, I'm giving up, have to work etc, but this is the best I can offer.

In complex setups it's really best to list ALL the technical stuff first off, and to not assume that you have done it all right, especially if there is a possible installer bug also involved, you want to remove all the other possible issues so you can focus on the real one, otherwise things are too murky and take way too much of my / our time to figure out for you.

The first thing I do is turn OFF os_prober in grub, that thing is terrible, and makes for a totally unmanageable grub configuration section.
Back to top