[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
I consider those unpredictable "predictable interface names" as a very very stupid idea! I don't want my interface eth0 be renamed into something else! Please read this post here: https://lists.dyne.org/lurker/message/20160111.171633.d8fa4287.pl.html Now as the roll out of Ubuntu 16.04 starts in the industry the new default setting of net.ifnames=1 will do much harm to the Linux community. I personally vote for putting net.ifnames=0 into the default kernel command line to avoid alienating thousands of otherwise happy Linux users! Please support my case. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Confirmed Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for "PCI slot", that the second p stands for "port number", and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: ubuntu-meta (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Confirmed Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for "PCI slot", that the second p stands for "port number", and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to address some other problem. Breaking
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
I also put GRUB_CMDLINE_LINUX_DEFAULT=net.ifnames=1 in /etc/default/grub and removed 75-persistent-net-generator.rules -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: New Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to address some other problem. Breaking working systems is far worse than
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
Is there any update on this? I have two USB mobile broadband interfaces and even if I upgraded to Ubuntu Vivid the network names are still not predictable. I had a quick look on the mailing list discussion and It's worth to note that some USB devices have duplicate mac addresses so it shouldn't be considered unique. This is actually quite common. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: New Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
The biosdevname mechanism is being proposed to be changed. Please see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038777.html. Feedback appreciated. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: New Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to address some other problem.
Re: [Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
On Mon, 13 Apr 2015 13:32:15 -, Robie Basak wrote: A release upgrade should not cause biosdevname to get installed. So can you (or someone) please confirm that this is definitely the behaviour in some case, It has now been most of a year since I filed the bug report, so as you might imagine, I no longer remember the details of the upgrade that prompted it. Here's what I know: On the system in question, eth0 disappeared and was replaced by psomethingpsomething. The main.log files under /var/log/dist-upgrade include lsb-release: quantal, raring, and saucy. The currently-installed release is trusty. This implies that the steps to reproduce include one or more of those distribution upgrades. I guess precise must have been the first-installed release. Although I don't know when biosdevname was first installed, it is listed in the Upgrade: log entries of all the /var/log/dist-upgrade/date/main.log files, including one from a year before my bug report. I suppose that means biosdevname was likely installed by some earlier release, rather than being newly installed during the problematic dist-upgrade. The motherboard's chipset is an Intel Z77 Express. The ethernet device uses a Realtek RTL8111/8168/8411 series chip. The r8169 kernel driver is currently in use. and if so provide steps to reproduce so that we can understand the mechanism involved here that is making this happen? Sorry, but I already spent too much time on this issue when it bit me in the first place. Reproducing it to determine step-by-step instructions would require taking the computer out of service, saving all of its data and state, taking it through several install and upgrade cycles, and then restoring everything. That is far more disruption and time than I can spare. Second, you say that some distributions require both systemd and biosdevname interface renaming to be disabled. My understanding is that on Ubuntu with systemd (so Vivid only), we do not rename interfaces via systemd by default - this must be done explicitly. Can we assume for the rest of the discussion that this is true, or otherwise can you provide steps to reproduce that demonstrate that it is not (again, another bug might be a good idea to avoid cluttering this one)? That's quite possible. It has been most of a year since I wrote that text, but I probably meant to include non-ubuntu distros when I wrote some distributions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: New Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
Full history in bug 891258 and https://lists.ubuntu.com/archives/ubuntu- devel/2012-January/034687.html, https://lists.ubuntu.com/archives /ubuntu-devel/2012-February/thread.html. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: New Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to address
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
Thank you for taking the time to file this and helping to make Ubuntu better. I appreciate your detailed write-up and understand your frustration at the changes made. Before going into policy questions, I'd like to clear up a couple of factual concerns I have after reading your report. I think it'd be useful to clarify these first so that opinions can be formed based on accurate facts. My first concern is that you say that you ended up with interfaces renamed according to biosdevname after a release upgrade when they weren't being renamed before the release upgrade. As far as I understand, this was never the intention and upon examination I can see no code that would cause this to happen. My understanding is that the biosdevname package that does the renaming is only installed at first install time by the installer, and not installed after that. A release upgrade should not cause biosdevname to get installed. So can you (or someone) please confirm that this is definitely the behaviour in some case, and if so provide steps to reproduce so that we can understand the mechanism involved here that is making this happen? I suggest that you do this in a separate bug against biosdevname to start with (eg. Interfaces get renamed on release upgrades) so that if it is a bug that can be fixed without any policy-level discussion then we can do it without cluttering this bug. Second, you say that some distributions require both systemd and biosdevname interface renaming to be disabled. My understanding is that on Ubuntu with systemd (so Vivid only), we do not rename interfaces via systemd by default - this must be done explicitly. Can we assume for the rest of the discussion that this is true, or otherwise can you provide steps to reproduce that demonstrate that it is not (again, another bug might be a good idea to avoid cluttering this one)? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in biosdevname package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: New Status in udev package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
** Changed in: biosdevname (Ubuntu) Status: New = Opinion ** Changed in: systemd (Ubuntu) Status: New = Opinion ** Changed in: udev (Ubuntu) Status: New = Opinion -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1347859 Title: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems Status in “biosdevname” package in Ubuntu: Opinion Status in “systemd” package in Ubuntu: Opinion Status in “udev” package in Ubuntu: Opinion Bug description: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to
[Touch-packages] [Bug 1347859] Re: Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems
** Description changed: Relatively recent linux distribution upgrades have been causing computers' ethernet devices to be unexpectedly renamed. While I understand that consistent device naming solves problems on some systems (mostly multi-NIC servers and a few specialty embedded devices), unilaterally forcing these changes on everyone is causing a lot of frustration. Here are some of the problems I've encountered: - - Interface names that were easily recognized as abbreviations for their device type have been replaced by cryptic names that have no obvious meaning whatsoever. It's easy to guess that eth0 is short for ethernet #0. What the heck is p4p1 supposed to mean? How is a human supposed to guess that the first p stands for PCI slot, that the second p stands for port number, and that the whole mysterious string represents an ethernet interface? This new naming convention is inferior to the old one in at least one significant respect: it makes things more difficult to understand. + Interface names that were easily recognized as abbreviations for their + device type have been replaced by cryptic names that have no obvious + meaning whatsoever. It's easy to guess that eth0 is short for ethernet + #0. What the heck is p4p1 supposed to mean? How is a human supposed to + guess that the first p stands for PCI slot, that the second p stands + for port number, and that the whole mysterious string represents an + ethernet interface? This new naming convention is inferior to the old + one in at least one significant respect: it makes things more difficult + to understand. One of the more useful examples of consistency that unix-like systems have enjoyed for decades has been thrown out: the extremely well-known ethernet device names. This creates yet another hurtle for users and admins when switching between different operating systems or trying to apply general-purpose unix knowledge. A lot of documentation has been broken. I have no idea how many manuals, forum posts, bug reports, printed instructions, email messages, personal notes, books, and other forms of documentation in the world refer to a unix ethernet device as eth0, but I'll bet the number is huge. All that valuable guidance has just been rendered misleading or even useless to anyone who doesn't keep up with the latest distribution-specific device naming experiments; in other words: the people who need it most. Well-established workflows have been broken. The change trips up users and admins who have for years been getting tasks done quickly with commands that they could recall and execute without a second thought. They are suddenly finding that their workflows no longer work. This interrupts tasks that should have been quick and easy, forcing people figure out why known-good procedures are broken, think about how to modify their memorized commands to work on the affected systems, and train their fingers to type those new commands as quickly as they did the old ones. Beyond being irritating, it can eat up a bunch of time that some of us don't have to spare. Working systems have been broken. Tools and automation scripts, especially those developed for site-specific use, often make the difference between a computer that does real work and a useless generic OS installation. Sometimes they even make the difference between a malfunctioning headless box that can be fixed over the network and an expensive brick. It is quite common for such software to make some minimal assumptions about its runtime environment, like assuming that the name of the only network device that has ever been or will ever be present will not suddenly change after being stable for months or years. There are also applications (e.g. Matlab) and configuration files (e.g. smb.conf, dhclient.conf, isc-dhcp-server) that might depend on references to eth0. Renaming a critical and ubiquitous device like this is so very likely to cause problems that it should never, ever be done in an upgrade without the admin's explicit consent. Sufficient warning of the change was not given. On one of my machines, eth0 was renamed to p4p1 when I upgraded to Ubuntu 14.04 (trusty), yet I don't see any mention of it in the Trusty release notes, nor in any of the notes for releases of the previous several years. Is it buried in fine print someplace that I missed? Having to figure out for myself what changed, why, and how to revert it (in multiple ways on each machine) was a significant waste of my time. Multiply that by all the other people who were affected similarly, and I'll bet we'd get an embarrassing number of needlessly wasted person-months that could have been saved with a simple announcement and link to documentation. - - In short, the way this feature was forced on the world was an irresponsible blunder. It doesn't matter that the change was meant to address some other
