<div dir="auto">How does the predictable naming conventions work in VMs? I see they always differ slightly.<div dir="auto"><br></div><div dir="auto">Are we not using a pool of expected syntax like 1/2/3 ??? Or is it built on things like mb.vendor, # nics, and other arbitrary things like that?</div><div dir="auto"><br></div><div dir="auto">I've been reconfiguring servers that were vMotioned from one DC to another ... the nic names are ALWAYS *slightly* different.</div><div dir="auto"><br></div><div dir="auto">Im not sure why the way you access single user mode had to change.<br><br><div data-smartmail="gmail_signature" dir="auto">Thanks,<br>Alexander.<br><br>Sent from my Samsung Galaxy S8+</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018, 13:41 Brian Cluff <<a href="mailto:brian@snaptek.com">brian@snaptek.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12/4/18 12:40 PM, Snyder, Alexander J wrote:<br>
> Does anyone know why networking devices aren't eth0/1/2/3 but are now <br>
> ens0f0/enp0d0.<br>
<br>
Those are the new "Predictable Network Interface Names" based on where <br>
they are physically plugged into the system.<br>
You can read all about them here:<br>
<a href="https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/" rel="noreferrer noreferrer" target="_blank">https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/</a><br>
In a nut shell they make sure that you device names don't ever change <br>
which is really annoying when you have a server is hosted out of state <br>
and can't get your hands on it to fix all your scripts that use eth0 as <br>
your internet facing interface when it suddenly switches places with <br>
eth1 or gets bumped to eth3 for any number of reasons.<br>
The new names are a little jarring at first, but if you allow yourself <br>
to get used to them then you will be able to tell someone, without any <br>
doubt, based on the devices name which exact device needs to be swapped <br>
out when it fails, and the replacement device will be given the same <br>
name, as long as it's plugged into the same place)<br>
<br>
> Also getting into single user mode now is (IMHO) unnecessarily <br>
> complicated (typing 'single' versus now 'init=/sysroot/bin/bash').<br>
<br>
init=/sysroot/bin/bash has always worked and is my preferred way of <br>
getting into a system without running anything else.  That line simply <br>
tells grub to bypass starting the system's init system which is systemd <br>
on the newer systems and to instead run bash as linux's init.<br>
<br>
If you are looking to get into a true single user mode you will probably <br>
want to instead use one of the following lines where you were previously <br>
using init=/sysroot/bin/bash:<br>
<br>
systemd.unit=rescue.target (can be shortened to systemd.unit=rescue)<br>
or<br>
systemd.unit=emergency.target (can be shortened to systemd.unit=emergency)<br>
<br>
The emergency target is the most minimal of the 2.<br>
<br>
Brian Cluff<br>
<br>
---------------------------------------------------<br>
PLUG-discuss mailing list - <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank" rel="noreferrer">PLUG-discuss@lists.phxlinux.org</a><br>
To subscribe, unsubscribe, or to change your mail settings:<br>
<a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a></blockquote></div>