Ever since the other day, every time I reboot the server (running OpenSuSe 11.4)after any updates, the fstab entry for mounting the 2nd SATA drive and the main OS drive are reversed,,,EG

OS drive (sda) should be in fstab:-

and the 2nd SATA drive should be:-

But every time the server is rebooted, the /dev/disk/by-id drive's ID is reversed to be sdb not sda as it should be, and the mounted dev sdb points to the main drive and not the 2nd drive, I have to manually edit fstab and change /dev/sd?1 and /dev/sd?2 to either a or b depending on what has happened.

How can I force Linux to always use sda for it's primary drive? then I can use sdb for the second drive in fstab

Is that your actual fstab entries? Have you tried using /dev/by-Id for your 2nd drive like the OS?

Have you considered adding a label to your partitions and mounting by label? IT bypasses this problem.
(So does mounting by UUID, but that is terribly ugly!)

Yes it's partially from the current fstab,,, there are more entries, but I only posted what was relevant to the problem.

Hmmmm, labels,,,, do you mean a volume label? If so, how is the second drive mounted just by it's label?

I always thought mounting had to be done using the device located in /dev

michaelk suggested I try mounting using device-by-id, is that better than mounting by label?

I also noticed the symlinks within /dev/disk/by-id change too,,,, EG

Currently the OS drive (primary) ID = ata-ST3100011A_4LH0PWJC which points to ../../sdb (/dev/sdb) which shouldn't,, because the primary drive should be sda and it's ID should point to ../../sda

The second drive's ID = ata-WDC_WD5000AACS-00ZUB0_WD-WCASU3669592 which currently points to ../../sda, as can be seen the symlinks are reversed,,,, the ST drive should be sda, and the WDC should be sdb.

Now, performing a reboot, the primary drive ID symlink changes back to sda, but rebooting again, changes to sdb, the symlinks change with every reboot from sda to sdb and back again and so on, which seems to mess up fstab.

Support for opensuse 11.4 ended on Nov. 5 2012

there should not be "updates" for it
and if you used "evergreen"
that support ended back in July
so there are no evergreen updates ether to install

If you need "evergreen"
please install the current 13.1

Nope, there are many ways to identify file systems in /etc/fstab these days. /dev/sdxy is only one method.

As you have discovered depending on how devices are discovered /dev/sdx may not point to the same drive every boot. Using persistent names solves this problem. The /dev directory is virtual i.e. only exists in memory and created at boot time which is why the links may change.

There are several ways to use a persistent name in /etc/fstab to identify a filesystem:
UUID, By-ID, and file system labels. I'm not aware that one method is better then the other, each should be unique.

nowadays any *nix os should do the job using UUID in fstab , not /dev/sd* ,, using sdX allways gets OS confused
run in terminal .. blkid and should see UUID associated with theis respective /sdX drive

in fstab tune that accordingly ..

example :
insert a usb dribe and run fsdik -l
should see that usb under let's say sdg sg1
insert a second usb drive
should see it as sdh sdh1
now remove first one and run again fdisk -l ,, now sdh become sdg
that confuses OS
instead , using UUID allways new (old drives) remains in the same possition , BUT if running fdisk /dev /sdX just for repartition uuid would be changed , therefore use carefully , in my oppinion best sollution is to write manually an unique value in all drives like making a folder named 1-drive-kinkston-8gb-purchase-moment , and run a root script that would mount all new drives and search for that folder ,, afterwards alter fstab as searching gets that value.. it is ugly but it works

Sometimes my english sounds as bad as it is , more infos can be achieved here as requested


my server uses 2 kinkston usb flash drives just for boot but cloned ones , and from there it runs raid mirror mdadm drives , in this way i can rebooot either one boot drive is dammaged , either one raid (2 TB ) [UU] is dammaged.
mixing /dev/sdx would compromising server at once if not carefull.

"Hmmmm, labels,,,, do you mean a volume label? If so, how is the second drive mounted just by it's label?"

you need to try google, it is a wondeful search tool.
In this case the man page for Tune2fs may help. You can Label partitions and mount them by label. It is easy, far more readable than using UUID, and avlids all kinds of troubles. What device it gets mapped to becomes irrelevent, as mount searches all detected devices for the one with the proper label to do the mount.

You may want to read something like this: http://www.cyberciti.biz/faq/rhel-ce...rtition-label/
found using google, or this: https://wiki.archlinux.org/index.php/fstab for greater detail and links to related documents in the wonderful Arch community.

Easiest to follow, a great first HOW-TO for reference is at http://www.nslu2-linux.org/wiki/HowTo/MountDisksByLabel
and the classic Debian style (my second love) at https://wiki.debian.org/fstab

Reading any ONE of these shuld answer that question, as well as several you had not yet thought to ask.