On 09/15/12 00:42, Hendrik Boom wrote:
On Fri, 14 Sep 2012 23:25:03 +0300, Andrei POPESCU wrote:
On Vi, 14 sep 12, 17:12:38, Hendrik Boom wrote:
Of course, after I've made my copy (with slight changes to /etc/fstab)
I have two nearly identical sets of partitions, so it may be tricky to
tell them apart. Is grub2 clever enough to figure it all out anyway?
And what data does it use to this end? (so I can make sure it's right!)
UUIDs? What failure mode(s) do you have in mind, because I can't think
of any.
It probably is os-prober that I mean. The misconfiguration I have in
mind is matching one system's /boot with another systems's /. I've had
it happen on a laptop sometime ago. and it sure messed up my upgrades. I
have no idea how it happened, but it has made me paranoid.
-- hendrik
Hi.
Useless entries in grub.cfg (with non-matched kernel and root, e.g.
kernel from stable and root from testing) or probably even no correct
one - is normal for 30_os-prober and 10_linux scripts. I don't think,
that there is a simply way to fix them.
Though, here is quote from [1] about making grub2 able to boot two OSes
without useless entries:
__QUOTE__
I'll use following terms:
- grubdir is directory, where all grub modules and other stuff have
installed by grub-install. It is usually /boot/grub, but may be set to
'DIR/grub' using '--boot-directory DIR' option of grub-install.
Here suggested two schemes for booting several Linux systems with grub2. They
are designed to satisfy following requirments:
- update-grub should work in all Linux systems and does not break
anything.
- No incorrect and useless menuentries, which often generated by
/etc/grub.d/30_os-prober script.
- New linux system should not ruin boot, if update-grub will accidently
run on it with default config.
- OS kernel and initrd should be stored on corresponding OS root
partition. This is OS-dependent data and i don't want to store it in
shared location (like shared boot partition). Also, if OS will be moved
to some other computer, kernel and initrd will still be there.
Generally, there is two approaches to this problem:
- One main config (grub.cfg), which have created and updated by hand (or
some other method, but not by update-grub), and many OS-specific
configs, which have generated and updated by update-grub from
corresponding OS. Main config should find and load OS-specific ones.
- One merged config. Merge should occur during generation or update by
update-grub from any OS.
Because each OS may run update-grub, second approach requires each OS to have
specific merge script in the /etc/grub.d, and if it is not there (for newly
installed OS), update-grub will overwrite grub.cfg making all other systems
unbootable. Hence, i'm not considering second approach further, and choosing
first one.
Main grub config should be stored on the shared boot partition, but
OS-specific ones may be stored on either shared boot partititon as well or on
OS root partition. I can't definitely say, that OS-specific grub config
belongs to OS or to grub. On the one hand, OS-specific config is generated
using OS-specific scripts from /etc/grub.d, and, hence, belongs to OS. But, on
the other hand, grub-mkconfig and scripts from /etc/grub.d may read files from
grubdir and make some choices depending on their content (and they actually
will), hence, OS-specific config depends on particular grub installation and
belongs to grub. In other words, OS-specific grub.cfg depends on both OS
configuration and bootloader features available.
__END_QUOTE__
Note, that suggested above approach requires one edited by hand grub,cfg
along with automatically generated others.
[1]: http://sgf-dma.blogspot.com/2012/07/multiboot-with-grub-2.html
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50544d00.6040...@gmail.com
