Here is a report of a repeatable unrecoverable problem.
11.0 release amd64 r306420
# dd if=/dev/zero of=/dev/ada0s1 seek=2048 count=1 bs=1m
1+0 records in
1+0 records out
1048576 bytes transferred
# <reboot: Device not configured>
The same goes for any other uncached access to the
filesystem in ada0s1a (Note: / is on s1a, dd occurs past
that), ie all first use of commands that read disk.
wherein that read does not trigger the fault,
only the write of the string does.
All the layout offsets and sizes add up sequentially, no overlap,
the relavant portions are below, disk is <~= 250G,
gpart, fdisk, boot0cfg, bsdlabel all concur without error,
and were done with the live release tool versions.
What am I overlooking, or is this kernel behaviour a bug?
On Sun, Oct 8, 2017 at 3:05 PM, Eugene Grosbein <[hidden email]> wrote:
> The problem is known and already fixed. You should upgrade.
Was there a ticket and revision number to look into that?
Because this issue is still present in 11.1 and r324300.
When booting either from usb...
- Mounting ada0s1a read-only on /mnt, and giving the same
dd, still produces "Device not configured" upon an ls -R /mnt.
A umount clears that condition. Repeat.
- After triggering it read-only, but not unmounting to clear
it, a mount -uw panics the box.
- Giving the dd in unmounted state appears to be ok.
debugflags=16, manpage say 'allow[s]...write[ing]...sectors... to
mounted [read-write?] disk [the aforesaid mounted partition on it?]".
The manpage is unclear there. Also geom(8) does not display
that actual rank status info, ie: "Rank 1 provider". IMO, 16 should
"allow [all] foot shooting".
So mode 16 appears to be broken because the dd is denied,
even though the dd is NOT writing to the read-write mounted
s1a partition itself (which should be allowed even if it were),
but is seeking over past it.
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[hidden email]"
10.10.2017 15:06, grarpamp пишет:
> On Sun, Oct 8, 2017 at 3:05 PM, Eugene Grosbein <[hidden email]> wrote:
>> The problem is known and already fixed. You should upgrade.
> Was there a ticket and revision number to look into that?
> Because this issue is still present in 11.1 and r324300.