Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #161932 > unrolled thread

Attempt to Move Root

Back to article view | Back to linux.debian.user

Contents

  Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-20 12:10 +0100
    Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-20 19:20 +0100
      Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-20 22:00 +0100
        Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-20 22:40 +0100
    Re: Attempt to Move Root David Christensen <dpchrist@holgerdanske.com> - 2015-12-21 10:00 +0100
      Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-21 11:00 +0100
        Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 16:30 +0100
          Re: Attempt to Move Root Lisi Reisz <lisi.reisz@gmail.com> - 2015-12-21 16:40 +0100
            Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 21:40 +0100
          Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-21 16:40 +0100
            Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 21:00 +0100
              Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-21 21:50 +0100
                Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-21 22:20 +0100
                  Re: Attempt to Move Root David Baron <d_baron@012.net.il> - 2015-12-22 08:50 +0100
              Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 17:00 +0100
                Re: Attempt to Move Root John Hasler <jhasler@newsguy.com> - 2015-12-22 18:40 +0100
                  Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 18:40 +0100
                    Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 19:50 +0100
                      Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-22 20:50 +0100
                        Re: Attempt to Move Root Brian <ad44@cityscape.co.uk> - 2015-12-22 21:20 +0100
                        Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-22 23:10 +0100
                          Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-22 23:30 +0100
                            Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-23 10:40 +0100
                              Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-24 02:20 +0100
                                Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-24 12:20 +0100
                              Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-27 14:10 +0100
                                Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-27 14:50 +0100
                                  Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-27 15:20 +0100
                                    Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-27 15:40 +0100
                                      Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-27 16:00 +0100
                                        Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-27 16:20 +0100
                                          Re: Attempt to Move Root Nicolas George <george@nsup.org> - 2015-12-28 03:50 +0100
                                          Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-28 03:50 +0100
                                      Re: Attempt to Move Root Gene Heskett <gheskett@shentel.net> - 2015-12-27 16:10 +0100
                                        Re: Attempt to Move Root Petter Adsen <petter@synth.no> - 2016-01-01 10:20 +0100
                                          Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-01-01 11:40 +0100
                                Re: Attempt to Move Root Sven Hartge <sven@svenhartge.de> - 2015-12-28 03:50 +0100
                                  Re: Attempt to Move Root Pascal Hambourg <pascal@plouf.fr.eu.org> - 2015-12-28 03:50 +0100
                          Re: Attempt to Move Root Brian <ad44@cityscape.co.uk> - 2015-12-22 23:40 +0100
                        Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-25 17:10 +0100
                    Re: Attempt to Move Root John Hasler <jhasler@newsguy.com> - 2015-12-22 19:50 +0100
                      Re: Attempt to Move Root (SOLVED!!) David Baron <d_baron@012.net.il> - 2015-12-23 10:00 +0100
                        Re: Attempt to Move Root (SOLVED!!) Anders Andersson <pipatron@gmail.com> - 2015-12-23 12:50 +0100
                          Re: Attempt to Move Root (SOLVED!!) David Baron <d_baron@012.net.il> - 2015-12-23 13:20 +0100
                Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-25 16:40 +0100
                  Re: Attempt to Move Root Stephen Powell <zlinuxman@wowway.com> - 2015-12-28 05:00 +0100
        Re: Attempt to Move Root David Christensen <dpchrist@holgerdanske.com> - 2015-12-21 20:00 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#162005

[Multipart message — attachments visible in raw view] — view raw

Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> In ye olde days (pre-Windowsm 98) some programs (I think Photoshop did
> it.) wrote licence data into that space, because it was unused. The copy
> protection scheme of some games also tried to hide information there.
> 
> So "nobody" is not quite right. "nobody with the right mind" would be a
> better description.

I did not know that, it is simply disgusting. Well, if you have to deal with
bad-behaved proprietary programs that fancy themselves more powerful than
the operating system, then you can not use that feature of GRUB. That means
you have to put its second stage in a partition; obviously, this is possible
too.

But when dealing with that level of stupidity, really there is nothing to
do: we can not trust these proprietary programs will not decide to write
anywhere on the disk just because they have decided they have the right to
do so, or because they have a bug.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#162008

Nicolas George <george@nsup.org> wrote:
> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :

>> In ye olde days (pre-Windowsm 98) some programs (I think Photoshop
>> did it.) wrote licence data into that space, because it was unused.
>> The copy protection scheme of some games also tried to hide
>> information there.
>> 
>> So "nobody" is not quite right. "nobody with the right mind" would be
>> a better description.

> I did not know that, it is simply disgusting. Well, if you have to
> deal with bad-behaved proprietary programs that fancy themselves more
> powerful than the operating system, then you can not use that feature
> of GRUB. That means you have to put its second stage in a partition;
> obviously, this is possible too.

> But when dealing with that level of stupidity, really there is nothing
> to do: we can not trust these proprietary programs will not decide to
> write anywhere on the disk just because they have decided they have
> the right to do so, or because they have a bug.

And this is why I love the GPT. There is a defined space for the
bootloader to be and no nether region of swirly unknowness between the
MBR and the start of the first partition.

Also this: Sit back kids, Uncle Sven tells a story from the trenches of
the 1st GRUB war.

I was upgrading a remote server from Squeeze to Wheezy. This server uses
LVM on top of an MD-RAID1, /boot is included in / which is a LV. so GRUB
needs to know about MD and LVM (and the filesystem of / of course).

With Squeeze everything was fine and dandy.

But after upgrading to Wheezy, GRUB would no longer install into the
31744 byte-sized space after the MBR. Its core.img with all needed
componenents was 12 bytes to large, about 60 bytes bigger than the one
from Squeeze!

What to do? Using the old one from Squeeze? Psshht, needing to hold the
old package for ever, maybe making the system unbootable in the worst
moment? Not an option!

But we have a MD-RAID! I removed one disk from the RAID, repartitioned
it as GPT, added a bios_grub partition of the right (and future-proof!)
size before the data partition, readded this to the running half of the
RAID, let the RAID resync, repeated the whole procedure with the other
disk, installed GRUB to its new home, rebooted while hoping/praying and
... tadaaa ... the system came right up.

This of course was only possible because the MD-RAID code allows for a
slight variation on the partition size so I had to be careful to stay
inside that margin but in the end it worked out fine with only 3 minutes
of downtime for the reboot.

And because of that experience I use only the GPT for physical servers,
even when booting in legacy mode. Because I have a known place of a
known size for the boot loader.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#162025

[Multipart message — attachments visible in raw view] — view raw

Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> And this is why I love the GPT. There is a defined space for the
> bootloader to be and no nether region of swirly unknowness between the
> MBR and the start of the first partition.

The UEFI boot system is indeed a great improvement, or would be if it was
correctly implemented by vendors, but do not expect too much of it.

You can have already a partition dedicated to the bootloader with old-style
MBR partitions.

If dealing with programs that bypass the operating system and write outside
partitions, GPT will not help. It may even make things worse if the program
does not know it and gets confused.

The core of it is: no program, even an operating system, should ever write
outside partitions except at the direct request of the administrator. If
this rule is kept, then there is nothing to worry about, except mistakes,
and GRUB's hack works. If this rule is violated, then there is nothing to be
done, all hell can break loose at any time.

> Also this: Sit back kids, Uncle Sven tells a story from the trenches of
> the 1st GRUB war.
> 
> I was upgrading a remote server from Squeeze to Wheezy. This server uses
> LVM on top of an MD-RAID1, /boot is included in / which is a LV. so GRUB
> needs to know about MD and LVM (and the filesystem of / of course).
> 
> With Squeeze everything was fine and dandy.
> 
> But after upgrading to Wheezy, GRUB would no longer install into the
> 31744 byte-sized space after the MBR. Its core.img with all needed
> componenents was 12 bytes to large, about 60 bytes bigger than the one
> from Squeeze!
> 

> What to do? Using the old one from Squeeze? Psshht, needing to hold the
> old package for ever, maybe making the system unbootable in the worst
> moment? Not an option!

You seem to be missing something here: there is absolutely no requirement
that the GRUB version installed as a package on the distribution is the same
as the version installed as bootloader. You could have left the upgrade
replace GRUB or even removed the package for GRUB, just leaving the old
bootloader, that is not a problem.
> 
> But we have a MD-RAID! I removed one disk from the RAID, repartitioned
> it as GPT, added a bios_grub partition of the right (and future-proof!)
> size before the data partition, readded this to the running half of the
> RAID, let the RAID resync, repeated the whole procedure with the other
> disk, installed GRUB to its new home, rebooted while hoping/praying and
> ... tadaaa ... the system came right up.

The same thing would have worked with without GPT. Especially if you use a
bios_grub partition instead of an EFI system partition.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#162071

Nicolas George <george@nsup.org> wrote:
> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :

>> And this is why I love the GPT. There is a defined space for the
>> bootloader to be and no nether region of swirly unknowness between the
>> MBR and the start of the first partition.

>> Also this: Sit back kids, Uncle Sven tells a story from the trenches of
>> the 1st GRUB war.
>> 
>> I was upgrading a remote server from Squeeze to Wheezy. This server uses
>> LVM on top of an MD-RAID1, /boot is included in / which is a LV. so GRUB
>> needs to know about MD and LVM (and the filesystem of / of course).
>> 
>> With Squeeze everything was fine and dandy.
>> 
>> But after upgrading to Wheezy, GRUB would no longer install into the
>> 31744 byte-sized space after the MBR. Its core.img with all needed
>> componenents was 12 bytes to large, about 60 bytes bigger than the one
>> from Squeeze!
>> 

>> What to do? Using the old one from Squeeze? Psshht, needing to hold the
>> old package for ever, maybe making the system unbootable in the worst
>> moment? Not an option!

> You seem to be missing something here: there is absolutely no
> requirement that the GRUB version installed as a package on the
> distribution is the same as the version installed as bootloader. You
> could have left the upgrade replace GRUB or even removed the package
> for GRUB, just leaving the old bootloader, that is not a problem.

Yes, but I wanted to be sure that there will be no suprises for me or
another administrator in the future. Having no GRUB package installed
would have deviated from the norm, could cause strange side-effects with
other packages or the packages manager and keeping the old version
installed would have been ugly.

The idea was to have a system which fits one of the server templates
used and not create another special snowflake which needs manual
attention every time.

>> But we have a MD-RAID! I removed one disk from the RAID, repartitioned
>> it as GPT, added a bios_grub partition of the right (and future-proof!)
>> size before the data partition, readded this to the running half of the
>> RAID, let the RAID resync, repeated the whole procedure with the other
>> disk, installed GRUB to its new home, rebooted while hoping/praying and
>> ... tadaaa ... the system came right up.

> The same thing would have worked with without GPT. Especially if you use a
> bios_grub partition instead of an EFI system partition.

Eh? I did use a bios_grub partition, because the server in question uses
a legacy BIOS to boot.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#162085

[Multipart message — attachments visible in raw view] — view raw

Le quartidi 4 nivôse, an CCXXIV, Sven Hartge a écrit :
> > The same thing would have worked with without GPT. Especially if you use a
> > bios_grub partition instead of an EFI system partition.
> Eh? I did use a bios_grub partition, because the server in question uses
> a legacy BIOS to boot.

Then you confirm what I wrote: you could have done exactly the same with
legacy MBR partitions, GPT was not needed for that operation.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#162127

Nicolas George a écrit :
> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
>> And this is why I love the GPT. There is a defined space for the
>> bootloader to be and no nether region of swirly unknowness between the
>> MBR and the start of the first partition.

Note that current partition tools leave a bigger gap than ~31 KB,
typically ~1 MB to ensure partition alignment. So on a newer
installation you would not face that problem again even with an MSDOS
partition table.

> The UEFI boot system is indeed a great improvement, or would be if it was
> correctly implemented by vendors, but do not expect too much of it.

You are confusing GPT (partition table format) and UEFI (firmware and
boot interface).

> You can have already a partition dedicated to the bootloader with old-style
> MBR partitions.

Can you tell more ? AFAIK, there is no equivalent to the "BIOS boot"
partition in the MSDOS partition scheme.

> You seem to be missing something here: there is absolutely no requirement
> that the GRUB version installed as a package on the distribution is the same
> as the version installed as bootloader. You could have left the upgrade
> replace GRUB or even removed the package for GRUB, just leaving the old
> bootloader, that is not a problem.

I beg to differ.
Upgrading the GRUB package will automatically try to reinstall the
bootloader it is responsible for. If it fails, it will install the new
modules in /boot/grub/ and leave the old boot image and core image,
leading to a version mismatch.
Also, the grub.cfg config file created by grub-mkconfig or update-grub
may not be compatible with the bootloader installed by another version
of GRUB because of changes in syntax or modules.

Of course you are correct if the GRUB package is not responsible for the
active bootloader.

> The same thing would have worked with without GPT.

Yes, by leaving a bigger gap between the MBR and the first partition.

> Especially if you use a
> bios_grub partition instead of an EFI system partition.

A bios_grub (actually "BIOS boot") partition without GPT ? Please tell
me more !

[toc] | [prev] | [next] | [standalone]

#162130

[Multipart message — attachments visible in raw view] — view raw

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> You are confusing GPT (partition table format) and UEFI (firmware and
> boot interface).

Quite the contrary, I am trying to de-confuse by using exactly the correct
terms.

> Can you tell more ? AFAIK, there is no equivalent to the "BIOS boot"
> partition in the MSDOS partition scheme.

What is there to tell more? You create a partition and decide it is for the
bootloader, period.

> I beg to differ.
> Upgrading the GRUB package will automatically try to reinstall the
> bootloader it is responsible for. If it fails, it will install the new
> modules in /boot/grub/ and leave the old boot image and core image,
> leading to a version mismatch.
> Also, the grub.cfg config file created by grub-mkconfig or update-grub
> may not be compatible with the bootloader installed by another version
> of GRUB because of changes in syntax or modules.
> 
> Of course you are correct if the GRUB package is not responsible for the
> active bootloader.

Agreed.

[toc] | [prev] | [next] | [standalone]

#162132

Nicolas George a écrit :
> Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
>> You are confusing GPT (partition table format) and UEFI (firmware and
>> boot interface).
> 
> Quite the contrary, I am trying to de-confuse by using exactly the correct
> terms.

There was nothing confusing in Sven's message until you mentionned UEFI
in response to "I love the GPT". Why did you start talking about UEFI ?

>> Can you tell more ? AFAIK, there is no equivalent to the "BIOS boot"
>> partition in the MSDOS partition scheme.
> 
> What is there to tell more? You create a partition and decide it is for the
> bootloader, period.

Could you please give a concrete example ?
AFAIK, GRUB cannot use a partition in MSDOS format to store its core
image in the same way as it uses a BIOS boot partition in GPT format.
If you're talking about a partition mounted on /boot/grub, it is not the
same at all. If you're talking about another bootloader, please name it.

[toc] | [prev] | [next] | [standalone]

#162133

[Multipart message — attachments visible in raw view] — view raw

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> There was nothing confusing in Sven's message until you mentionned UEFI
> in response to "I love the GPT". Why did you start talking about UEFI ?

For the early stage of booting, there is no difference between MBR-style
partitions (it is more accurate and less ambiguous than "MSDOS-style") and
GPT-style partitions. There are only sectors accessed through a BIOS call.
Therefore, if something makes booting easier, it's not GPT, it's UEFI.

> Could you please give a concrete example ?
> AFAIK, GRUB cannot use a partition in MSDOS format to store its core
> image in the same way as it uses a BIOS boot partition in GPT format.

What makes you say that? There is nothing special about GPT partitions, they
are intervals of sectors, just as MBR-style partitions.

[toc] | [prev] | [next] | [standalone]

#162134

Nicolas George a écrit :
> Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
>> There was nothing confusing in Sven's message until you mentionned UEFI
>> in response to "I love the GPT". Why did you start talking about UEFI ?
> 
> For the early stage of booting, there is no difference between MBR-style
> partitions (it is more accurate and less ambiguous than "MSDOS-style") and
> GPT-style partitions. There are only sectors accessed through a BIOS call.

I agree, but a dedicated space on a partition is a safer location than
unallocated disk space or a filesystem.

> Therefore, if something makes booting easier, it's not GPT, it's UEFI.

*Cough*
At least it was supposed to. The more I mess with UEFI implementations,
the more I feel dubious about its real advantages.

>> AFAIK, GRUB cannot use a partition in MSDOS format to store its core
>> image in the same way as it uses a BIOS boot partition in GPT format.
> 
> What makes you say that?

My experience and the documentation I read. If you know a way to have
GRUB install its core image into an arbitrary partition, I'd love to
learn about it.

[toc] | [prev] | [next] | [standalone]

#162137

[Multipart message — attachments visible in raw view] — view raw

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> *Cough*
> At least it was supposed to. The more I mess with UEFI implementations,
> the more I feel dubious about its real advantages.

Six messages ago, I wrote "or would be if it was correctly implemented by
vendors"; you read it since you replied to it. Please try to keep up.

> My experience and the documentation I read.

If you manage to find usable documentation for GRUB, please share it.

In the meantime, I can tell what I saw in the code, and this is: GRUB makes
no difference between MBR-style partitions (that it calls internally
"msdos") and GPT.

[toc] | [prev] | [next] | [standalone]

#162139

[Multipart message — attachments visible in raw view] — view raw

Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> I repeat : the point is not MBR/MSDOS vs GPT. It is that the GRUB
> installer handles *specially* one type of partition which exists only in
> GPT style : "BIOS Boot" aka "bios_grub".
> 
> Are you talking about the installer code run by grub-install or the
> bootloader code ? I am not aware that the installer code can handle any
> partition type other than the above type in the same way.

I am talking about the installer, of course. The algorithm used is:

1. embed in the disk if possible, otherwise:
2. embed in the filesystem if possible, otherwise:
3. write in a file and print a warning.

It seems that no options are present to control this finely, which means it
will try to use the first method that works, but all the infrastructure is
there.

[toc] | [prev] | [next] | [standalone]

#162145

Nicolas George a écrit :
> 
> In the meantime, I can tell what I saw in the code, and this is: GRUB makes
> no difference between MBR-style partitions (that it calls internally
> "msdos") and GPT.

I repeat : the point is not MBR/MSDOS vs GPT. It is that the GRUB
installer handles *specially* one type of partition which exists only in
GPT style : "BIOS Boot" aka "bios_grub".

Are you talking about the installer code run by grub-install or the
bootloader code ? I am not aware that the installer code can handle any
partition type other than the above type in the same way.

[toc] | [prev] | [next] | [standalone]

#162136

On Sunday 27 December 2015 09:30:38 Nicolas George wrote:

> Le septidi 7 nivôse, an CCXXIV, Pascal Hambourg a écrit :
> > There was nothing confusing in Sven's message until you mentionned
> > UEFI in response to "I love the GPT". Why did you start talking
> > about UEFI ?
>
> For the early stage of booting, there is no difference between
> MBR-style partitions (it is more accurate and less ambiguous than
> "MSDOS-style") and GPT-style partitions. There are only sectors
> accessed through a BIOS call. Therefore, if something makes booting
> easier, it's not GPT, it's UEFI.
>
> > Could you please give a concrete example ?
> > AFAIK, GRUB cannot use a partition in MSDOS format to store its core
> > image in the same way as it uses a BIOS boot partition in GPT
> > format.
>
> What makes you say that? There is nothing special about GPT
> partitions, they are intervals of sectors, just as MBR-style
> partitions.

I made the mistake of trying to install a wheezy derivitive on a 2T drive 
that had been prepared using GPT partitions.  The installer could not 
see them at all, so after 2 tries, I just let it go ahead and do its own 
partitioning and formatting to ext4. The system has actually worked 
well, on a drive that is said to be too big for MBR.

So I would like to be enlightened as to the real differences between the 
systems. URL's to the proponents sites would be fine.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#162417

On Sun, 27 Dec 2015 10:07:13 -0500
Gene Heskett <gheskett@shentel.net> wrote:

> I made the mistake of trying to install a wheezy derivitive on a 2T
> drive that had been prepared using GPT partitions.  The installer
> could not see them at all, so after 2 tries, I just let it go ahead
> and do its own partitioning and formatting to ext4. The system has
> actually worked well, on a drive that is said to be too big for MBR.

The max addressable size of a drive for MBR is 2TiB, AIUI.

> So I would like to be enlightened as to the real differences between
> the systems. URL's to the proponents sites would be fine.

You can take a look at this, for starters:

https://wiki.archlinux.org/index.php/GPT

The first couple of sections highlights the differences between MBR and
GPT, and there are links to more information at the bottom of the page.

Petter

-- 
"I'm ionized"
"Are you sure?"
"I'm positive."

[toc] | [prev] | [next] | [standalone]

#162421

Petter Adsen a écrit :
> Gene Heskett <gheskett@shentel.net> wrote:
> 
>> I made the mistake of trying to install a wheezy derivitive on a 2T
>> drive that had been prepared using GPT partitions.  The installer
>> could not see them at all, so after 2 tries, I just let it go ahead
>> and do its own partitioning and formatting to ext4. The system has
>> actually worked well, on a drive that is said to be too big for MBR.
> 
> The max addressable size of a drive for MBR is 2TiB, AIUI.

Yes, assuming standard 512-byte sectors. A lot more with large 4096-byte
sectors ("4Kn" Advanced Format).

2 TiB > 2 TB, so GPT is not required for a 2 TB disk. However GPT has
other advantages over MSDOS than maximum addressable size.

[toc] | [prev] | [next] | [standalone]

#162138

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
> Nicolas George a écrit :
>> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :

>>> And this is why I love the GPT. There is a defined space for the
>>> bootloader to be and no nether region of swirly unknowness between
>>> the MBR and the start of the first partition.

> Note that current partition tools leave a bigger gap than ~31 KB,
> typically ~1 MB to ensure partition alignment. So on a newer
> installation you would not face that problem again even with an MSDOS
> partition table.

Correct. But that space is still indefined and who knows what tries to
write data into that place.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#162142

Sven Hartge a écrit :
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>>> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> 
>>>> And this is why I love the GPT. There is a defined space for the
>>>> bootloader to be and no nether region of swirly unknowness between
>>>> the MBR and the start of the first partition.
> 
>> Note that current partition tools leave a bigger gap than ~31 KB,
>> typically ~1 MB to ensure partition alignment. So on a newer
>> installation you would not face that problem again even with an MSDOS
>> partition table.
> 
> Correct. But that space is still indefined and who knows what tries to
> write data into that place.

You do know, if you only install and run open source software on this
machine. However that comment was just for completeness. I advocate and
favour GPT whenever I can.

[toc] | [prev] | [next] | [standalone]

#162009

On Tue 22 Dec 2015 at 23:05:54 +0100, Nicolas George wrote:

> Le duodi 2 nivôse, an CCXXIV, Sven Hartge a écrit :
> > In ye olde days (pre-Windowsm 98) some programs (I think Photoshop did
> > it.) wrote licence data into that space, because it was unused. The copy
> > protection scheme of some games also tried to hide information there.
> > 
> > So "nobody" is not quite right. "nobody with the right mind" would be a
> > better description.
> 
> I did not know that, it is simply disgusting. Well, if you have to deal with
> bad-behaved proprietary programs that fancy themselves more powerful than
> the operating system, then you can not use that feature of GRUB. That means
> you have to put its second stage in a partition; obviously, this is possible
> too.

Doesn't Reed-Solomon error correction on the core image take care of
this issue? Bug #550702, Message #70:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550702

  This is yet another modification on crappy windows applications like
  Flexible Lies Manager. This is neither Debian nor GRUB bug, but of the
  windows application which improperly writes to MBR gap.
  However this is a relatively widespread issue, so in upstream we now
  write that part using Reed-Solomon so we're not affected by this
  misbehaviour other than the time needed to recover from corruption in
  Reed-Solomon.

[toc] | [prev] | [next] | [standalone]

#162109

On Tue, 22 Dec 2015 14:44:31 -0500 (EST), Sven Hartge wrote:
> 
> In ye olde days (pre-Windowsm 98) some programs (I think Photoshop did
> it.) wrote licence data into that space, because it was unused. The copy
> protection scheme of some games also tried to hide information there.
> 

I can think of some other cases.  Back in the day when most BIOSes had
a head limit of 16, thus limiting the size of a hard disk addressable via
BIOS Int 13h functions 02h and 03h to 504MiB, programs such as Ontrack
Disk Manager could be installed to circumvent this restriction.  They
would hook the BIOS to increase the head limit to 255.  I believe this
was accomplished by putting the BIOS hook program in the boot sector
and moving the original boot sector to the second sector (CHS value
0:0:2).

Also, in the days of IBM 386 microchannel machines, such as the IBM
PS/2 model 70, IBM sold a memory board that initialized after POST
by using a similar boot hook.

Around that same time period, Novell Netware was known to also use an
unallocated sector, perhaps for licensing, copy protection, etc.
These schemes all conflicted with each other of course.  As I say in
my lilo web page, there are no rules for the use of unallocated sectors.

And grub-legacy and grub-pc (by default at least) now do a similar thing.
They store information in unallocated sectors.  That's one of the
reasons (but not the only reason) that I switched back to LILO.

-- 
  .''`.     Stephen Powell    <zlinuxman@wowway.com>
 : :'  :
 `. `'`
   `-

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web