Bug 124973 - [gjournal] [patch] boot order affects geom_journal consumers selection
Summary: [gjournal] [patch] boot order affects geom_journal consumers selection
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.0-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2008-06-25 07:20 UTC by Alexei Volkov
Modified: 2018-01-03 05:13 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alexei Volkov 2008-06-25 07:20:00 UTC
The system has hardware RAID controller:

atapci0@pci0:1:2:0:     class=0x010485 card=0x341b8086 chip=0x7275105a rev=0x01 hdr=0x00
    vendor     = 'Promise Technology Inc'
    device     = 'PDC20277 FastTrak TX/SBFastTrak133 Lite EIDE Controller'
    class      = mass storage
    subclass   = RAID

This controller configured as
# atacontrol status ar0
ar0: ATA RAID1 status: READY
   0 ad4  ONLINE
   1 ad6  ONLINE

ar0 labeled as 
# ls -l /dev/ar0*
crw-r-----  1 root  operator    0,  83 Jun 25 09:22 /dev/ar0
crw-r-----  1 root  operator    0,  86 Jun 25 09:22 /dev/ar0s1
crw-r-----  1 root  operator    0,  99 Jun 25 13:22 /dev/ar0s1a
crw-r-----  1 root  operator    0, 100 Jun 25 09:22 /dev/ar0s1b
crw-r-----  1 root  operator    0, 101 Jun 25 09:22 /dev/ar0s1c
crw-r-----  1 root  operator    0, 102 Jun 25 09:22 /dev/ar0s1d
crw-r-----  1 root  operator    0, 103 Jun 25 09:22 /dev/ar0s1e
crw-r-----  1 root  operator    0, 104 Jun 25 09:22 /dev/ar0s1f

And gjournal provider was configured with
# gjournal label /dev/ar0s1d
# gjournal label /dev/ar0s1e
# gjournal label /dev/ar0s1f

with subsequent
#newfs -J /dev/ar0s1d.journal
#newfs -J /dev/ar0s1e.journal
#newfs -J /dev/ar0s1f.journal

and the /boot/loader.conf has the line

/etc/fstab as followed:

/dev/ar0s1a             /               ufs     rw              1       1
/dev/ar0s1b             none            swap    sw              0       0
/dev/ar0s1d.journal     /var            ufs     rw              2       2
/dev/ar0s1e.journal     /tmp            ufs     rw              2       2
/dev/ar0s1f.journal     /usr            ufs     rw              2       2
/dev/acd0               /cdrom          cd9660  ro,noauto       0       0

rebooting is failed due gjournal starts using ad4* as consumers instead ar0* devices.

If the geom_journal.ko module loaded not via /boot/loader.conf but from rc.d scripts it consumes right ar0* devices.


Use special /etc/rc.d/gjournal script instead /boot/loader.conf line.

# /etc/rc.d/gjournal 

# PROVIDE: gjournal
# REQUIRE: localswap
# BEFORE: fsck mountcritlocal
# KEYWORD: nojail

. /etc/rc.subr


        echo  'Starting gjournal providers.'
        /sbin/gjournal load

load_rc_config $name
run_rc_command "$1"
How-To-Repeat: Use livefs installation. Manually label file systems as described in full description, install the system and reboot.
Comment 1 Gavin Atkinson freebsd_committer freebsd_triage 2008-06-25 14:08:18 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-geom

Over to maintainer(s).  Although there is a patch in the PR, I think 
it is more of a workaround than the actual fix, so passing it to 
-geom rather than -rc.
Comment 2 Aragon Gouveia 2008-10-25 18:33:29 UTC
Hi there,

I just hit my head against this tonight on 7.1-BETA2.  My filesystems were
using ad0s1a, etc. before enabling gjournal.  After creating a provider and
enabling gjournal in loader.conf, all the filesystem device nodes got
renamed to ad0a, etc.

I'm not sure if this has been fixed since Alexei filed it or if what I'm
describing is that fix, but all I did to fix things for me was to recreate
my gjournal provider with the '-h' argument:

gjournal label -h /dev/ad0s1g

And now everything behaves when gjournal is enabled in loader.conf. :)

Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:28 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped