On Sb, 06 apr 19, 14:46:44, Karl O. Pinc wrote: > On Sat, 6 Apr 2019 21:31:42 +0300 > Andrei POPESCU <andreimpopescu@gmail.com> wrote: > > > > > According to [1] here are two other options: > > > > 3. assign own names (e.g. internet0, dmz0, lan0, etc.) by creating a > > .link file in /etc/systemd/network/ and migrate your configuration > > accordingly. > > This I was not thinking of, although I'd skimmed [1]. > > This is sort of like choice 2, in that it requires digging > into hardware identifiers. But being able to use, say, a > MAC address instead of digging into the intricacies of the bus > makes this a simpler approach. It would also be nice > to use this approach to keep the old eth* name and not > have to change the rest of /etc/ at all. This approach seems much less error prone to me. > On the other hand, it does > not really help in migrating to the new naming scheme. It could be mentioned at least as an option, as many sysadmins might not want to migrate anyway. > > 4. disable the naming policy (via kernel parameter or udev) and > > optionally migrate later (e.g. when one has console access to the > > system). > > > > It should be possible to use the kernel parameter in combination with > > a "boot once" grub entry to both get the new name and test the new > > configuration for remote systems. > > Humm. Yes. [2] says this will work. For some reason I thought > it said this approach was going away, but it does not say that. > > This might be simplest when updating remote systems. Although > it would require an "at" job to reboot after the "boot once". Right? > At least if trying to migrate remotely. Untested: # echo "/usr/bin/systemd-run --on-boot=10min /bin/systemctl reboot" >> /etc/rc.local # chmod +x /etc/rc.local Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature