There is a solution under way. Linux 3.10 will include code written by
me to secure core.img of grub when running from ext4. This means, that
ext4 will be as safe to use for grub chainloading as btrfs or any other
filesystem offering "embedding".
I am currently extending grub-setup.c to use th
Andrey,
> Here is example how using filesystem blocklists may lead to unbootable
> system without any extX corruption involved.
>
> - user sets up multiboot system with Windows as primary bootloader
> - standard technique to add Linux loaders has always been - copy
> partition boot sector and "
В Thu, 07 Feb 2013 11:47:33 +0100
Martin Wilck пишет:
> Hello,
>
> this is a question about the long-running topic of installing GRUB in
> partitions or partitionless disks.
>
Here is example how using filesystem blocklists may lead to unbootable
system without any extX corruption involved.
-
On 02/19/2013 07:56 PM, Chris Murphy wrote:
>> The biggest argument for Fedora not being able to do this has been the
>> claimed danger of block list corruption.
> The biggest argument is:
> https://bugzilla.redhat.com/show_bug.cgi?id=872826#c10
Sorry, I see nothing in that comment that I'd call
On Feb 19, 2013, at 1:47 AM, Martin Wilck wrote:
> Chris,
>
>> Effectively you're asking for indefinitely supporting GRUB 0.9, by requiring
>> other dependencies so that can happen.
>
> The only other dependency I am asking for is the ability for the distro
> boot loader to be installed in th
On Feb 19, 2013, at 1:43 AM, Michael Chang wrote:
> 2013/2/19 Chris Murphy :
>>
>> It's also untrue. GRUB can first load a grub.cfg pointing to the grub.cfg of
>> each distribution; those distribution specific grub.cfg's are updated by
>> those distributions. The first grub.cfg only needs upd
>> Am I understanding correctly that the user mistake you describe must be
>> some manipulation of "core.img" itself (e.g. running grub2-mkimage but
>> now grub2-setup, which would classify as "mistake" in a blocklist setup)?
>
> Yes. Such kind of mistakes. Or deleting GRUB and restoring it from b
On 19.02.2013 13:58, Martin Wilck wrote:
> Vladimir,
>
> thanks for your thoughtful answer. I understand your concerns better now.
>
> On 02/19/2013 10:37 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> Suppose blocklist changes because of e.g. user mistake. Yet at the old
>> location the
Vladimir,
thanks for your thoughtful answer. I understand your concerns better now.
On 02/19/2013 10:37 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Suppose blocklist changes because of e.g. user mistake. Yet at the old
> location there is still the old core.img. For the time being. So thi
Andrey,
> I think this is simply the wrong question for upstream. The primary
> consideration is, what happens inside filesystem is outside of grub
> scope, so grub simply cannot commit itself to saying "it's fine and we
> support it everywhere". Because grub has no control over what happens.
But
I haven't gone through this whole thread yet but this is one of problems
with blocklist installs:
Suppose blocklist changes because of e.g. user mistake. Yet at the old
location there is still the old core.img. For the time being. So this
problem may go unnoticed for years yet if someone has the ab
On 19.02.2013 09:43, Michael Chang wrote:
> They could still booting to other distribution via
> togging the active flag and perform the rescue of data.
If they have the ability to toggle this flag, why don't they have the
ability to simply reinstall bootloader?
signature.asc
Description: Ope
Chris,
> Effectively you're asking for indefinitely supporting GRUB 0.9, by requiring
> other dependencies so that can happen.
The only other dependency I am asking for is the ability for the distro
boot loader to be installed in the root or boot partition. That's not much.
The biggest argument
2013/2/19 Chris Murphy :
>
> On Feb 18, 2013, at 10:02 PM, Andrey Borzenkov wrote:
>
>>
>> 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 a system has on
On Feb 18, 2013, at 10:02 PM, Andrey Borzenkov wrote:
>
> 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 a system has only linux, chain loading doesn't nee
On Thu, Feb 7, 2013 at 2:47 PM, Martin Wilck
wrote:
> Hello,
>
Hi Martin
> this is a question about the long-running topic of installing GRUB in
> partitions or partitionless disks.
>
> Recently I have been involved in discussions about this on
> https://bugzilla.redhat.com/show_bug.cgi?id=872826
On Tue, Feb 19, 2013 at 1:07 AM, Chris Murphy 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 i
On Feb 18, 2013, at 10:16 AM, Martin Wilck wrote:
> Using chainloading has the advantage that the primary bootloader (it's
> indeed GRUB 0.9x in my case) doesn't have to understand the more
> advanced filesystems of newer distros.
Updating your boot loader has the advantage that you don't need
Chris,
> Why do you specifically want a blocklist method of getting the primary
> bootloader to load the second?
I may have expressed myself unclearly.
What I want is the *secondary* boot loader to be able to load *its own
code* from a partition header (e.g. ext4) using block lists. The primar
On 02/08/2013 07:42 PM, Lennart Sorensen wrote:
> Of course the block list breaks if the file in the filesystem is modified
> or moved without updating the block list, which used to break lilo all the
> time whenever one forgot to run the lilo command after making a change.
True. lilo accessed th
On Feb 8, 2013, at 10:17 AM, Martin Wilck wrote:
>> This is not a complete answer but one of my problems is that such
>> requests don't even suply any kind of reason to go into such installs.
>> We nerd to consider usecases before even considering using an approach
>> which is known for some pre
В Fri, 8 Feb 2013 13:58:36 -0500
"Lennart Sorensen" пишет:
> On Fri, Feb 08, 2013 at 12:56:52PM -0600, Bruce Dubbs wrote:
> > You don't need an EFI system to give GRUB enough space. You just
> > need to partition the drive so the first partition starts at 1MB
> > instead of sector 63. I think u
On Fri, Feb 08, 2013 at 12:56:52PM -0600, Bruce Dubbs wrote:
> You don't need an EFI system to give GRUB enough space. You just
> need to partition the drive so the first partition starts at 1MB
> instead of sector 63. I think using a GPT partition scheme is quite
> preferred over the MSDOS schem
Lennart Sorensen wrote:
On Fri, Feb 08, 2013 at 06:17:57PM +0100, Martin Wilck wrote:
In my case, the reason is a multiboot setup based on chainloading the
indiviual installed OS's bootloaders from a central, primary bootloader.
This is easily accomplished by installing the individual OS's
bootl
On Fri, Feb 08, 2013 at 06:17:57PM +0100, Martin Wilck wrote:
> In my case, the reason is a multiboot setup based on chainloading the
> indiviual installed OS's bootloaders from a central, primary bootloader.
> This is easily accomplished by installing the individual OS's
> bootloaders in their res
> This is not a complete answer but one of my problems is that such
> requests don't even suply any kind of reason to go into such installs.
> We nerd to consider usecases before even considering using an approach
> which is known for some pretty serious problems. Will answer in more
> details late
This is not a complete answer but one of my problems is that such requests
don't even suply any kind of reason to go into such installs. We nerd to
consider usecases before even considering using an approach which is known
for some pretty serious problems. Will answer in more details later.
On Feb
This is not a complete answer but one of my problems is that such requests
don't even suply any kind of reason to go into such installs. We nerd to
consider usecases before even considering using an approach which is known
for some pretty serious problems. Will answer in more details later.
On Feb
> herefore I asked a similar question on ext4-devel.
The ext4 developers have made some interesting comments on the subject:
http://thread.gmane.org/gmane.comp.file-systems.ext4/36911On 02/07/2013
Regards
Martin
--
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering
FUJIT
29 matches
Mail list logo
