[Bug 242341] GEOM / GEOM_PART: silent discard MBR modification

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242341

--- Comment #7 from Andrey V. Elsukov <ae at FreeBSD.org> ---
(In reply to Tomasz "CeDeROM" CEDRO from comment #6)

And again, You didn't provided any useful info.

> 1. dd if=/dev/da0 of=/dev/da1 bs=512 count=1 does not copy anything.

Please, use script(1) command if you unable to make a copy from your terminal.
Should be something like this:
# dd if=/dev/da0 of=/dev/da1 count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.001958 secs (261495 bytes/sec)

You can use hexdump(1) command to check the result of your copy, e.g.
# dd if=/dev/da1 count=1 | hexdump -vC

> 2. dd if=/dev/zero of=/dev/da1 bs=512 count=1 zeroes the mbr.

This looks impossible, if first command doesn't work, this also wont work.

> Can you please explain in detail what does it mean exactly "ignores the 
> partition table"? I guess here is the problem.

There is no problem, all described in gpart(8) man page. "Ignores" means that
GEOM_PART class will not create geom object of type MBR and there will no
partitions appears. 

> If the "partition table is ignored", then why it is silently ignored, 
> writes to MBR goes to /dev/null, reads from MBR does not update disk
> layout, while it is possible to write to the rest of the disk?
> Why the whole disk is not locked against writing in a clearly 
> distinguishable manner? Like error return code from DD and error 
> messages in DMESG?

I don't think that something like this happens in reality :)

> So you confirm that the write to MBR was silently discared and the whole
> situation is indeed managed by GEOM_PART. This is exactly the problem I 
> am reporting. Thank you :-)

You still misunderstand how all things work. There are different GEOM objects,
and when MBR is ignored, GEOM_PART discards nothing, since there is no related
GEOM object. This is why I asked to show the output of `gpart show` and `gpart
list` commands.

-- 
You are receiving this mail because:
You are the assignee for the bug.