Quantcast

gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Lawrence Stewart-3
Hi all,

I recently got a new HP Compaq Elite 8200 work desktop which has a
hybrid UEFI and regular BIOS arrangement. I want to dual-boot Win 7
64bit Enterprise via EFI and FreeBSD 9-STABLE via BIOS+gptzfsboot (until
such time as we gain EFI support of course) on the machine and ran into
a problem.

I finally got around to analysing the issue in detail and wrote it up here:

http://people.freebsd.org/~lstewart/misc/gpart_debug/

The summary is that FreeBSD's gpart rewrites the protective MBR with
0x80 (active) in the single MBR partition table entry, which makes the
MS EFI bootloader unhappy and it will stop booting Win 7.

The gpart command I ran to trigger the behaviour was "gpart modify -i 5
-t freebsd-zfs <geom>", where partition 5 was already created in Win 7
and manually set using Win 7's diskpart utility to type freebsd-zfs i.e.
the gpart command should have been a NOP. Indeed, the GPT remains
unchanged, but the pmbr gets changed, which is what breaks Win 7 booting.

After identifying the cause of the problem and a workaround (please see
the README.txt at the above URL for full details and pre/post gpart
dumps of the MBR+GPT), I have the following questions:


- Should gpart be writing 0x80 (active) in the protective MBR entry?

   - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?

- Should gpart be silently rewriting the protective MBR entry at all
when only asked to make changes to the GPT?


Thanks in advance for any insights and help.

Cheers,
Lawrence
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Andrey V. Elsukov
On 09.08.2012 12:57, Lawrence Stewart wrote:
> After identifying the cause of the problem and a workaround (please see the README.txt at the above
> URL for full details and pre/post gpart dumps of the MBR+GPT), I have the following questions:
>
> - Should gpart be writing 0x80 (active) in the protective MBR entry?

AFAIK, this was added because some BIOS could not boot without it.

>   - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?

This question you should ask to the Microsoft. :)

> - Should gpart be silently rewriting the protective MBR entry at all when only asked to make changes
> to the GPT?

The PMBR is part of GPT metadata described in the UEFI spec. So, I think it can.

--
WBR, Andrey V. Elsukov




signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Lawrence Stewart-3
Hi Andrey,

On 08/09/12 20:57, Andrey V. Elsukov wrote:
> On 09.08.2012 12:57, Lawrence Stewart wrote:
>> After identifying the cause of the problem and a workaround (please see the README.txt at the above
>> URL for full details and pre/post gpart dumps of the MBR+GPT), I have the following questions:
>>
>> - Should gpart be writing 0x80 (active) in the protective MBR entry?
>
> AFAIK, this was added because some BIOS could not boot without it.

Makes sense if gpart is writing the pmbr out i.e. "gpart bootcode -b
/boot/pmbr <geom>", but manipulating an existing pmbr for a GPT specific
subcommand smells dodgy to me.

>>   - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?
>
> This question you should ask to the Microsoft. :)

Perhaps I should rephrase my question as:

Is the MS bootloader's behaviour reasonable/unreasonable based on what
people know of the relevant specs? My current guess why it behaves like
this is that if it sees an MBR partition marked active, it simply
assumes another OS is in charge and therefore bails out at the Windows
EFI boot stage.

>> - Should gpart be silently rewriting the protective MBR entry at all when only asked to make changes
>> to the GPT?
>
> The PMBR is part of GPT metadata described in the UEFI spec. So, I think it can.

Can and should are two different things. I would argue it's a POLA
violation at the very least to manipulate the pmbr when the user asked
for something else. I certainly started my hunting expecting to find the
GPT changing in some subtle way when FreeBSD wrote it out compared to
what Windows writes.

We have a specific gpart command to put a pmbr in place so I think it's
reasonable to expect other GPT specific commands not to fiddle with the
pmbr.

Cheers,
Lawrence
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Andrey V. Elsukov-2
On 09.08.2012 16:11, Lawrence Stewart wrote:
>>> - Should gpart be writing 0x80 (active) in the protective MBR entry?
>>
>> AFAIK, this was added because some BIOS could not boot without it.
>
> Makes sense if gpart is writing the pmbr out i.e. "gpart bootcode -b
> /boot/pmbr <geom>", but manipulating an existing pmbr for a GPT specific
> subcommand smells dodgy to me.

When you create GPT it already has PMBR, because it is part of GPT
metadata. gpart's `bootcode' subcommand writes *bootcode* to specific
area in the PMBR.

>>>   - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?
>>
>> This question you should ask to the Microsoft. :)
>
> Perhaps I should rephrase my question as:
>
> Is the MS bootloader's behaviour reasonable/unreasonable based on what
> people know of the relevant specs? My current guess why it behaves like
> this is that if it sees an MBR partition marked active, it simply
> assumes another OS is in charge and therefore bails out at the Windows
> EFI boot stage.
In the EFI system partition might be several boot loaders, and this MS
bootloader's behaviour seems strange to me.

> Can and should are two different things. I would argue it's a POLA
> violation at the very least to manipulate the pmbr when the user asked
> for something else. I certainly started my hunting expecting to find the
> GPT changing in some subtle way when FreeBSD wrote it out compared to
> what Windows writes.
>
> We have a specific gpart command to put a pmbr in place so I think it's
> reasonable to expect other GPT specific commands not to fiddle with the
> pmbr.

Don't confuse bootcode in the PMBR and PMBR.

--
WBR, Andrey V. Elsukov


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Marcel Moolenaar
In reply to this post by Lawrence Stewart-3

On Aug 9, 2012, at 5:11 AM, Lawrence Stewart <[hidden email]> wrote:

> Hi Andrey,
>
> On 08/09/12 20:57, Andrey V. Elsukov wrote:
>> On 09.08.2012 12:57, Lawrence Stewart wrote:
>>> After identifying the cause of the problem and a workaround (please see the README.txt at the above
>>> URL for full details and pre/post gpart dumps of the MBR+GPT), I have the following questions:
>>>
>>> - Should gpart be writing 0x80 (active) in the protective MBR entry?
>>
>> AFAIK, this was added because some BIOS could not boot without it.
>
> Makes sense if gpart is writing the pmbr out i.e. "gpart bootcode -b
> /boot/pmbr <geom>", but manipulating an existing pmbr for a GPT specific
> subcommand smells dodgy to me.

Agreed. The original design of gpart was such that it could preserve
what it needed and only limit changes to what it was asked to do.

For the GPT scheme this meant that it would simply read the entire
PMBR, keep it in memory and write it back when updates are made.

etc...

>
>>>  - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?
>>
>> This question you should ask to the Microsoft. :)
>
> Perhaps I should rephrase my question as:
>
> Is the MS bootloader's behaviour reasonable/unreasonable based on what
> people know of the relevant specs? My current guess why it behaves like
> this is that if it sees an MBR partition marked active, it simply
> assumes another OS is in charge and therefore bails out at the Windows
> EFI boot stage.

I think the key distinction may be between BIOS and (U)EFI. When BIOS
is the firmware, beaviour is different from when booting (U)EFI. It is
possible (likely?) that Windows has different behaviour based on the
firmware as well.

>
>>> - Should gpart be silently rewriting the protective MBR entry at all when only asked to make changes
>>> to the GPT?
>>
>> The PMBR is part of GPT metadata described in the UEFI spec. So, I think it can.
>
> Can and should are two different things.

It should. The problem is not with geom_part writing the PMBR, it's
with what we write and why. This loops back to the ol' compatibility
discussions.

> We have a specific gpart command to put a pmbr in place so I think it's
> reasonable to expect other GPT specific commands not to fiddle with the
> pmbr.

I beg to differ. The PMBR is an integral part of the GPT spec, so it
is not at all reasonable to expect the GPT scheme to bank on something
or someone else to create or maintain it.

What about the following: We have the kernel keep track of the firmware
used. On x86 this is either BIOS or UEFI in the common case. Other F/W
implementations like U-Boot, OFW, etc are possible as well, especially
on non-x86 machines.

The geom_part scheme uses this information to determine how to behave
with respect to the PMBR. When booted with BIOS, non-standard stuff is
accepted by virtue of what we've seen in the field. With UEFI we can
start off being anal (read: strictly compliant) and extend out based
on what we run into.

In particular: this way we also don't mess up the EFI/GPT support that
is there on ia64.

Thoughts?

--
Marcel Moolenaar
[hidden email]


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Lawrence Stewart-3
In reply to this post by Andrey V. Elsukov-2
On 08/10/12 00:20, Andrey V. Elsukov wrote:

> On 09.08.2012 16:11, Lawrence Stewart wrote:
>>>> - Should gpart be writing 0x80 (active) in the protective MBR entry?
>>>
>>> AFAIK, this was added because some BIOS could not boot without it.
>>
>> Makes sense if gpart is writing the pmbr out i.e. "gpart bootcode -b
>> /boot/pmbr <geom>", but manipulating an existing pmbr for a GPT specific
>> subcommand smells dodgy to me.
>
> When you create GPT it already has PMBR, because it is part of GPT
> metadata. gpart's `bootcode' subcommand writes *bootcode* to specific
> area in the PMBR.

Right, I had a fundamental misunderstanding about the relationship
between the pmbr and GPT. Thanks to you and Marcel for setting me
straight on this.

>>>>   - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?
>>>
>>> This question you should ask to the Microsoft. :)
>>
>> Perhaps I should rephrase my question as:
>>
>> Is the MS bootloader's behaviour reasonable/unreasonable based on what
>> people know of the relevant specs? My current guess why it behaves like
>> this is that if it sees an MBR partition marked active, it simply
>> assumes another OS is in charge and therefore bails out at the Windows
>> EFI boot stage.
>
> In the EFI system partition might be several boot loaders, and this MS
> bootloader's behaviour seems strange to me.
>
>> Can and should are two different things. I would argue it's a POLA
>> violation at the very least to manipulate the pmbr when the user asked
>> for something else. I certainly started my hunting expecting to find the
>> GPT changing in some subtle way when FreeBSD wrote it out compared to
>> what Windows writes.
>>
>> We have a specific gpart command to put a pmbr in place so I think it's
>> reasonable to expect other GPT specific commands not to fiddle with the
>> pmbr.
>
> Don't confuse bootcode in the PMBR and PMBR.

Despite my misunderstanding about the relationship between the pmbr and
GPT, I still stand by my assertion that gpart is not behaving very well
here, but more on that in my follow up to Marcel.

Cheers,
Lawrence
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Lawrence Stewart-3
In reply to this post by Marcel Moolenaar
[Note: all mail to Marcel is currently bouncing due to a dsbl entry for
xcllnt.net's MX]

On 08/10/12 00:38, Marcel Moolenaar wrote:

>
> On Aug 9, 2012, at 5:11 AM, Lawrence Stewart <[hidden email]> wrote:
>
>> Hi Andrey,
>>
>> On 08/09/12 20:57, Andrey V. Elsukov wrote:
>>> On 09.08.2012 12:57, Lawrence Stewart wrote:
>>>> After identifying the cause of the problem and a workaround (please see the README.txt at the above
>>>> URL for full details and pre/post gpart dumps of the MBR+GPT), I have the following questions:
>>>>
>>>> - Should gpart be writing 0x80 (active) in the protective MBR entry?
>>>
>>> AFAIK, this was added because some BIOS could not boot without it.
>>
>> Makes sense if gpart is writing the pmbr out i.e. "gpart bootcode -b
>> /boot/pmbr <geom>", but manipulating an existing pmbr for a GPT specific
>> subcommand smells dodgy to me.
>
> Agreed. The original design of gpart was such that it could preserve
> what it needed and only limit changes to what it was asked to do.
>
> For the GPT scheme this meant that it would simply read the entire
> PMBR, keep it in memory and write it back when updates are made.
>
> etc...

That sounds like reasonable (and better) behaviour to me, but modulo
Andrey's comments about some BIOS-based systems not booting without the
pmbr partition being set to active, switching to this behaviour seems as
though it may cause issues.

>>>>  - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?
>>>
>>> This question you should ask to the Microsoft. :)
>>
>> Perhaps I should rephrase my question as:
>>
>> Is the MS bootloader's behaviour reasonable/unreasonable based on what
>> people know of the relevant specs? My current guess why it behaves like
>> this is that if it sees an MBR partition marked active, it simply
>> assumes another OS is in charge and therefore bails out at the Windows
>> EFI boot stage.
>
> I think the key distinction may be between BIOS and (U)EFI. When BIOS
> is the firmware, beaviour is different from when booting (U)EFI. It is
> possible (likely?) that Windows has different behaviour based on the
> firmware as well.

On the HP system I'm seeing this on, it tries EFI boot sources first,
then falls back to BIOS boot sources second.  As a result of installing
Win 7 from the DVD's EFI bootcode, which in turn sets up GPT and
installs the Win 7 x64 EFI boot loader, Win 7 will only boot from the
EFI boot loader on this system.

After the pmbr entry gets the 0x80 active flag set by gpart, all
subsequent reboots fall through from the EFI boot sources to the BIOS
boot sources i.e. there is no way with this set up that Win is
attempting to boot when the firmware switches to BIOS, as the pmbr has
no boot code in it.

Either the Win 7 EFI bootcode is being run and making a conscious choice
to bail, or the HP EFI firmware is seeing the 0x80 in the pmbr and
skipping running the Win 7 EFI bootcode. Not sure if there's a way I can
tell which one is the case?

>>>> - Should gpart be silently rewriting the protective MBR entry at all when only asked to make changes
>>>> to the GPT?
>>>
>>> The PMBR is part of GPT metadata described in the UEFI spec. So, I think it can.
>>
>> Can and should are two different things.
>
> It should. The problem is not with geom_part writing the PMBR, it's
> with what we write and why. This loops back to the ol' compatibility
> discussions.

Right, I didn't understand that the pmbr is actually part of the GPT
metadata and therefore should always be written to disk as part of any
GPT related gpart command.

>> We have a specific gpart command to put a pmbr in place so I think it's
>> reasonable to expect other GPT specific commands not to fiddle with the
>> pmbr.
>
> I beg to differ. The PMBR is an integral part of the GPT spec, so it
> is not at all reasonable to expect the GPT scheme to bank on something
> or someone else to create or maintain it.
>
> What about the following: We have the kernel keep track of the firmware
> used. On x86 this is either BIOS or UEFI in the common case. Other F/W
> implementations like U-Boot, OFW, etc are possible as well, especially
> on non-x86 machines.
>
> The geom_part scheme uses this information to determine how to behave
> with respect to the PMBR. When booted with BIOS, non-standard stuff is
> accepted by virtue of what we've seen in the field. With UEFI we can
> start off being anal (read: strictly compliant) and extend out based
> on what we run into.
>
> In particular: this way we also don't mess up the EFI/GPT support that
> is there on ia64.
>
> Thoughts?

I'm not very fluent in all this so I won't answer your question
directly, but rather walk through a scenario and hopefully you can
comment on how your proposal works in this case...

Taking my desired HP configuration as the example:

- Win 7 installed as an EFI boot source

- FreeBSD doesn't have EFI boot support, so it has to be installed to
boot via pmbr bootcode + gpt(zfs)boot in a freebsd-boot GPT partition

- In the HP's firmware config, I choose whether to try boot from EFI or
"legacy" (BIOS) sources first. Currently I try from EFI first.

- In this arrangement, the firmware starts in EFI mode and will always
boot Win 7 as it's the only bootable EFI payload installed.

- Using the F9 key on boot, I get a menu to choose the boot source, and
with FreeBSD installed to boot via pmbr bootcode + gpt(zfs)boot, the
only way to get FreeBSD to start is to select "Legacy HDD" as the boot
source, which switches firmware to BIOS and boots from the bootcode in
the pmbr, which in turn executes gpt(zfs)boot from the freebsd-boot GPT
partition.


As I understand things, the above scenario ensures FreeBSD always thinks
the firmware is BIOS even though an EFI bootloader is installed and
functional. Therefore, your proposed tweaks don't handle this case as
gpart will think it's running on a BIOS systems and happily tweak the
pmbr in ways which can (and in this case do) break the EFI booting.

The only way I can see to get smart about this would be to actually look
for the existence of an EFI system partition and look to see if there is
an active bootloader payload in there. Sounds pretty gross to me but I
can't think of a way around this.

This of course all gets greatly simplified when FreeBSD grows EFI boot
support. However in the meantime, I see the above as the only viable
solution to dual boot Win 7 EFI and FreeBSD 9 on the same disk (please
suggest alternatives if I'm missing something obvious).

Cheers,
Lawrence
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Andrey V. Elsukov-2
On 10.08.2012 6:13, Lawrence Stewart wrote:

>> What about the following: We have the kernel keep track of the firmware
>> used. On x86 this is either BIOS or UEFI in the common case. Other F/W
>> implementations like U-Boot, OFW, etc are possible as well, especially
>> on non-x86 machines.
>>
>> The geom_part scheme uses this information to determine how to behave
>> with respect to the PMBR. When booted with BIOS, non-standard stuff is
>> accepted by virtue of what we've seen in the field. With UEFI we can
>> start off being anal (read: strictly compliant) and extend out based
>> on what we run into.
>>
>> In particular: this way we also don't mess up the EFI/GPT support that
>> is there on ia64.
>>
>> Thoughts?
It seems this is not enough. The problem, that Lawrence has, is not
related to BIOS/UEFI. Automatic detection of various standard violation is
handy for our users, but sometimes false positives occur.

To solve all problems it seems we need to introduce several quirks, e.g.:

#define GPT_QUIRK_BOOTCAMP      0x0001  /* boot camp supported */
#define GPT_QUIRK_MSLOADER      0x0002  /* don't set Active flag to the PMBR entry */
#define GPT_QUIRK_IGNOREPMBR    0x0004 /* don't require PMBR entry */

The same quirks should be added to the loader(8).


--
WBR, Andrey V. Elsukov



signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Lawrence Stewart-3
In reply to this post by Lawrence Stewart-3
On 10/08/2012 12:13 PM, Lawrence Stewart wrote:
[snip]

> Taking my desired HP configuration as the example:
>
> - Win 7 installed as an EFI boot source
>
> - FreeBSD doesn't have EFI boot support, so it has to be installed to
> boot via pmbr bootcode + gpt(zfs)boot in a freebsd-boot GPT partition
>
> - In the HP's firmware config, I choose whether to try boot from EFI or
> "legacy" (BIOS) sources first. Currently I try from EFI first.
>
> - In this arrangement, the firmware starts in EFI mode and will always
> boot Win 7 as it's the only bootable EFI payload installed.
>
> - Using the F9 key on boot, I get a menu to choose the boot source, and
> with FreeBSD installed to boot via pmbr bootcode + gpt(zfs)boot, the
> only way to get FreeBSD to start is to select "Legacy HDD" as the boot
> source, which switches firmware to BIOS and boots from the bootcode in
> the pmbr, which in turn executes gpt(zfs)boot from the freebsd-boot GPT
> partition.

I just wanted to confirm for posterity's sake that as of a few hours
ago, the above set up does actually work. I have Win 7 installed using
GPT + EFI boot. I booted into a FreeBSD 9.1 CD live filesystem and used
"gpart -b /boot/pmbr -p /boot/gptzfsboot -i 6 raid/r0" to install first
stage boot code into the pmbr and second stage boot code into my
freebsd-boot GPT partition. I installed a ZFS-based FreeBSD set up into
it's own GPT partition. I then tweaked the pmbr using my dd + vim trick
to unset the active flag.

I can now boot successfully from Win 7 EFI bootloader or, if I select
"Legacy HDD" from my HP's boot menu, it will happily boot my FreeBSD
install from the kernel living in my ZFS root.

It's good to confirm this actually works as I expected it would, but I
guess we need to make some changes in order to address this issue
completely, including all the edge cases.

Cheers,
Lawrence
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gpart rewrites pmbr in a way which breaks Win 7 EFI bootloader

Lawrence Stewart-3
In reply to this post by Andrey V. Elsukov-2
On 10/08/2012 6:31 PM, Andrey V. Elsukov wrote:

> On 10.08.2012 6:13, Lawrence Stewart wrote:
>>> What about the following: We have the kernel keep track of the firmware
>>> used. On x86 this is either BIOS or UEFI in the common case. Other F/W
>>> implementations like U-Boot, OFW, etc are possible as well, especially
>>> on non-x86 machines.
>>>
>>> The geom_part scheme uses this information to determine how to behave
>>> with respect to the PMBR. When booted with BIOS, non-standard stuff is
>>> accepted by virtue of what we've seen in the field. With UEFI we can
>>> start off being anal (read: strictly compliant) and extend out based
>>> on what we run into.
>>>
>>> In particular: this way we also don't mess up the EFI/GPT support that
>>> is there on ia64.
>>>
>>> Thoughts?
>
> It seems this is not enough. The problem, that Lawrence has, is not
> related to BIOS/UEFI. Automatic detection of various standard violation is
> handy for our users, but sometimes false positives occur.
>
> To solve all problems it seems we need to introduce several quirks, e.g.:
>
> #define GPT_QUIRK_BOOTCAMP      0x0001  /* boot camp supported */
> #define GPT_QUIRK_MSLOADER      0x0002  /* don't set Active flag to the PMBR entry */
> #define GPT_QUIRK_IGNOREPMBR    0x0004 /* don't require PMBR entry */
>
> The same quirks should be added to the loader(8).

This sounds like a useful proposal. I will note though that I can't be
totally sure if my issue is caused by the MS EFI loader or my HP EFI
firmware seeing the active flag and failing to boot. My hunch is it's
the MS EFI loader because the HP EFI firmware still shows the MS EFI
payload as a valid boot option and seems to switch to it temporarily
before falling through to legacy BIOS boot. There are no diagnostic
messages or anything shown on screen though so that makes it hard to
know what's going on.

Cheers,
Lawrence
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Loading...