gjournal + WARNING: R/W mount of / denied. Filesystem not clean - run fsck.

[Niki Denev]

Hello,

I have the following problem when using gjournal for the root filesystem 
on my laptop (Sony VAIO PCG-U3)
If there is a unclean shutdown (hard poweroff/ kernel panic) on the next 
boot the machine starts to load normally,
i have messages as :

        GEOM_JOURNAL: Journal ad0s1a consistent.
        Trying to mount root from ufs:/dev/ad0s1a.journal
        WARNING: / was not properly dismounted

Then the system continues with executing fsck  in preen mode (fsck -p),
which reports :
        /dev/ad0s1a.journal: FILESYSTEM CLEAN; SKIPPING CHECKS
and fsck returns with zero, but after this when a read/write mount is 
tried the
system barfs this :

        WARNING: R/W mount of / denied. Filesystem not clean - run fsck.
        mount:  : Operation not permitted

and i'm dropped in the shell.
Now if i try fsck -p it gives me that the filesystem is clean as above, 
it still can't be mounted though.
If i try "mount /" i get :
       WARNING: R/W mount of / denied. Filesystem not clean - run fsck.
       mount: /dev/ad0s1a.journal : Operation not permitted.

Note the difference, when executed from the init scripts or by hand from 
the shell (the device name is omitted in the first)

Now i can run "fsck /" which goes pretty fast on my 15G drive, reporting 
no problems but going thru all the phases (1,2,3,4,5),
and after this the filesystem is apparently marked as clean, and if i 
CTRL-D the boot process continues normaly.

So, my question is: Is this normal behaviour? Isn't fsck in preen mode 
supposed to mark the filesystem clean if it is journaled and
the preen does not find problems? I think fsck should be handled 
automaticaly with journaled filesystems so no user intervention is required.

My system is running the -current snapshot from 200705 
(7.0-CURRENT-200705), and i'll try to update now to see if the problem 
still exists, but the
machine is pretty slow, so this would take a while, and i haven't 
noticed changes in /etc/rc.d/root and /etc/rc.d/fsck that may have fixed 
this.

P.S.: Excuse me if this is already fixed.