Mailinglist Archive: opensuse (1239 mails)

< Previous Next >
Re: [opensuse] ssytemd and openSUSE
The key thing is, with disks/partitions/filesystems, you get to choose how they are identified (at least you do since the last several years).

Sometimes uuid is the sanest answer for what you need.

Sometimes uuid is the exact opposite of what you need and you really need is (the human settable and arbitrary) volume id.

Sometimes you even really need the plain old device name like sda1.

There IS NO one rightest way for all. Each of those methods has use cases where it makes the most sense, and other use cases where it is entirely broken and unusable. They are all the only possible way, and they are all the absolutely impossible way, each at different times in different situations.

So for disks, you get to choose.

For network devices, naming the devices only after their physical installation and discovery by the kernel seems like a step backwards.

True, as with disks, *sometimes* you will need exactly that. You can still identify disks as /dev/sda1. But there is a pretty big reason why it's the least recommended thing to look at. Because hardware isn't predictable any more. The drive with your filesystem on it might be sda one boot and might be sdd the next boot purely because of things outside the OS's control, like bios settings and whether any other drives are plugged in, where they are plugged in, or maybe the whole drive was cloned to a new machine when the old one failed.

So many years ago they developed the means to find filesystems by their names or uuids wherever they might be, *instead* of finding disk and partitions by "2nd scsi disk, 1st partition"

The same is true for network devices.

Sometimes you care about the hardware type and physical connection most of all.

"My 1st wifi device is my WAN interface. I don't care what it's called, I might have replaced a dead usb nic with a new one and it will have a different mac address and might be from a different manufacturer and use a different chip driver and might be plugged in to a different usb port or pci slot. I might have 2 motherboard built-in gigabit nics that may or may not be enabled in the bios, and may or may not have cables plugged in at any given time, but they are not wi-fi. But it's always true that my 1st wifi device is my wan!"

Sometimes you care about an arbitrarily assigned name and nothing else.

"I have huge complicated firewall rules, and they all refer to "nic0" as the all-important internet-facing interface. I need to be able to rename or alias any interface to "nic0". It might be ethernet one day, it might be wifi another day, it might be a bridge or virtual interface another day. It might have any mac address. I don't need the system to recognize which device I want automatically at boot if something changed, I just need to be able to take any device, and rename it or provide an alias for it, to the name of my choice, so that a bunch of scripts and fierwall tables and other config files can all be made to work by me just changing one thing in one spot."

Sometimes you care about a particular device.

"My wan is on the device with this mac address. Due to bios settings or me moving plugs/slots around, it might show up as the 1st 2nd or 3rd device, but the ethernet cable is plugged in to this device so this mac address is my wan, whatever slot number it happens to be in, or no matter if I plugged in 3 other new nics and the numbers all changed around so what used to be 1 is now 4"

etc etc

You need to be able to choose how you identify things for the same reasons as is already understood to be true for disks.


On 6/19/2013 7:55 AM, Anton Aylward wrote:
Andrey Borzenkov said the following on 06/19/2013 02:22 AM:
Linux is not the only operating system where device names changed from
release to release.

I've had a 12.2 and 12.3 installed on similar hardware (the 800Mhz
pieces of crap out of the Closet of Anxieties that I speak of) One got
eth0 the other eth1 - same hardware, same family of motherboard and
embedded system.

But more to the point: what's magic about "ertyhX' rather than a
descriptive name?

If you are running NetworkManager rather than the command line then
details are hidden from you.

If you are running from the command line you can do what I'm doing to
cope with the fact that what is eth0 - the single ethernet port - on one
machine is eth1 on the other. Heck, even if you are scripting its easy
enough to run grep/sed/awk to pull it out of a query.

If you are debugging, the the names are more useful than a mere "eth0".

There is also the POV that these descriptive device names are really no
different from the use of UUID for disk names. They stay the same
across releases, even across changes in the distribution.

Look at this way. Suppose I have three partitions.
I then use fdisk to split one of them into two partitions.
What happens to the names of the other two?

| a | b | c |


| | | b | c |


| a | | | c |

Oh, and try that with different distributions not just different
releases! If you use UUID the names stay the same; if you use
'partition-based' the /dev/sda2 and /dev/sda3 might (or might not
depending on things you may be unaware of) change.

This is one reason I use LVM! Even if I move a LV to another physical
drive it keeps the same name :-)

I can - and have - taken such drives from one machine to another, booted
them under other distributions and the persistent naming if partitions
based on UUID and LVM naming meant that I had no hassle.

Now you may live in an idealised world where your hardware never fails,
you never upgrade. Maybe you aren't one of the people who are unhappy
with the way Suse is going and want to move to Fedora, Mageia or CentOS.
If you use UUID for your partition naming in /etc/fstab then life will
be much nice because you are using persistent naming.

But you really can't tell what those other distributions will do with
your other devices names. Or the partitions that don't use UUID or LVM.

To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >