FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 09-15-2012, 09:40 AM
Dmitriy Matrosov
 
Default Grub2 with multiple Debians

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 50544D00.6040402@gmail.com">http://lists.debian.org/50544D00.6040402@gmail.com
 
Old 09-15-2012, 10:39 AM
Andrei POPESCU
 
Default Grub2 with multiple Debians

On Sb, 15 sep 12, 13:40:16, Dmitriy Matrosov wrote:
>
> Note, that suggested above approach requires one edited by hand grub,cfg
> along with automatically generated others.

I've solved this by having one grub in the MBR and installing each grub
in the corresponding first sector of the partition. Not recommended by
grub, but it works.

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 09-15-2012, 02:23 PM
lee
 
Default Grub2 with multiple Debians

Hendrik Boom <hendrik@topoi.pooq.com> writes:

> On Fri, 14 Sep 2012 23:06:42 +0200, lee wrote:
>
>> Hendrik Boom <hendrik@topoi.pooq.com> writes:
>>
>>> 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!)
>>
>> Are you referring to grub figuring it out when booting or to grub
>> figuring it out while it's being installed? (In any case, I don't know
>> any of the answers ...)
>
> Presumably while installing grub. WHile booting, grub2 has precious few
> decisions to make -- it's pretty well all scripted from the configuration
> file.

It will have to figure out somehow which config to use. I don't know
how it does that and assume that this information is stored when it's
installed in the MBR. When you copy Linux version A to version A1 and
upgrade version A to version B and version B goes wrong, wouldn't grub
still look at it's configuration (its /boot directory) which is part of
version B rather than at its configuration in A1? In such a case, I
think you really want grub to look at A1.

Can't we have a boot manager which is independent of the installed OSs?
Grub kinda does its own thing already, and if there was something like a
standardised API through which OSs could tell the boot manager how they
are to be booted, we would install the boot manager as the first thing
and only once. Then we could install as many OSs (or at least Linux
versions that comply with the standard) as we like, each of them telling
the boot manager how to boot them. You wouldn't have the problem you
have now anymore.

Doing it the other way round as we do now kinda doesn't make any sense
at all.


What if you install a tiny minimal Linux version only to get grub
installed and exclusively use that version of grub for booting? The
Debian installer and the package management would have to be fine
without installing or updating grub, and you would have to boot into
your minimal version to update grub from there. Is that possible?


--
Debian testing amd64


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d31nl60c.fsf@yun.yagibdah.de">http://lists.debian.org/87d31nl60c.fsf@yun.yagibdah.de
 
Old 09-15-2012, 06:52 PM
Hendrik Boom
 
Default Grub2 with multiple Debians

On Sat, 15 Sep 2012 13:40:16 +0400, Dmitriy Matrosov wrote:

> 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.

You'd think that os-prober could use the entries in /etc/fstab to
identify the /boot that goes with a particular root partition.

(That assumes, or course, that /etc is in the root partition and not
separately mounted. But if it was separately mounted, there would be no
way for it to read /etc/fstab in order to find out what to mount for /
etc.)

-- hendrik


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/k32ipb$q76$1@ger.gmane.org
 
Old 09-15-2012, 06:55 PM
Hendrik Boom
 
Default Grub2 with multiple Debians

On Sat, 15 Sep 2012 02:19:11 +0000, Hendrik Boom wrote:

> On Fri, 14 Sep 2012 22:37:28 +0100, Joe wrote:
>
>> On Fri, 14 Sep 2012 20:42:21 +0000 (UTC)
>> Hendrik Boom <hendrik@topoi.pooq.com> 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.
>>>
>>>
>> The problem is that update-grub rewrites /boot/grub/grub.cfg. It may be
>> possible to specify roots and boots in /etc/grub.d/ (I do use a
>> separate /boot, but I've never needed to try this) or alternatively it
>> is perfectly possible to edit grub.cfg, but you need to remember to do
>> so each time update-grub is run, before rebooting. More than once, I've
>> known versions of grub not deal correctly with a separate /boot, so
>> I've had to do this until the bug was fixed.
>
> It might be that bug that fouled up my laptop. Or I might have done it
> myself at some point. Anyway, I've become paranoid about such things.
> If the bug has been fixed, well, that'll be one less thing to go wrong
> when I upgrade.
>
> Thanks for telling me that there was a bug, and that it was fixed.

What was the actual bug, by the way -- failure to read /etc/fstab
properly, which should make it clear which /boot to use?

-- hendrik


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/k32iur$q76$2@ger.gmane.org
 
Old 09-15-2012, 07:02 PM
Dmitriy Matrosov
 
Default Grub2 with multiple Debians

On 09/15/12 18:23, lee wrote:


Can't we have a boot manager which is independent of the installed OSs?
Grub kinda does its own thing already, and if there was something like a
standardised API through which OSs could tell the boot manager how they
are to be booted, we would install the boot manager as the first thing
and only once. Then we could install as many OSs (or at least Linux
versions that comply with the standard) as we like, each of them telling
the boot manager how to boot them. You wouldn't have the problem you
have now anymore.

All of this can be implemented with grub (grub2 at least). And one of the
approaches, is to have (main) grub config, which loads OS-specific ones. The
main grub config should only know where to find OS-specific ones and should
_not_ be updated by update-grub from any OS. The os-specific ones, on the
other hand, should be updated by update-grub from corresponding OS. The
main config must be updated either manually, or by some other method (using
standardized API, as you said). Anyway, this is exactly what described in
article i mention earlier. And may be it's a bit complicated, but it works.


What if you install a tiny minimal Linux version only to get grub
installed and exclusively use that version of grub for booting? The
Debian installer and the package management would have to be fine
without installing or updating grub, and you would have to boot into
your minimal version to update grub from there. Is that possible?



Grub from this minimal linux should somehow figure out which OS root
corresponds to which kernel, or where to find /boot corresponding to some
OS. Default grub2 scripts can't do this (at the time, when i have checked).


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 5054D0BF.7070406@gmail.com">http://lists.debian.org/5054D0BF.7070406@gmail.com
 
Old 09-15-2012, 07:03 PM
Hendrik Boom
 
Default Grub2 with multiple Debians

On Sat, 15 Sep 2012 13:39:29 +0300, Andrei POPESCU wrote:

> On Sb, 15 sep 12, 13:40:16, Dmitriy Matrosov wrote:
>>
>> Note, that suggested above approach requires one edited by hand
>> grub,cfg along with automatically generated others.
>
> I've solved this by having one grub in the MBR and installing each grub
> in the corresponding first sector of the partition. Not recommended by
> grub, but it works.

So each system-specific grub would. presumably, boot just that system.
And what would the MBR grub do? Chainload a boot-time choice the others?

And how would these be protected against the script that updates the grub
configuration when the package-manager installs a new kernel during a
routine upgrade?

>
> Kind regards,
> Andrei

-- hendrik


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/k32je0$q76$3@ger.gmane.org
 
Old 09-15-2012, 07:17 PM
Dmitriy Matrosov
 
Default Grub2 with multiple Debians

On 09/15/12 22:52, Hendrik Boom wrote:

On Sat, 15 Sep 2012 13:40:16 +0400, Dmitriy Matrosov wrote:


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.


You'd think that os-prober could use the entries in /etc/fstab to
identify the /boot that goes with a particular root partition.


May be this will work. May be not. But there will be many problems with
this, and rewriting os-prober (instead just some or several configs) is not
the last of them (i mean, you will have problems during grub update if your
patches have not yet accepted upstream). And if you want my opinion, i don't
think this will work. First, there is no guarantee, that corresponding /boot
will be mentioned in fstab. Second, /boot may be common for all
distributions,

and the problem will be to identify correct kernel. And, third, you should
not just figure out correct kernel for current OS, but for all others as
well.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 5054D45F.1080302@gmail.com">http://lists.debian.org/5054D45F.1080302@gmail.com
 
Old 09-15-2012, 08:09 PM
Hendrik Boom
 
Default Grub2 with multiple Debians

On Sat, 15 Sep 2012 02:19:11 +0000, Hendrik Boom wrote:

> On Fri, 14 Sep 2012 22:37:28 +0100, Joe wrote:
>
>> On Fri, 14 Sep 2012 20:42:21 +0000 (UTC)
>> Hendrik Boom <hendrik@topoi.pooq.com> 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.
>>>
>>>
>> The problem is that update-grub rewrites /boot/grub/grub.cfg. It may be
>> possible to specify roots and boots in /etc/grub.d/ (I do use a
>> separate /boot, but I've never needed to try this) or alternatively it
>> is perfectly possible to edit grub.cfg, but you need to remember to do
>> so each time update-grub is run, before rebooting. More than once, I've
>> known versions of grub not deal correctly with a separate /boot, so
>> I've had to do this until the bug was fixed.
>
> It might be that bug that fouled up my laptop. Or I might have done it
> myself at some point. Anyway, I've become paranoid about such things.
> If the bug has been fixed, well, that'll be one less thing to go wrong
> when I upgrade.
>
> Thanks for telling me that there was a bug, and that it was fixed.

Actually, it seems it may be bug #612407 -- the symptoms are almost
exactly what happened on my laptop, with the exception that I had the
problem with sqeeze/wheezy instead of lenny/squeeze: http://
bugs.debian.org/cgi-bin/bugreport.cgi?bug=612407

If they've fixed the bug as you say, this is presumably another one,
unless they've fixed it but failed to mark it as fixed.

In any case, this tells me that I should go ahead with my upgrade plans,
but should watch any automatically updated grub configuration files like
a hawk, diffing them against previous versions, and the like.

Also, looking around the grub buglog, it looks as if booting several
different / partitions from one /boot partition is perfectly legal. But
I don't know if the Debian package manager is cool with that -- one
partition being upgraded independently by two package managers? It seems
they might disagree about when files need to be removed.

It's copnceivable that I made a mistake on my laptop with /etc/fstab and
inadvertently did specify the same /boot for the different systems. Or
that it happened during the automatic upgrade of /fstabs from /dev/sd*
notation to UUID notation. But the number of comments I've seen about os-
prober getting things wrong makes me suspect that the trouble could arise
even without a faulty /etc/fstab. I just don't know any more. What was
it the Defence Against the Dark Arts master kept saying all the time?
Something like "Extreme Vigilance"? At least I know what to beware of
now.

-- hendrik


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/k32na0$q76$4@ger.gmane.org
 
Old 09-15-2012, 08:14 PM
Hendrik Boom
 
Default Grub2 with multiple Debians

On Fri, 14 Sep 2012 23:25:03 +0300, Andrei POPESCU wrote:

> UUIDs? What failure mode(s) do you have in mind, because I can't think
> of any.

When looking at /etc/fstab or grub configuration files:

Alas! UUIDs are so unmnemonic!

-- hendrik



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/k32nj4$q76$5@ger.gmane.org
 

Thread Tools




All times are GMT. The time now is 10:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org