Re: The Simple Things in Life
Xen [2016-07-21 5:22 +0200]: > It was ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules. > > But that doesn't work, it used to work somewhere at some point. It does work, other than for USB devices, which is LP: #1593379. It got fixed in xenial-updates two days ago. Perhaps you forgot to "update-initramfs -u" after that and have the USB device already connected. FWIW, this is the *only* reply to this thread that I will ever do. I'm too busy following by secret agenda to reply to the other mails... Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The Simple Things in Life
*chuckle* I think you hit it on the head with the house numbers... Eventually, people will just get a house in a different neighborhood if things become too stupid where they live. Thx also for the follow-up on the code. Too bad there is no easy fix outside of boot params. -ml PS: in 12.04, one of my MB NIC's came in as dev "virbr0"... perhaps "en[whatever]" is not so bad after all... On 7/20/2016 8:00 PM, Xen wrote: Markus Lankeit schreef op 20-07-2016 23:54: Hi Xen, Thanks for going to bat for us on this--sorry that no one wanted to hear you. Odd that a Debian dev would balk at this... Last I loaded the latest Debian (about a month ago), I got the good-old "ethx" interface names. Hmm Totally agree with your assessment that the argument "for" this new naming scheme is ludicrous and illogical... Thankfully, there is a relatively simple way to disable this scheme ( http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04). Yes. But... I don't like changing boot parameters for this (it means the sanity of my system is now wholly dependent on my bootloader's configuration file, which is a dependency I do not want to have; any form of alternative booting of the kernel now *also* needs to reference those parameters for the system to keep functioning as normal (if it uses any firewall scripts or the like) which is something I don't want and don't want to invest in. It should be purely based on on-disk structures that either just belong to /etc, (preferably) or get added to the initrd. The udev rule is convenient enough except that udev is incomprehensible so the only way to manage this is to keep a notition of this in some convenient internet location of your own because invariably you are going to lose access to wherever you have stored it, and you can't memorize this or produce it from memory. Meaning, unless you have some trustworthy access to this information you will not be able to reproduce it when you configure a new system and you will just forget and not care. Which seems to be the intent of the designers: that it is so hard or inconvenient that most people just won't bother and use the default. Hence, more people using what they want. I believe the way to turn off the system is to do: ln -s /dev/null /etc/udev/rules.d/70-persistent-net.rules Which I did in the beginning but I can never remember the name. At a certain point I fixed my static IP in a central dnsmasq config file so my static IPs are getting fixed through DHCP but before I definitely didn't have this facility and simply preferred to use /etc/network/interfaces which became hideous under this system. I still don't like seeing this enp4s0 (under the previous motherboard it was enp3s0, go figure) whenever I look under the hood and detest it to the bone. It is like calling a house in a street with no other houses, house number 2530. 2530 Empty Street. Why 2530? Well, the hash of the number of bricks used to built the house was 2530, that's why. Makes sense right. right. Maybe I will use this thread to find this information ;-). Regards. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The Simple Things in Life
Xen schreef op 21-07-2016 5:00: I believe the way to turn off the system is to do: ln -s /dev/null /etc/udev/rules.d/70-persistent-net.rules It was ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules. But that doesn't work, it used to work somewhere at some point. But no longer. So I have no clue how to turn it off other than passing a kernel parameter. Which I don't want. I guess I need to start patching more software, or something -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The Simple Things in Life
Markus Lankeit schreef op 20-07-2016 23:54: Hi Xen, Thanks for going to bat for us on this--sorry that no one wanted to hear you. Odd that a Debian dev would balk at this... Last I loaded the latest Debian (about a month ago), I got the good-old "ethx" interface names. Hmm Totally agree with your assessment that the argument "for" this new naming scheme is ludicrous and illogical... Thankfully, there is a relatively simple way to disable this scheme ( http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04). Yes. But... I don't like changing boot parameters for this (it means the sanity of my system is now wholly dependent on my bootloader's configuration file, which is a dependency I do not want to have; any form of alternative booting of the kernel now *also* needs to reference those parameters for the system to keep functioning as normal (if it uses any firewall scripts or the like) which is something I don't want and don't want to invest in. It should be purely based on on-disk structures that either just belong to /etc, (preferably) or get added to the initrd. The udev rule is convenient enough except that udev is incomprehensible so the only way to manage this is to keep a notition of this in some convenient internet location of your own because invariably you are going to lose access to wherever you have stored it, and you can't memorize this or produce it from memory. Meaning, unless you have some trustworthy access to this information you will not be able to reproduce it when you configure a new system and you will just forget and not care. Which seems to be the intent of the designers: that it is so hard or inconvenient that most people just won't bother and use the default. Hence, more people using what they want. I believe the way to turn off the system is to do: ln -s /dev/null /etc/udev/rules.d/70-persistent-net.rules Which I did in the beginning but I can never remember the name. At a certain point I fixed my static IP in a central dnsmasq config file so my static IPs are getting fixed through DHCP but before I definitely didn't have this facility and simply preferred to use /etc/network/interfaces which became hideous under this system. I still don't like seeing this enp4s0 (under the previous motherboard it was enp3s0, go figure) whenever I look under the hood and detest it to the bone. It is like calling a house in a street with no other houses, house number 2530. 2530 Empty Street. Why 2530? Well, the hash of the number of bricks used to built the house was 2530, that's why. Makes sense right. right. Maybe I will use this thread to find this information ;-). Regards. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: The Simple Things in Life
Hi Xen, Thanks for going to bat for us on this--sorry that no one wanted to hear you. Odd that a Debian dev would balk at this... Last I loaded the latest Debian (about a month ago), I got the good-old "ethx" interface names. Hmm Totally agree with your assessment that the argument "for" this new naming scheme is ludicrous and illogical... Thankfully, there is a relatively simple way to disable this scheme ( http://askubuntu.com/questions/767786/changing-network-interfaces-name-ubuntu-16-04). Thx. -ml On 7/20/2016 1:56 PM, Xen wrote: Markus Lankeit schreef op 20-07-2016 0:01: Also, the whole network device naming scheme is just a fiasco... Before, I could have a simple template for all my systems... now every system requires a unique template that takes me to the HW level to figure out what it might be. And this is supposed to be more intuitive and/or predictable than "eth0"? I've tried to make a point of this recently on the systemd-devel list but one of the Ubuntu (and Debian) devs (Martin Pitt) would have none of it and a kernel developer tried to show me off into the woods by coming up with thought experiments as to why any other solution would not be viable. Basically I just think they have an agenda and won't admit to it. Many illogical decisions become logical the moment you know the truth. There are probably some business customers that need flawless device recognition while requiring absolute zero configuration from the viewpoint of the boot process. Any other strategy would work, including condensing the detected hardware list for onboard/unpluggable devices only. They tried to tell me that a Linux system was capable of recognising a hardware device that was present during boot only hours after the system was booted - theoretically - and that because of this a stable "condensation" into names such as ethernet0 would not be possible. Ie. what if after 3 hours of using the system, a network card will suddenly pop up? What then of your numbering? Now you have to insert another card in the number and your numbers won't be right anymore. That is the ludicrous argument to my counterargument that they gave me. Ie. I believe the network card detection works by trying all drivers and seeing if they can find any card they can manage, this is a pretty deterministic process and will probably end pretty fast for any driver seeing how fast the system boots these days (particularly with SSD) and never has a problem. If any driver cannot find any hardware, it is removed from the list and never tried again. So apparently (according to kernel documents I read online) this is a pretty bounded thing with a guaranteed endpoint depending on whether any drivers do anything really weird, which I think they don't. However lacking my real knowledge of the thing they were able to pretty much shove me off into the woods as indicated or at least give other people the impression that I didn't know what I was talking about. I suggested a condensation of network devices (based on the current scheme) into a fixed list of ethernet0, ethernet1 and so on, that would at once be different from the old default (the kernel names) and that would be executed moments prior to the activation of the networking system and that would fix the networking instability with about as much grace as the current system can foster. Meaning, I just wanted to map the current names into fixed lists (of devices) but only for hardware-devices-present-at-boot (unpluggables) and using the current "BIOS" names as the foundation for that mapping (in terms of order) such that the order of those devices would never change as long as the mapping was done after all the devices had been found. Which seems not impossible, but they told me it was. Existing mapping (renaming) to kernel device names caused race conditions when done on the fly. Mapping to another fixed namespace can never cause race conditions. And if the condensation is done prior to networking being started, there can never be an issue because conceptually networking cannot start until all required devices have been found. Ie. you cannot start some firewall if one of the required devices is missing. It is a complete and conceptual end-point (target, as per systemd jargon) that network device recognition must have completed prior to doing anything with those devices; that logically the former phase must be completed before the next can start. So how you can start networking while accepting as some kind of basic reality and possibility that 3 hours down the line, a required networking device will suddenly surface, is beyond me. Yet this is what Martin Pitt and others told me. Which to me feels like "find reasons to not have to do this thing, quick". "Give him the wrong directions, quick". "Don't let anyone think his idea is actually capable of having life, quick". :-/. What else can I make of it
Re: The Simple Things in Life
Markus Lankeit schreef op 20-07-2016 0:01: Also, the whole network device naming scheme is just a fiasco... Before, I could have a simple template for all my systems... now every system requires a unique template that takes me to the HW level to figure out what it might be. And this is supposed to be more intuitive and/or predictable than "eth0"? I've tried to make a point of this recently on the systemd-devel list but one of the Ubuntu (and Debian) devs (Martin Pitt) would have none of it and a kernel developer tried to show me off into the woods by coming up with thought experiments as to why any other solution would not be viable. Basically I just think they have an agenda and won't admit to it. Many illogical decisions become logical the moment you know the truth. There are probably some business customers that need flawless device recognition while requiring absolute zero configuration from the viewpoint of the boot process. Any other strategy would work, including condensing the detected hardware list for onboard/unpluggable devices only. They tried to tell me that a Linux system was capable of recognising a hardware device that was present during boot only hours after the system was booted - theoretically - and that because of this a stable "condensation" into names such as ethernet0 would not be possible. Ie. what if after 3 hours of using the system, a network card will suddenly pop up? What then of your numbering? Now you have to insert another card in the number and your numbers won't be right anymore. That is the ludicrous argument to my counterargument that they gave me. Ie. I believe the network card detection works by trying all drivers and seeing if they can find any card they can manage, this is a pretty deterministic process and will probably end pretty fast for any driver seeing how fast the system boots these days (particularly with SSD) and never has a problem. If any driver cannot find any hardware, it is removed from the list and never tried again. So apparently (according to kernel documents I read online) this is a pretty bounded thing with a guaranteed endpoint depending on whether any drivers do anything really weird, which I think they don't. However lacking my real knowledge of the thing they were able to pretty much shove me off into the woods as indicated or at least give other people the impression that I didn't know what I was talking about. I suggested a condensation of network devices (based on the current scheme) into a fixed list of ethernet0, ethernet1 and so on, that would at once be different from the old default (the kernel names) and that would be executed moments prior to the activation of the networking system and that would fix the networking instability with about as much grace as the current system can foster. Meaning, I just wanted to map the current names into fixed lists (of devices) but only for hardware-devices-present-at-boot (unpluggables) and using the current "BIOS" names as the foundation for that mapping (in terms of order) such that the order of those devices would never change as long as the mapping was done after all the devices had been found. Which seems not impossible, but they told me it was. Existing mapping (renaming) to kernel device names caused race conditions when done on the fly. Mapping to another fixed namespace can never cause race conditions. And if the condensation is done prior to networking being started, there can never be an issue because conceptually networking cannot start until all required devices have been found. Ie. you cannot start some firewall if one of the required devices is missing. It is a complete and conceptual end-point (target, as per systemd jargon) that network device recognition must have completed prior to doing anything with those devices; that logically the former phase must be completed before the next can start. So how you can start networking while accepting as some kind of basic reality and possibility that 3 hours down the line, a required networking device will suddenly surface, is beyond me. Yet this is what Martin Pitt and others told me. Which to me feels like "find reasons to not have to do this thing, quick". "Give him the wrong directions, quick". "Don't let anyone think his idea is actually capable of having life, quick". :-/. What else can I make of it. Sorry for not writing all that well. Regards. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
