DebianThis forum is for the discussion of Debian Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I'm having this following problem, while setting up a machine that will be administered remotely. The basic requirement is to have a stable minimal complete fallback system that gives me ssh access, no matter what.
So far I've installed 3.1 stable (sarge) with X11 and KDE for the full installation and a minimal sarge installation on a different partition. So far so good, both work as designed.
What I'm now trying to do is to have grub fallback to the minimal installation, and here lies the problem. In another distribution, I'd have used the 'fallback' mechanism of grub to always boot the minimal installation, even if by mistake I screw up the full system. Not so in Debian, I believe, since the 'update-grub' script automagically creates new kernel entries after each patch, so I'm worried my hand-crafted grub menu.lst will be overwritten. I don't want to hack the script (don't know enough about Debian yet).
What are my options? Is there a standard solution for a bullet-proof fallback system that only offers remote access?
My last option is to create a grub floppy and use that to boot the minimal install, but I'd rather not do that.
Thx m_yates, that's quite useful. One followup question, if I may.
If I pin the kernel, I suspect that any security updates won't be applied when apt-get upgrading. Am I correct? If so, how do I update the kernel without grub configuration being overwritten, manually with apt-get?
Well, it's just removing a post-inst script after all
update-grub will not be launched...
To be honest, I've not yet tried it but the line is empty now because I don't like what update-grub is doing everytime and I wan't to control it for my next install
When is it updated?
It is part of kernel-package so everytime this will be updated and you ask to take the file of the maintainer then this file will be overwritten to its default content.. you can restrict to never install update of this package or ask to keep this file intact
You can do a lot of things with this entry, have a look at /usr/share/doc/kernel-package/examples
As far as I know update-grub only affects a small part of the menu.lst file. I can safly install new kernels and run update-grub without affecting my personal changes to the file (WinXP was added during install, and I set it as default boot system)
If I remember correct (I'm not at home now so I can't check) menu.lst contains lines that are something like
#Start of Debian generated menu
#end of Debian generated menu
It's not exactly that but something in that direction.
If you add/remove/edit thing that are not between those lines, nothing will be changed when running update-grub
title Debian GNU/Linux, kernel latest
kernel /boot/vmlinuz-last root=/dev/hda3 ro
### BEGIN AUTOMAGIC KERNELS LIST
blablah generated by update-grub
### END DEBIAN AUTOMAGIC KERNELS LIST
Then the vmlinuz-last would never been touched, and with default set to 0 , you would always boot on vmlinuz-last ( which could be linked to the last vmlinuz , done in a script in kernel-img.conf)
But for my machine, it still puts a lot of useless things between ###BEGIN ###END
Like recovery blocks (as I have 5 different kernels, it makes me 10 lines!) I don't need this recovery ones, if something goes wrong , I edit the line and boot . For this problem I maybe have to configure something in menu.lst but have not really searched..
Also in my previous example, it would still add /boot/vmlinuz-last between the ### marks, the result is I have 2 identical blocks.
At least, it should look for the user-defined blocks and not regenerate a block for the same kernel..