Thanks techAdmin... I used chainloading in the original grub and am familiar with it.

The method I use may be seen as more of a pain, but having and maintaining a master grub is and has been working for me for a couple of years... All that it costs me is to login to /sda5 ( where the original sudo grub-install /dev/sda was run from) and from there do a grub-update where it picks up the new kernel and restart.

To reiterate, every thing works perfectly except one debian kernel (and only this one kernel), which installed perfectly from smxi.

Last night and today I have installed 3 new distros using the same grub and everyone of them worked..

This is not a smxi issue as I first thought it could have been. It is an issue within that kernel not correctly installing or not having what grub needs to see it.

If and when I see a change to it, I will report back the fix.

Please do not let me or this consume any more of your time...

Thanks for everything
Back to top

A newer Debian kernel 3.2.0-3-amd64 was available via smxi today. I installed it and grub found it instantly ...

Whatever was the previous Debian kernel was the issue.

aus9 said this a while back and I think was dead on..



I am just glad it is over...

Thanks everyone for the comments.
Back to top

vastone, I feel your pain, I've also been having to track down some painful issues, unrelated, in a few different areas, today I finally resolved one, which is a big deal since it's a major money thing for a client.

While unable to resolve a second, I do now know the cause, and that it cannot be fixed, which is something.

So it was an actual debian packaging bug, I see. Want to bet it failed in the post installer script to consider grub being on partition root? Or whatever?

Good to hear the issue was the actual debian kernel and that it's fixed now, these things drive me up the wall until I actually understand what's happening and why.
Back to top