Swapping battery => change in device numbers?
-
I had a configured system, about to be sent out to a collocation service.
I decided to swap the systems on-board lithium battery which was already a few years old, given the far off site location of where the system was going to be installed.Of course, the clock etc. would need to be set again, but the system wouldn't boot anymore.
After reopening the device and hooking up a screen and keyboard to the on-board connectors, it turns out, even though there was no change in the hardware/software configuration, the boot device changed it's device name.Things used to boot from /dev/ad8s1a and now the same device was named /dev/ad5s1a
After changing the corresponding lines in /etc/fstab things are booting again, but how do device names change randomly like that?
More importantly, I have a twin device, which will operate locally as the other end of the location, there /etc/fstab still lists /dev/ad8s1a as boot device (and /dev/ad8s1b as swap), which means if these things are also stored in the config file, I can't load one system's config into a what should be a twin device and expect things to function.
So are there any rules as to the assignment of device names and when these assignments change?
-
When you remove the CMOS battery the BIOS looses all it's settings. On the next boot the bios setup tries to load the CMOS settings, fails, and loads a set of default settings instead. It seems the the default settings (possibly the failsafe settings) for your board have a number of SATA ports, or a whole disk controller, disabled. Hence when pfSense boots it sees fewer ports and numbers them differently.
A solution to this, as I understand it, would be to use ufs labels instead of the older drive labelling scheme. That's not included in 2.1.X and I'm not sure if it's made into 2.2. There is a script to convert the drives though. YMMV!
https://forum.pfsense.org/index.php?topic=63656.msg352181#msg352181Steve
-
Thanks for your answer. What you write makes sense. What puzzles me, however, that since I had to go into the BIOS setup page after swapping the battery anyway (to make sure other options are the way I want them to be), I thought that I had enabled all the interfaces anyway.
Could it be, that when I initially installed pfSense I had a USB DVD drive hooked up with an install CD in it, and possibly also some USB thumb drive attached, that these USB devices had an effect on device numbers that the BIOS/OS somehow remembered even though they were later removed, and now that they weren't attached when I swapped the battery, it resulted in different device number assignments?
Anyway, I wish I knew about this script before sending out the box, because if it should fail I might saw off the branch I'm sitting on. Still, going forward that's something to keep in mind, because if a few years down the road someone needs to swap the battery in the system, I would like the idea that it's bootable afterwards ;)
Thanks for the hint with that script.
-
I wouldn't exepect USB devices to make a difference since they are usually given a different label, cd#.. or da#…
It would be interesting to find out if that is the cause on your box. Also interesting to note that something as simple as the battery going flat can completely scupper a box. I guess that's why many custom boxes have custom default settings.Steve
-
I in the mean time switched to using ufsids for more peace of mind.
However, human readable labels are nicer.
So I tried to stick either of these two lines in near the start of /etc/rc
/sbin/glabel label rootfs /dev/ada0s1a
/sbin/tunefs -L root /dev/ada0s1a
but neither seems to take (I used two different labels, so I'd know which command was able to create the label), but even after a reboot no label visible.
Is there a way to do that with a system like that, because I can't get physical access to at least one of the units, so traditional single user mode with keyboard and screen isn't an option.
Also are ufsids, glabels and tunefs labels mutually exclusive, or could one file system have all three? The man pages are as usual useful only reminding people who know everything already of what they temporarily forgot ;) -
Usually what causes your drive to change in that circumstance is the SATA ACHI mode setting in the BIOS changing.
-
The man pages are as usual useful only reminding people who know everything already of what they temporarily forgot ;)
Ha! Very true. Classic engineering fail, can't write documentation that can be understood by people who don't know it already. Pretty sure I'm guilty of that on many occasions.
I can't help you there since I never knew either. ::)Steve
-
@cmb:
Usually what causes your drive to change in that circumstance is the SATA ACHI mode setting in the BIOS changing.
Could be that I missed something there :(
Would that explain why on that box even after loading the ahci module, I still get a device /dev/adXXX instead of /dev/adaXXX?
If so, since TRIM was enabled with tunefs, does it mean TRIM isn't actually working, because it requires ACHI? Or does it just require that module to be loaded, regardless of the mode the interface is operating in? (tunefs -p shows TRIM to be enabled if that means anything…) -
Hmm, yes, I'm pretty sure you need AHCI for trim to work correctly. :-\
Steve