[CentOS] systemctl hoses eth port settings

[allan emord]

Hi all,
I recently added 2 eth ports to C7 machine via USB adapters.
Set up devices with Settings - Network .
While cables (and target devices) are installed, running `systemctl 
restart network` worked OK. If one of the devices loses connectivity 
(e.g. uplug eth cable) `systemctl restart network` will mix up the 
device assignments thereby losing connectivity to host. e.g. enp7s0, the 
PCI network card, gets set to parameters that belong to one of the USB 
adapters.
This is not desired behavior. Is there something I have done 
incorrectly? I this normal behavior? I have looked at the scripts for 
if[up|down], and if run manually, works well to re-configure the enp7s0 
interface but (apparently) systemctl does not use these scripts.

Thanks for your consideration.
Allan
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] rd.lvm.lv on CentOS Stream 9 (first-boot failure)

[Gordon Messmer]

On 1/9/22 15:37, Gordon Messmer wrote:
1: The system also includes a volume group named "BackupGroup" and 
that group activates on boot (post-dracut).  Why are those LVs 
activated when rd.lvm.lv is specified?



As far as I can tell, this is because in the dracut boot process, the 
device backing VolGroup is activated, but the device backing BackupGroup 
is not.  As a result, the latter device triggers a udev event after the 
normal root FS is mounted, and udev creates a transient systemd unit to 
start the BackupGroup VG.  No udev event for VolGroup == no furter 
activation.




2: Why didn't Anaconda add the "var" LV to the kernel arguments?



I still don't know the answer to this, but the current arrangement seems 
like a bug.  As far as I know, the LVs inside VolGroup can't be 
activated unless that VG is complete, and if it's complete, then I can 
see no good reason why Anaconda should add individual LVs to the kernel 
command line rather than "rd.lvm.vg=VolGroup".  Activating the group as 
a whole would fix both the boot failure resulting from lv_var not being 
activated, as well as the libvirt failure resulting from the guest LVs 
being absent.


Once I replaced Anaconda's boot args with "rd.lvm.vg=VolGroup", the 
system works properly.



3: This seems like a change from earlier releases, but I can't find 
any documentation to that effect.  Under CentOS 7, after dracut had 
finished, the remaining logical volumes in that group would be 
activated.  Because they aren't, currently, libvirtd cannot start any 
of its guests until I manually activate the group.  How can I restore 
the old behavior of activating all of the LVs on boot?



I believe the regression is the result of deprecating lvmetad in favor 
of udev event-based activation.


___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos