Hi,
On Thu, 2018-10-25 at 20:35 +0200, Thomas HUMMEL wrote: > On 10/18/2018 11:30 PM, Thomas Haller wrote: > > Btw, note that if you configure the device as unmanaged via > > NM_CONTROLLED=no in ifcfg, then the device cannot be set to > > managed. > > This way of unmanaging a device is definite, > > Hello again, another use case I'm still wrapping my head around > (even > with the precious knowledge acquired thanks to your help!) > > Let's say I've got this setup : > > - eth0 NM_CONTROLLED=no > - eth1 NM_UNMANAGED=1 via udev > (and suppose eth1 in no-auto-default.state) > > here's what I'm testing > > - about NM_CONTROLLED=no : > > # nmcli connection show > NAME UUID TYPE DEVICE > > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > GENERAL.DEVICE: eth0 > GENERAL.STATE: 10 (unmanaged) > > GENERAL.DEVICE: eth1 > GENERAL.STATE: 10 (unmanaged) > > GENERAL.DEVICE: lo > GENERAL.STATE: 10 (unmanaged) > > # nmcli device set eth0 managed yes > # echo $? > 0 > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > GENERAL.DEVICE: eth0 > GENERAL.STATE: 10 (unmanaged) > > -> as you explained, unmanaging a device this way is definite, but > is > the 0 return value legit here ? The return value of the nmcli command is odd, maybe a bug. It returns success, because it successfully flagged the device that the user wishes to manage it. However, there may still be other (stronger) reasons, why the device stays unmanaged (NM_CONTROLLED=no). Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `, but this just returns (state != "unmanaged"). Optimally, there would be a nother flag which is the opposite of `nmcli device set $DEV managed $VALUE`. So, when you issue device-set, it would succeed and would toggle this flag, but that alone may not be sufficient to make the device (fully) GENERAL.NM-MANAGED yet. > - about the following sentence in man regarding NM_UNMANAGED : > > "You will still be able to attach a connection to the > device manually or observe externally added configuration such as > addresses or routes." I think this part of the manual should be improved. https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=085b769729e9c623cc60bb0f88df36d1843cd22b > > # nmcli device set eth1 managed yes > # echo $? > 0 > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > GENERAL.DEVICE: eth1 > GENERAL.STATE: 20 (unavailable) state "unavailable", looks like the device has no cable plugged in (no carrier). You'd also see that with `ip link show eth1` saying "NO- CARRIER". > -> it's not unmanaged anymore, so it's managed > > # nmcli connection show > NAME UUID TYPE DEVICE > > -> still no connection, seems normal to me I agree. A connection would only be created via the "auto-default" mechanism, which depends on main.no-auto-default setting and /var/lib/NetworkManager/no-auto-default.state. Not sure whether that's the case, or because the device state is still unavailable... either way, this doesn't seem wrong here (without knowing all the details). > # nmcli device connect eth1 > Error: Failed to add/activate new connection: Connection 'eth1' is > not > available on the device eth1 at this time. Here, (I think), first nmcli tried to activate a profile on the device. That failed, because no profile exists. Then it tried to create a new profile (with ipv4.method=auto). Activation of the created profile then probably fails, because the device has no carrier (which is required for successful DHCP). > -> ok, seems normal to as well since auto profile creation must not > work > under NM_UNMANAGED conditions no, I think this part of the manual is misleading. A device is either "unmanaged" or not. Udev's NM_UNMANAGED is a way to configure the device as unmanaged, and `nmcli device set $DEV managed yes` can overrule that. Aterwards, there is no further difference between other managed devices. > > # nmcli connection add type ethernet con-name managed-eth1 ifname > eth1 > Connection 'managed-eth1' (41727fca-d424-40d9-91e7-55197ff9a962) > successfully added. > > # nmcli connection show > NAME UUID TYPE DEVICE > managed-eth1 41727fca-d424-40d9-91e7-55197ff9a962 ethernet -- > > -> ok I managed to create a connection somehow linked to eth1 > device. > It's not active which also seems normal to me It didn't autoactivate, because the device's state is "unavailable" If you'd create a profile with ipv4.method=manual, you could also activate it on a device with cabel unplugged. > But then I cannon neither connect the eth1 device nor activate the > newly > created profile > > -> what's happening here ? > best, Thomas
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
