misc/43905: fsck_root fails on write protected partition

[bad%bsd.de@localhost]

>Number:         43905
>Category:       misc
>Synopsis:       fsck_root fails spectaculary trying to check a clean FS on a 
>read-only block device
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 25 11:50:00 +0000 2010
>Originator:     Christoph Badura
>Release:        NetBSD 5.99.39
>Organization:
netbsd bozotic software testing labs
>Environment:
        
        
System: NetBSD  5.99.39 NetBSD 5.99.39 (XEN3_DOMU) #0: Fri Sep 24 05:34:52 UTC 
2010  
builds%b6.netbsd.org@localhost:/home/builds/ab/HEAD/i386/201009240000Z-obj/home/builds/ab/HEAD/src/sys/arch/i386/compile/XEN3_DOMU
 i386
Architecture: i386
Machine: i386
>Description:
Boot NetBSD with a root file system on a read-only block device.
I've been using shared root file system images for Xen domU for a few years
in that setup.

With the new fsck_chroot the boot strap aborts as follows:

Starting root file system check:
NO WRITE ACCESS
/dev/rxbd0a: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
Automatic file system check failed; help!
ERROR: ABORTING BOOT (sending SIGTERM to parent)!

Note that the root fs is marked as read-only in fstab and this has worked
for years:
/dev/xbd0a              /               ffs     ro

After exporting the root image as writable to the domU the comedy continues
with:

Starting root file system check:
/dev/rxbd0a: file system is clean; not checking

There's at least two bugs here:

1) fsck aborts because it can't get write access to the block device
even thought he file system is clean and it doesn't actually want to write
to the device anyway.

2) valid fstabs that have been working since at least 3.0 suddenly fail

>How-To-Repeat:

create a NetBSD minimal installation in a vnd backed image.
export that image as read-only to a domU.
boot the domU.

>Fix:
        

>Unformatted: