# Should I expect /dev/da0 and /dev/da1 to 'swap' between 13.0 RELEASE and 13.1-RELEASE



## EasyTarget (Jun 6, 2022)

I'm in the process of upgrading to 13.1 from 13.0, and having some disk issues. I'm just trying to gather some info at this point for some issues I am having.

I have two external Western Digital Passport USB 3 disks attached to my home server  (system specs), one holds my home folders, the other is a media/data store. WIth 13.0 (and all 12.x releases before this) these appear as _/dev/da0_ and _/dev/da1_ respectively.

When I boot with the 13.1 kernel the devices are swapped, the device with my _/home_ partition is now _/dev/da1_ and _/data_ is on _/dev/da0_.

If I revert to the 13.0 kernel the order reverts as well. I've swapped back and forth between the two kernels and verified this behaviour (world is at 13.1, but the 13.0 kernel boots ok with this). If I boot repeatedly into the same kernel the order remains constant, eg the order is not 'flip-flopping' between boots, it's ted to the kernel version. A full power cycle has no effect either.

Should I expect this? Should I be worried by it? or should I just adjust paths in _/etc/fstab_ and accept it as 'just one of those things' ?

Hoping the collective wisdom here can provide some insights on what might have changed, my expectation and experience is that the order of these devices should remain absolutely stable, even between major or minor releases.

I'm seeing some other, more serious, problems with these disks.. but I'm still gathering info about this and I'd like to address the above first, so that I can be clearer with the mount errors I subsequently see with 13.1 (but not with 13.0).


----------



## Phishfry (Jun 6, 2022)

EasyTarget said:


> Should I expect this?


Yes. An easy fix is to use disk labels. Then you put disk label in /etc/fstab.









						FreeBSD 101 : Disk labels, GEOM, GPT, UFS
					






					www.ithands-on.com


----------



## diizzy (Jun 6, 2022)

This mainly comes down to how your controllers / channels are enumerated, you can hardset it but I would highly recommend you to at least use GPT labels (some prefer BSD ones).
See https://www.freebsd.org/cgi/man.cgi?query=scbus&sektion=4&n=1

Example:
hint.scbus.0.at="ahcich4"
hint.ada.0.at="scbus0"
hint.scbus.1.at="ahcich5"
hint.ada.1.at="scbus1"


----------



## EasyTarget (Jun 6, 2022)

diizzy , Phishfry . Thankyou, I know FreeBSD supports disk labels, and it's something I should start using (as I do on linux boxes) but since this is a server under a cupboard I am never hotplugging or re-arranging the drives and it has not been necessary so far.

I'm having other issues with these drives / filesystems, I'll pursue those myself as far as I can and gather some proper logs before coming back here. At the moment I'm just trying to scope things out, wondering how much the _/dev/da_ Direct Access driver has changed with this release.

A big thanks for the links and example. I'll get the system booting with 13.0 and labels, and pursue remaining problems in a new thread.


----------



## mer (Jun 6, 2022)

USB devices have a non zero probability of enumerating differently every reboot.  Most of the times they won't but if something on a chain is a little slower responding, they may.  Timing differences between releases could expose it.

Internal devices like ad* devices typically have a "closer to zero" probability (they almost always are the same).

Disklabels are the answer, but you need to be aware of the concept of "geom withering".  Basically when you label disks, you have a number of "/dev/*" entries that are created.  Some automatically, some because of the label.  This happens during boot, GEOM does this.
All possible references exist until something is mounted.  How it is mounted is important.  
Lets say you have /dev/ada0, with 1 partition and you you gpart to label the partition as "mypart1".  It would also have "GPT UUID" labels and I think there is another type of label.  That means you can mount the partition by referencing:
/dev/ada0p1
/dev/gpt/mypart1
/dev/gptid/somereallyweirdhexstring

If you do "mount /dev/ada0p1 /blah", the /dev/gpt and /dev/gptid entries go away until you unmount the partition.
If you "mount /dev/gpt/mypart1 /blah" the others would go away.

That's withering.

To transition, set the sysctls to allow the different types, reboot, apply labels, then unmount a partition, remount it using the label.
Fun stuff


----------



## _al (Jun 6, 2022)

I ran into a similar problem on Linux - Linux shuffles partition's names.
After every boot, I run a simple perl-script that creates sh-script which is used to mount.
(This perl-script is not ideal, and I purposely wrote it in a primitive form)

```
use v5.14;

my %h=(
# partition label   => the disk on which it is located
"esmero"    =>    "WDC_WD4003FRYZ-01F0DB0",
"luego"        =>    "WDC_WD4003FRYZ-01F0DB0",
"quid"        =>    "WDC_WD4002FYYZ-01B7CB1",
"fresco"    =>    "WDC_WD4002FYYZ-01B7CB1",
"abrigo"    =>     "WDC_WD4000FYYZ-01UL1B3",
"nuevo"        =>     "WDC_WD4000FYYZ-01UL1B3",
"merced"    =>     "WDC_WD4000FYYZ-01UL1B3",
"mirlo"        =>    "WDC_WD4000FYYZ-01UL1B0",
"neat"        =>    "WDC_WD4000FYYZ-01UL1B0",
"perada"    =>    "WDC_WD4002FYYZ-01B7CB0",
"uvero"        =>    "WDC_WD4002FYYZ-01B7CB0"
);

print 'Wait...';

my @disks    =    `lsblk -d -io KNAME,MODEL | grep \'sd\\w\'`;
my @parts    =    `sudo /sbin/parted -l | grep -e \"esmero\" -e \"luego\" -e \"quid\" -e \"fresco\" -e \"abrigo\" -e \"nuevo\" -e \"merced\" -e \"mirlo\" -e \"neat\" -e \"perada\" -e \"uvero\" `;
my @m_all=();
M: for my $name (keys %h){
    for my $disk (@disks){
        my @arr1 = split /\s+/, $disk;
        if ($h{$name} eq $arr1[1]){
            for my $part (@parts){
                my @arr2 = split /\s+/, $part;
                if ($name eq $arr2[6]){
                    push @m_all, 'mount -t ext4 -o rw /dev/'.$arr1[0].$arr2[1].' /'.$name."\n";
                    next M;
                }
            }
        }
    }
}

my @lsdps    =    `ls -l /dev/disk/by-label`;
my @must=();
for my $line (@lsdps){
    if($line=~m{(esmero|luego|quid|fresco|abrigo|nuevo|merced|mirlo|neat|perada|uvero)(.+)(/sd\w+\d+)}){
        push @must, 'mount -t ext4 -o rw /dev'.$3.' /'.$1."\n";
    }
}

@must = sort @must;
@m_all = sort @m_all;

my $ok=1;
if(@must == @m_all){ # compare size
    print "\n", 'mount points: ', $#must+1, "\n";
    for(my $i=0; $i <= $#must; $i++){
        unless($must[$i] eq $m_all[$i]){
            $ok=0;
            last;
        }
        print $must[$i];
    }
} else {
    $ok=0;
}

if ($ok){
    my $f_out='./m_all';
    open F_OUT,'>', $f_out;
    print F_OUT @m_all;
    close(F_OUT);
    chmod 0755, $f_out;
    print "Ok!\n";
} else {
    print "!Ok\n";
}
```

[EDIT] *This script is for Linux. Just as an idea to write a similar one for FreeBSD*


----------



## Alain De Vos (Jun 7, 2022)

If you mount devices from /dev/gpt/mygptname , a renumbering problem will not occure.


----------



## EasyTarget (Jun 17, 2022)

A quick narco-post to wrap this up for anybody stumbling across it in the future.

I've set the system up to use disk labels in /etc/fstab, and this has resolved all the mounting issues.

After a quick read-up here and elsewhere I decided to not go the glabel(8) route as described in the manual (https://docs.freebsd.org/en/books/handbook/geom/#geom-glabel) since it seems a bit out of date, lacking GPT info.

In my /etc/fstab I'm using /dev/ufsid/... for the system root, /usr and /var partitions, which are on the BSD partitioned internal drive. But the two USB disks are GPT partitioned and so I am using /dev/gpt/[data|home|swap](*) to identify them instead. This seems like the best way forward, when I next rebuild the system I'll convert it to GPT throughout.

The good news is that this works beautifully, and has solved the gnarly mount problems that I thought I was seeing, but were really me just getting thoroughly confused about device and partition numbers.

Thanks again everybody above, I do like scripting based solutions but the best route for this machine was to sort the labelling out.

(*) Yep, I put swap on a USB3 external disk instead of the internal SSD, this works really well for my use model.


----------

