Prev: ECC error correction/scrubbing on x86-64
Next: Facing Problem with USB Floppy Drive while using write protected floppy.
From: Robert Nichols on 29 Jan 2010 20:42
In article <rpG8n.58207$Yi4.1348(a)news.usenetserver.com>,
Andrew Gideon <c182driver1(a)gideon.org> wrote:
:On Thu, 28 Jan 2010 22:19:30 -0600, Robert Nichols wrote:
:
:> So, when you install stage 1 in the MBR or in one of those partitions
:> within the extended partition, there is room to embed stage 1.5. If you
:> install stage 1 in the boot sector of any of the primary partitions,
:> there is no space available, and the embedding will fail.
:
:Since I am not using an extended partition, it appears that I can
:conclude that I am not using a stage 1.5. Correct?

I believe I just said that with stage 1 installed in the MBR there is
room for stage 1.5.

:> Without an
:> embedded stage 1.5, the stage 1 boot loader will contain sector
:> addresses of files in /boot, and booting will likely fail if those files
:> are moved.
:
:Where "moved" means "moved on physical disk" (as opposed to the "mv"
:command), right?

Yes. Note that even overwriting the same file can result in different
blocks being allocated. When a file is opened for just writing (as
opposed to read/write or append), it is first truncated to zero length
and the old storage blocks released. Whether the new content begins at
the same physical location depends on the FS allocation strategy.

[SNIP]
:> The above is true for the case without LVM. I have never used LVM, so I
:> don't know what goes on within its logical volumes. If your drive has
:> only primary partitions, I believe the only opportunity for embedding
:> stage 1.5 would be when stage 1 is installed in the MBR.
:
:This lost me. Is there a place to embed a stage1.5 if only primary
:partitions are in use?

Yes, there is usually space in the remainder of the track that contains
the MBR. You have to install GRUB in the MBR to use that.

:> And BTW, if you turn off "DOS Compatibility Mode" when partitioning the
:> disk, then those 62 sectors are not left free and there is nowhere that
:> stage 1.5 can be embedded.
:
:Is there a way to determine if "DOS Compatibility Mode" was used on a
:given disk? I don't know whether Fedora's installer defaults to having
:this set or not.

Run 'fdisk' on the drive, type "x" to go into expert mode, then "p" to
display the partition list. Note the numbers in the "Start" column. If
you see a number larger than 18 (it will typically be "63") for
partition 1, then there is sufficient space to embed if GRUB is
installed in the MBR. Here's an actual example (just don't ask how I
got that mess -- it's a test system and partitions have been shuffled
around repeatedly by a variety of tools):

Command (m for help): x

Expert command (m for help): p

Disk /dev/sda: 255 heads, 63 sectors, 121601 cylinders

Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID
1 00 1 1 0 254 63 1023 63 104872257 da
2 80 0 1 1023 254 63 1023 104872320 3164805 83
3 00 0 1 1023 254 63 1023 108037125 3164805 83
4 00 0 1 1023 254 63 1023 111201930 1842318135 05
5 00 1 1 1023 254 63 1023 63 20980827 83
6 00 1 1 1023 254 63 1023 63 67119507 83
7 00 0 2 1023 227 39 1023 1 12287999 82
8 00 228 40 1023 254 63 1023 63 20982552 83
9 00 1 1 1023 254 63 1023 63 67119507 83
10 00 0 2 1023 118 6 1023 1 61439999 83
11 00 119 7 1023 254 63 1023 63 41954277 83

Embedding will succeed when GRUB is installed in the MBR or in the boot
sectors of partitions 5, 6, 8, 9, or 11.

The acid test, of course, is to run the grub installer and see whether
embedding succeeds.

--
Bob Nichols AT comcast.net I am "RNichols42"
From: Robert Nichols on 29 Jan 2010 20:46
In article <op.u7a9mdtqa3w0dxdave(a)hodgins.homeip.net>,
David W. Hodgins <dwhodgins(a)nomail.afraid.org> wrote:
:On Fri, 29 Jan 2010 14:11:19 -0500, Andrew Gideon <c182driver1(a)gideon.org> wrote:
:
:> triggered the problem. So it is appearing that an upgrade of grub can
:> leave a system unbootable if the stage1 isn't being updated...which can
:
:On my mandriva system, "rpm -q --scripts grub" shows the postinstall
:scriptlet that gets executed when a grub update is installed.
:
:The script determines where(if) grub is installed, and then updates
:it (if found to be installed), generating an error message if grub
:has been installed into more than one place.

On Red Hat and Fedora systems, the scripts just install the GRUB manual
in /usr/share/info. Nothing else.

--
Bob Nichols AT comcast.net I am "RNichols42"
From: Peter D. on 30 Jan 2010 20:01
on Fri, 29 Jan 2010 03:19 pm
in the Usenet newsgroup comp.os.linux.hardware
Robert Nichols wrote:

> In article <l1i8n.27418$377.22127(a)news.usenetserver.com>,
> Andrew Gideon <c182driver1(a)gideon.org> wrote:
> :On Wed, 27 Jan 2010 10:23:19 -0600, Robert Nichols wrote:
> [SNIP]
> :> If you do have an embedded stage 1.5 then all is well. The stage1_5
> :> file appropriate to the file system gets installed in a fixed area**
> :> outside the file system, and so is not overwritten by the upgrade. Stage
> :> 1.5 understands that file system and finds the stage 2 file that way.
> :
> :I understand - perhaps incorrectly *laugh* - that stage1 is written to
> :either the MBR or the beginning of the bootable partition. If the
> :latter, where is stage1.5 written?
> :
> :>
> :> ** The MBR and logical drives within an extended partition typically
> :> have the remainder of the track containing the main or extended
> :> partition table available for this. The primary partitions do not,
> :> and you'll see the "embed ... failed (this is not fatal)" message
> :> when you try to install GRUB on those partition boot sectors.
> :
> :I'm afraid that I don't understand that paragraph. Even from the
> :beginning: What is a "logical drive"?
> :
> :I do understand partitioning, and extended partitions vs. primary. But
> :it seems to me that you're writing that one can only put a stage1.5 in an
> :extended partition, and that would surprise me since I actually tend to
> :not have extended partitions. I use LVM, so I typically have only two or
> :perhaps three partitions: /boot and the partition used as a physical
> :volume for LVM.
>
> The extended partition is a primary partition. Within it are one or
> more logical partitions, AKA "logical drives." Each of those begins
> with a partition table, just like the MBR on the physical drive. As is
> the case with the MBR, the remainder of the track following the sector
> with the partition table is commonly left free, and the start of data
> for the filesystem (or whatever) is at the first sector of the next
> track. The most common virtual geometry is 63 sectors per track, and
> stage 1.5 fits easily in those remaining 62 sectors. (The largest stage
> 1.5 needs 19 sectors.) So, when you install stage 1 in the MBR or in
> one of those partitions within the extended partition, there is room to
> embed stage 1.5. If you install stage 1 in the boot sector of any of
> the primary partitions, there is no space available, and the embedding
> will fail. Without an embedded stage 1.5, the stage 1 boot loader will
> contain sector addresses of files in /boot, and booting will likely fail
> if those files are moved. ("Likely," because the old data blocks are
> not necessarily overwritten when the files are moved. It is entirely
> possible that the system would still boot, using the old data blocks,
> only to fail some time later when an unrelated action caused those
> blocks to be allocated to something else and overwritten.)
>
> The above is true for the case without LVM. I have neverSo used LVM, so I
> don't know what goes on within its logical volumes. If your drive has
> only primary partitions, I believe the only opportunity for embedding
> stage 1.5 would be when stage 1 is installed in the MBR.
>
> And BTW, if you turn off "DOS Compatibility Mode" when partitioning the
> disk, then those 62 sectors are not left free and there is nowhere that
> stage 1.5 can be embedded.

So, if I ever find a partitioning tool that says, "only used by MS" then
it is a bug. It could do with a better name anyway.

--
Peter D.
Sig goes here...

From: Robert Nichols on 31 Jan 2010 11:09
In article <fb1f37-nv1.ln1(a)psd.motzarella.org>,
Peter D. <p13(a)g-node.com.au> wrote:
:on Fri, 29 Jan 2010 03:19 pm
:in the Usenet newsgroup comp.os.linux.hardware
:Robert Nichols wrote:
[very big SNIP]
:> And BTW, if you turn off "DOS Compatibility Mode" when partitioning the
:> disk, then those 62 sectors are not left free and there is nowhere that
:> stage 1.5 can be embedded.
:
:So, if I ever find a partitioning tool that says, "only used by MS" then
:it is a bug. It could do with a better name anyway.

Come again???? That statement makes little sense. The function of DOS
Compatibility Mode is to ensure that each partition's start of data is
at the start of a track, which was a requirement back in the days of
MS-DOS** and C/H/S disk addressing. The effect is that wherever there
is a primary or secondary partition table, the remainder of that track
is left unused and the partition begins at the start of the next track.
In today's world of virtual geometries and LBA disk addressing there is
really no need for that, but various boot loaders, disk management
tools, and the like (viruses, too) do make use of that free space.

Some partitioning tools ('fdisk' is one) allow you to turn off DOS
Compatibility Mode (it is ON by default) and have the partition start at
the sector immediately following the partition table, thus reclaiming
that "wasted" space (maximum of 62 sectors -- not a big deal with
today's disk sizes). So, which is it that you consider a bug:
partitioning tools that leave that "MS-only" free space (that would be
the default for _all_ of them), or tools that provide the option to
reclaim it?

** I have no idea whether recent versions of MS-Windows still require
that file systems begin on a track boundary.

--
Bob Nichols AT comcast.net I am "RNichols42"
From: Peter D. on 4 Feb 2010 06:39
on Mon, 1 Feb 2010 03:09 am
in the Usenet newsgroup comp.os.linux.hardware
Robert Nichols wrote:

> In article <fb1f37-nv1.ln1(a)psd.motzarella.org>,
> Peter D. <p13(a)g-node.com.au> wrote:
> :on Fri, 29 Jan 2010 03:19 pm
> :in the Usenet newsgroup comp.os.linux.hardware
> :Robert Nichols wrote:
> [very big SNIP]
> :> And BTW, if you turn off "DOS Compatibility Mode" when partitioning
the
> :> disk, then those 62 sectors are not left free and there is nowhere
that
> :> stage 1.5 can be embedded.
> :
> :So, if I ever find a partitioning tool that says, "only used by MS" then
> :it is a bug. It could do with a better name anyway.
>
> Come again???? That statement makes little sense.

Sorry. I'll try again.

Somewhere in the dim, dark, unreliable recesses of my mind I have the
memory of deliberately not using the DOS compatible mode, because as
a Linux user, I thought that I had no use for it. I prefer LiLo, but
recent discussions here indicate that for the reliable use of GRUB,
DOS compatible mode is highly desirable. i.e. It is a mistake for
for a Linux user to not use DOS compatible mode.

As I now understand things any documentation that suggests, directly
or indirectly, that DOS compatible mode is something that only DOS
(or Windows) users need worry about is wrong. If a user interface
causes a user to select an option that makes a computer unbootable
I would suggest that that is a bug.

> The function of DOS
> Compatibility Mode is to ensure that each partition's start of data is
> at the start of a track, which was a requirement back in the days of
> MS-DOS** and C/H/S disk addressing.

Original purpose, but not only use.

> The effect is that wherever there
> is a primary or secondary partition table, the remainder of that track
> is left unused and the partition begins at the start of the next track.
> In today's world of virtual geometries and LBA disk addressing there is
> really no need for that, but various boot loaders, disk management
> tools, and the like (viruses, too) do make use of that free space.

I'm with you.

> Some partitioning tools ('fdisk' is one) allow you to turn off DOS
> Compatibility Mode (it is ON by default) and have the partition start at
> the sector immediately following the partition table, thus reclaiming
> that "wasted" space (maximum of 62 sectors -- not a big deal with
> today's disk sizes). So, which is it that you consider a bug:
> partitioning tools that leave that "MS-only" free space (that would be
> the default for _all_ of them), or tools that provide the option to
> reclaim it?
>
> ** I have no idea whether recent versions of MS-Windows still require
> that file systems begin on a track boundary.

I would consider it a bug to misinform the user such that they are
tempted to do something that can make their system unbootable. A DOS
mode does not seem very important to this Linux user.

On my current system cfdisk has a toggle labelled "Maximise" rather
than DOS compatibility. I think that the name change is a big
improvement, although I found no reference to GRUB in the man pages.

--
Peter D.
Sig goes here...

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: ECC error correction/scrubbing on x86-64
Next: Facing Problem with USB Floppy Drive while using write protected floppy.