How are BIOS drives assigned to /dev/adax

P

Peacekeeper2000

Hi,

I have a NL36 Server that has (with BIOS Mod) 6 on Board SATAs enabled and one PCIe Card with additional 2 SATA ports.

In the BIOS P0-P3 are the HDD's in the cage, while P5 is my boot SSD (P4 is the unused eSATA). The boot sequence is P5,P0,P1,P2,P3,S0,S1 (Sx are the 6th and 7th drive from the additional PCIe card)

Now my trouble:

When I am booting, it starts correct to boot from P5 which is detected. Then it discovers all devices and now the problem starts. In the old configuration, I had no Sx devices and it used /dev/ada4p2 as root filesystem. Now with the Sx devices (or with an external device on P4), the /dev/ada4 seems to be ada6. So FreeBSD is moving this last internal port always to the last adax device. It looks like (I can't check that) S0 is ada0 and S1 becomes ada1.

How can I ensure that P5 is always set up as the same /dev/adax device?

For me taht is a bit starnge as the BIOS is doing the right sequence, during the first Boot screen I can also see that the Drive is assigned as C Drive, but then during teh boot loader the sequenze is just changing. ( Is also a trouble when I try to boot from an USB stick). Is there a file where I could fix the alignment of BIOS drives (Px ports) to ada devices ?

Any help is appriciated
 
I am using GPT with UFS and gJournal. gLabel doesn't work well: it looks like gLabel is confused by the gJournal. I used gpart for my 3TB disk with one partition (2,7TB) as adaxp1. I used this as a provider for the gLabel and then the label as a provider for the gJournal. It mixed up and has overwritten the gJournal from a different disk. So that I disabled the gLabel in as module in the kernel and it worked fine again.

So I will give the "wired" version a try. Anyhow, thanks!
 
Hmm, ok that sounds interesting: I have labeled them also with gpart. How do I use them?

Code: 
# gpart show -pl /dev/ada0
=>        34  5860533101    ada0  GPT  (2.7T)
          34           6          - free -  (3.0k)
          40  5860533088  ada0p1  data0  (2.7T)
  5860533128           7          - free -  (3.5k)

# gpart show -pl /dev/ada1
=>        34  5860533101    ada1  GPT  (2.7T)
          34           6          - free -  (3.0k)
          40  5860533088  ada1p1  data1  (2.7T)
  5860533128           7          - free -  (3.5k)

# gpart show -pl /dev/ada4
=>       34  250069613    ada4  GPT  (119G)
         34          6          - free -  (3.0k)
         40       1024  ada4p1  ssdboot  (512k)
       1064        984          - free -  (492k)
       2048  243269632  ada4p2  ssdroot  (116G)
  243271680    6797960  ada4p3  ssdswap  (3.2G)
  250069640          7          - free -  (3.5k)
 
The labels appear in /dev/gpt/ when the drive is detected. Use those device paths in /etc/fstab or vfs.root.mountfrom in /boot/loader.conf.
 
I just configured /etc/fstab and vfs.root.mountfrom as ssdroot only instead of /dev/gpt/ssdroot. Now I need to build a rescue system as I can't boot anything now. (The keyboard is not providing me a ':' for the manual boot loader so I can't point to the right hfs:/dev/ ... device).

Arrgggh
 
Ok, I managed to get back to my old setup. And I need to say, there is no /dev/gpt directory. When I remember right, this is only available when I have allowed to load glabel with the kernel. In my own kernel, I took this out as it had confused the gJournal.

As you can see in my former post, gpart shows the labels. So the "simple" part should work - but my understanding is, that it only works when you have glabel loaded.

So I think I will now try the wired way.

But thanks, it was a learning again.

Just verified: with [cmd=]#glabel load[/cmd] the directories under /dev are created.
 
The kernel module is what creates the device paths in /dev/gpt (and others, if found). That is needed. But glabel(8) can also be used to create generic labels. GPT labels make those unnecessary.

I think SU+J made gjournal(8) mostly obsolete. But I don't use either one.
 
There are still some problem with soft updates journaling, the most important is UFS snapshots that do not work with soft updates journaling.
 
[Solved]

:e Solved! The hard wired as suggested by @kpa worked best for me. :stud

I think the glabel is not too bad, just not sure whether it is reliable enough. Anyhow this problem is solved and I can now build the backup system. Thank you all for your support!
 
Last edited by a moderator:
GPT labels are very safe and stable to use. Been using them with our big storage servers (24x hard drives in 3 servers, 45x hard drives in jbod multi-enclosure setup), and on all our firewalls.

Getting it to work on an existing system may require using a LiveCD like Frenzy, or mfsBSD, or even the 9.x install CD. that way you can label the partitions, test mount using the /dev/got/labelnames, exit loader.conf/fstab to use the labels, and have an easy-working boot shortly thereafter.
 
I had trouble with gJournal together with GPT labels (aka glabel(8)). To my mind there is a race condition between both kernel modules: it depends whether gLabel is first loaded before gJournal or vice versa. But at that time I was a newbie on FreeBSD. So I agree it also could be me at the end. My strategy was to first use gpart(8) including GPT labels. Then I used gjournal(8) like mentioned in the Handbook. As consumer I used /dev/adaxxx instead of /dev/gpt/labelname. Maybe that was the conflict. At the end I had instead of two equal disks a total different setup per disk, so I disabled glabel and everything worked fine again.
 
GPT labels are not the same thing as glabel(8) generic labels. Please read the man page, but the short version is that GPT labels take no extra space and do not interfere with partitions. I admit to being curious what was expected when labels were created but not used.

Likewise, the kernel module that provides labels must be loaded before labels will be available.
 
You must log in or register to reply here.
Back
Top