This can similarly be wiped out by updates but as it's in /etc/ you should (I think) get a prompt to keep your existing configuration when an update does hit.
As people in the bug go on to say, this still isn't ideal as there's every possibility that somebody might want to run both burg and grub or at the very least keep the two synced.
You could go one further and write a new script like this:
#!/bin/sh
set -e
exec update-grub "$@"
exec update-burg "$@"
Save it as /usr/sbin/update-bootloaders, chmod +x it, and then stick update-bootloaders in /etc/kernel-img.conf in place of update-grub or update-burg.
I guess in the long term, an alternatives system needs to be set up for various bootloaders as exists for java, audio and other interchangeable subsystems.
Normally update-grub gets called. This is just something that happens. The system expects grub to be the bootloader. Assuming you're never going to use grub again, you can do this:
This moves update-grub out the way and creates a symlink in its place that actually runs update-burg. So when a new kernel installs, it'll call update-grub which is actually update-burg.
Hacky but it should work.
To reverse:
cd /usr/sbin/
sudo rm update-grub # this is only a symlink
sudo mv update-grub.backup update-grub
If you have the habit of doing sudo apt-get upgrade to update your packages and kernels, the following script will solve your problem and is 100% resilient to updates:
#!/bin/bash
# Check what kernels are installed.
KERLST=`ls /boot | grep vmlinu`
# Do updates.
sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get -y dist-upgrade
# Update burg if kernels changed.
if [ "$KERLST" != "`ls /boot | grep vmlinu`" ]; then
sudo update-burg
fi
Save is as a text file apgrade.sh and mark it as executable. This script will perform every possible update, check whether the kernel list has changed, and update burg in case it did. I've been using it since 10.04 (bound to an alias), and no updates have broken it so far.
If, however, you like doing your updates manually through synaptic, then Oli's method might be better.
I created a script based on the most-helpful/best-rated information provided here. One subtle change is that the boot-loader executables are no longer exec'd (as in the case of grub it exits; thus the script exits and other loaders are not executed (@Ubuntu11)).
The script can be configured for multiple bootloaders.. (if the executable is update-name and in /usr/sbin;-).
It could be extended to allow update executables that are not update-name. To do this maybe use name:exec as values in the boot-loaders config variable and split the var then change the execution command accordingly (would probably need to use a different language for this to be elegant).
#!/bin/sh
# #################################################################
#
# Updates (multiple) bootloaders after kernel update.
#
# @shell bash
# @see http://askubuntu.com/questions/4905/how-to-automatically-update-burg-after-a-kernel-update
#
# #################################################################
#
# Install:
#
# -----------------------------------------------------------------
# * Save as: /usr/sbin/update-bootloaders
# * Then: chmod +x /usr/sbin/update-bootloaders
# * Edit /etc/kernel-img.conf and append/replace the following parameters:
# ** postinst_hook = update-bootloaders
# ** postrm_hook = update-bootloaders
#
# #################################################################
#
# Configuration:
#
# -----------------------------------------------------------------
# BOOTLOADERS: configuration variable to list bootloaders
BOOTLOADERS="grub burg"
#
# #################################################################
set -e
for BOOTLOADER in ${BOOTLOADERS}; do
EXEC="/usr/sbin/update-${BOOTLOADER}"
if [ -x ${EXEC} ]; then
echo "Updating ${BOOTLOADER}..."
${EXEC} "$@"
fi
done
# eof
Another method for you is to edit
/etc/kernel-img.conf
From: https://bugs.launchpad.net/burg/+bug/594431 (a bug report echos your experience)
This can similarly be wiped out by updates but as it's in
/etc/
you should (I think) get a prompt to keep your existing configuration when an update does hit.As people in the bug go on to say, this still isn't ideal as there's every possibility that somebody might want to run both burg and grub or at the very least keep the two synced.
You could go one further and write a new script like this:
Save it as
/usr/sbin/update-bootloaders
,chmod +x
it, and then stickupdate-bootloaders
in/etc/kernel-img.conf
in place ofupdate-grub
orupdate-burg
.I guess in the long term, an
alternatives
system needs to be set up for various bootloaders as exists for java, audio and other interchangeable subsystems.Normally
update-grub
gets called. This is just something that happens. The system expects grub to be the bootloader. Assuming you're never going to use grub again, you can do this:This moves
update-grub
out the way and creates a symlink in its place that actually runsupdate-burg
. So when a new kernel installs, it'll callupdate-grub
which is actuallyupdate-burg
.Hacky but it should work.
To reverse:
If you have the habit of doing
sudo apt-get upgrade
to update your packages and kernels, the following script will solve your problem and is 100% resilient to updates:Save is as a text file apgrade.sh and mark it as executable. This script will perform every possible update, check whether the kernel list has changed, and update burg in case it did. I've been using it since 10.04 (bound to an alias), and no updates have broken it so far.
If, however, you like doing your updates manually through synaptic, then Oli's method might be better.
Thanks!
I created a script based on the most-helpful/best-rated information provided here. One subtle change is that the boot-loader executables are no longer exec'd (as in the case of grub it exits; thus the script exits and other loaders are not executed (@Ubuntu11)).
The script can be configured for multiple bootloaders.. (if the executable is
update-name
and in/usr/sbin
;-).It could be extended to allow update executables that are not
update-name
. To do this maybe usename:exec
as values in the boot-loaders config variable and split the var then change the execution command accordingly (would probably need to use a different language for this to be elegant).