All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: GRUB and the risk of block list corruption in extX
Date: Tue, 19 Feb 2013 09:02:10 +0400	[thread overview]
Message-ID: <CAA91j0XOtgcqiF2DHy9AT1tickwWLsqt2P3ayf8HSL7bxYJf8g@mail.gmail.com> (raw)
In-Reply-To: <E2C68865-294D-47A5-846A-0C7CBDFBA9E5@colorremedies.com>

On Tue, Feb 19, 2013 at 1:07 AM, Chris Murphy <lists@colorremedies.com> wrote:
>
> Chainloading was never a good idea, it was the only idea for supporting multiboot on hardware with a brain dead BIOS that was never designed with multiboot in mind.
>

Chainloading is actually the only sane way to do multiboot. While it
may have started due to BIOS limitations, today chainloading is simply
passing control to another bootloader.

If you want to have "master" bootloader that loads everything else,
you have to ensure that when "something else" changes, it is reflected
in master bootloader configuration. That's unrealistic. You do not go
and run os-prober in chroot on every other Linux you may have when you
install additional kernel.

I have test VM with Windows/Fedora/openSUSE. I installed openSUSE
after Fedora. Wanna guess if openSUSE kerenls are present in Fedora
grub.cfg?

> Name something you can only do via chainloading that you cannot do by keeping a singular
> primary boot loader up-to-date.

This requires close cooperation between *all* installed OSes that is
simply not going to happen.

Oh, and how to you add options for Windows loader to you primary grub2
bootloader?

> Chainloading is a relic of BIOS limitations. It's a relic of boot sectors. That's not how things
> work with UEFI. The way forward is precisely the end to chainloading.

Huh? EFI has master bootloader which *chainloads* other bootladers. If
anything, this is "chainloading made right".


  reply	other threads:[~2013-02-19  5:02 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-07 10:47 GRUB and the risk of block list corruption in extX Martin Wilck
2013-02-08 11:44 ` Martin Wilck
2013-02-08 16:57 ` Vladimir 'phcoder' Serbinenko
2013-02-08 17:17   ` Vladimir 'phcoder' Serbinenko
2013-02-08 17:17   ` Martin Wilck
2013-02-08 18:42     ` Lennart Sorensen
2013-02-08 18:56       ` Bruce Dubbs
2013-02-08 18:58         ` Lennart Sorensen
2013-02-08 19:11           ` Andrey Borzenkov
2013-02-18 15:42       ` Martin Wilck
2013-02-09  6:22     ` Chris Murphy
2013-02-18 17:16       ` Martin Wilck
2013-02-18 21:07         ` Chris Murphy
2013-02-19  5:02           ` Andrey Borzenkov [this message]
2013-02-19  6:24             ` Chris Murphy
2013-02-19  8:43               ` Michael Chang
2013-02-19  9:06                 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-19 18:54                 ` Chris Murphy
2013-02-19  8:47           ` Martin Wilck
2013-02-19 18:56             ` Chris Murphy
2013-02-19 19:46               ` Martin Wilck
2013-02-19  9:37           ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-19 12:58             ` Martin Wilck
2013-02-19 15:48               ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-02-19 17:17                 ` Martin Wilck
2013-02-19  5:26 ` Andrey Borzenkov
2013-02-19 10:54   ` Martin Wilck
2013-05-03  5:01 ` Andrey Borzenkov
2013-05-03  8:21   ` Martin Wilck
2013-05-03 19:21     ` Dr. Tilmann Bubeck
  -- strict thread matches above, loose matches on Subject: below --
2013-02-10  0:17 Chris Murphy
2013-02-10  4:45 ` Theodore Ts'o
2013-02-11 15:38 ` Eric Sandeen
2013-02-07 10:18 Martin Wilck
2013-02-07 13:27 ` Jan Kara
2013-02-07 15:50 ` Eric Sandeen
2013-02-07 20:53 ` Theodore Ts'o
2013-02-08 10:15   ` Martin Wilck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA91j0XOtgcqiF2DHy9AT1tickwWLsqt2P3ayf8HSL7bxYJf8g@mail.gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.