In message alpine.gso.1.10.1110242118020@multics.mit.edu, Benjamin Kaduk
writes:
On Mon, 24 Oct 2011, Andrey V. Elsukov wrote:
This is stale message. boot0cfg might work without this.
On a *mounted* disk? Surely that qualifies as an open for the purposes
of the check.
The way this used
On 25.10.2011 10:08, Poul-Henning Kamp wrote:
The way this used to work before gpart, is that boot0cfg would send
a GEOM ctl-message to the MBR-geom asking Would you please write this
boot code ?
Since the MBR-geom was the owner of the whole disk, and the one
who had it open for writing, it
In message 4ea654f6.1060...@yandex.ru, Andrey V. Elsukov writes:
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig1B092FDF9A756BE78BC74C01
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
On 25.10.2011 10:08, Poul-Henning Kamp wrote:
On Mon, 24 Oct 2011, Andrey V. Elsukov wrote:
On 24.10.2011 1:54, Arnaud Lacombe wrote:
NOTE
Protection mechanisms in the geom(4) subsystem might prevent boot0cfg
from being able to update the MBR on a mounted disk. Instructions for
temporarily disabling these protection mechanisms can be
On 25.10.2011 5:18, Benjamin Kaduk wrote:
to allow writing to the MBR, and restore it to 0 afterwards.
This is stale message. boot0cfg might work without this.
On a *mounted* disk? Surely that qualifies as an open for the purposes of
the check.
Yes. boot0cfg uses GEOM_PART' control
Hi,
2011/10/7 Andrey V. Elsukov bu7c...@yandex.ru:
On 07.10.2011 23:41, Glen Barber wrote:
In my experience, without kern.geom.debugflags=16, the MBR will not be
written to the memstick, leaving you with what would effectively be a
coaster in the not-so-distant past.
The problem is that
On 24.10.2011 1:54, Arnaud Lacombe wrote:
NOTE
Protection mechanisms in the geom(4) subsystem might prevent boot0cfg
from being able to update the MBR on a mounted disk. Instructions for
temporarily disabling these protection mechanisms can be found in the
geom(4) manpage. Specifically,
In message 1644928028.20111008143...@serebryakov.spb.ru, Lev Serebryakov writ
es:
Hello, Poul-Henning.
You wrote 8 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 14:07:29:
It seems, that GPT will be incompatible with any pure-software
mirror or mirror-like RAID.
Unless you do what other implementations
Hello, Poul-Henning.
You wrote 9 октября 2011 г., 11:37:21:
So, every other GEOM class should have special knowledge about GPT?
It doesn't look like topology-agnostic GEOM way :)
That's mostly because GPT by design does not try to play nice.
I understand that... See my proposal in other
In message CACqU3MVgVUxe+Mtaf9wq6oz5=PZAq=sx-ihyqh1gyjd3pxm...@mail.gmail.com
, Arnaud Lacombe writes:
If you expose a setting, you cannot rely on a user not to use it even
if you told him not to. As long as this is exposed and usable, it will
be used, even more when it was documented.
This is
In message alpine.bsf.2.00.1110071734140.4...@wonkity.com, Warren Block write
s:
Since we're talking about this, could you review the usage in the
gmirror section of the Handbook GEOM chapter:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html
Seems like that is a
Hello, Poul-Henning.
You wrote 8 октября 2011 г., 12:18:54:
gmirror and this procedure has several problems:
1. It steals the last sector on the disk. If that sector contained data
you lost them, with no notice. Most often it will not, particularly
on a freshly installed system, but
In message 338510238.20111008140...@serebryakov.spb.ru, Lev Serebryakov write
s:
It seems, that GPT will be incompatible with any pure-software
mirror or mirror-like RAID.
Unless you do what other implementations have done: Play nice with
GPT and store your metadata in a GPT partition.
--
Hello, Poul-Henning.
You wrote 8 октября 2011 г., 14:07:29:
It seems, that GPT will be incompatible with any pure-software
mirror or mirror-like RAID.
Unless you do what other implementations have done: Play nice with
GPT and store your metadata in a GPT partition.
So, every other GEOM
Hi,
On Sat, Oct 8, 2011 at 4:11 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message
CACqU3MVgVUxe+Mtaf9wq6oz5=PZAq=sx-ihyqh1gyjd3pxm...@mail.gmail.com
, Arnaud Lacombe writes:
If you expose a setting, you cannot rely on a user not to use it even
if you told him not to. As long as
In message cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com
, Arnaud Lacombe writes:
User do not care to understand the meaning of an option, you leave a
hole somewhere, it will be used. I'm not even speaking about security
issue here...
There is a big difference between having
Hi,
On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message
cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com
, Arnaud Lacombe writes:
User do not care to understand the meaning of an option, you leave a
hole somewhere, it will be used. I'm
On Sat, Oct 8, 2011 at 11:08 AM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk
wrote:
In message
cacqu3muqq6xqtfxhve1jtu4aey3kcdktcprd7ojq3ourdc8...@mail.gmail.com
, Arnaud Lacombe writes:
User do not care to
Hi,
On Sat, Oct 8, 2011 at 2:11 PM, Garrett Cooper yaneg...@gmail.com wrote:
On Sat, Oct 8, 2011 at 11:08 AM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Sat, Oct 8, 2011 at 12:52 PM, Poul-Henning Kamp p...@phk.freebsd.dk
wrote:
In message
In message CACqU3MUT36PVxP2hMuizTxYLcuTkBQ_fOfrELit=7ueq-hv...@mail.gmail.com
, Arnaud Lacombe writes:
Arnaud,
Are we done here ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
Hi,
On Sat, Oct 8, 2011 at 3:10 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message
CACqU3MUT36PVxP2hMuizTxYLcuTkBQ_fOfrELit=7ueq-hv...@mail.gmail.com
, Arnaud Lacombe writes:
Arnaud,
Are we done here ?
'your call.
A.
___
On Fri, Oct 7, 2011 at 10:42 AM, Benjamin Kaduk ka...@mit.edu wrote:
Dear all,
I feel like this has come up before, but a quick search didn't reveal
anything terribly recent, at least.
The new installation chapter of the handbook for 9.0 (that Warren and Glen
and Garrett and Gavin and more
On Fri, 7 Oct 2011, Garrett Cooper wrote:
On Fri, Oct 7, 2011 at 10:42 AM, Benjamin Kaduk ka...@mit.edu wrote:
Dear all,
I feel like this has come up before, but a quick search didn't reveal
anything terribly recent, at least.
The new installation chapter of the handbook for 9.0 (that Warren
In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin Kaduk
writes:
Now, an ordinary user who is
doing this for the first time might ask, why do I need to do something
with 'debugflags' in order to make a USB stick?
Which is the exactly right question to ask.
The procedure
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin Kaduk
writes:
Now, an ordinary user who is
doing this for the first time might ask, why do I need to do something
with 'debugflags' in order to make a USB stick?
Which is the
Hi,
On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wbl...@wonkity.com wrote:
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin
Kaduk
writes:
Now, an ordinary user who is
doing this for the first time might ask, why do I need
On Fri, 7 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wbl...@wonkity.com wrote:
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin
Kaduk
writes:
Now, an ordinary user who is
doing this
On Fri, 7 Oct 2011, Warren Block wrote:
On Fri, 7 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wbl...@wonkity.com wrote:
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message alpine.gso.1.10.1110071341430@multics.mit.edu, Benjamin
Kaduk
writes:
In message alpine.bsf.2.00.1110071236270.2...@wonkity.com, Warren Block write
s:
Which is the exactly right question to ask.
The procedure documented is clearly flawed.
Well, yes. The goal is to unprotect the device, regardless of what may
already be on it. Then the user can overwrite it
On Fri, Oct 7, 2011 at 12:03 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message alpine.bsf.2.00.1110071236270.2...@wonkity.com, Warren Block
write
s:
Which is the exactly right question to ask.
The procedure documented is clearly flawed.
Well, yes. The goal is to unprotect the
In message CAGH67wQk0jR+uk0oFO7Ye001vd-0UgcY-bf+84a8=9wtlhg...@mail.gmail.com
, Garrett Cooper writes:
My guess is that GEOM isn't letting go of the GPT table and you have
multiple partitions in the GPT table and you're not destroying them
hierarchically in a proper manner.. but again, that's
On 07.10.2011 22:53, Warren Block wrote:
The current documentation is
sysctl kern.geom.debugflags=16
dd if=memstick.img of=/dev/whatever0 bs=64k
Did you try just write your image without debugflags settings?
When /dev/whatever0 is not used nothing should prevent you write
your image.
--
Hi,
On 10/7/11 3:18 PM, Poul-Henning Kamp wrote:
My guess is that GEOM isn't letting go of the GPT table and you have
multiple partitions in the GPT table and you're not destroying them
hierarchically in a proper manner.. but again, that's just a guess
based on hazy recollection.
If none
On 07.10.2011 23:41, Glen Barber wrote:
In my experience, without kern.geom.debugflags=16, the MBR will not be
written to the memstick, leaving you with what would effectively be a
coaster in the not-so-distant past.
The problem is that this bad suggestion is everywhere in the Internet.
And
On Fri, 7 Oct 2011, Glen Barber wrote:
Hi,
On 10/7/11 3:18 PM, Poul-Henning Kamp wrote:
My guess is that GEOM isn't letting go of the GPT table and you have
multiple partitions in the GPT table and you're not destroying them
hierarchically in a proper manner.. but again, that's just a guess
On 10/7/11 4:27 PM, Warren Block wrote:
In my experience, without kern.geom.debugflags=16, the MBR will not be
written to the memstick, leaving you with what would effectively be a
coaster in the not-so-distant past.
Tried it just now with the 9.0-BETA3 memstick image.
[...]
Followed
Hi,
On Fri, Oct 7, 2011 at 4:27 PM, Warren Block wbl...@wonkity.com wrote:
On Fri, 7 Oct 2011, Glen Barber wrote:
Hi,
On 10/7/11 3:18 PM, Poul-Henning Kamp wrote:
My guess is that GEOM isn't letting go of the GPT table and you have
multiple partitions in the GPT table and you're not
On Fri, 7 Oct 2011, Glen Barber wrote:
On 10/7/11 4:27 PM, Warren Block wrote:
In my experience, without kern.geom.debugflags=16, the MBR will not be
written to the memstick, leaving you with what would effectively be a
coaster in the not-so-distant past.
Tried it just now with the 9.0-BETA3
In message alpine.bsf.2.00.1110071352210.2...@wonkity.com, Warren Block write
s:
# mount /dev/da0p2 /mnt
# dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k
dd: /dev/da0: Operation not permitted
# sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 - 16
# dd
Hi,
On Fri, Oct 7, 2011 at 5:10 PM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message alpine.bsf.2.00.1110071352210.2...@wonkity.com, Warren Block
write
s:
# mount /dev/da0p2 /mnt
# dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k
dd: /dev/da0: Operation not permitted
On 10/7/11 5:10 PM, Warren Block wrote:
Me not being one that uses hald or devd for USB, I'm certain the device
was not mounted when writing the memstick image. In the former case of
your test, is the USB stick bootable?
I cleared the first 34 blocks and wrote it again to make sure, but
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message alpine.bsf.2.00.1110071352210.2...@wonkity.com, Warren Block
writes:
Followed by removing the memory stick without unmounting it to avoid
overwriting part of the image. No obvious problems, but no, it's not
polite. (I'm thinking
On Sat, 8 Oct 2011, Andrey V. Elsukov wrote:
On 07.10.2011 23:41, Glen Barber wrote:
In my experience, without kern.geom.debugflags=16, the MBR will not be
written to the memstick, leaving you with what would effectively be a
coaster in the not-so-distant past.
The problem is that this bad
43 matches
Mail list logo
