Hash: SHA256

It actually works is enough reason for me.  Was forced to migrate a
> bunch of systems not six months back from systemd-udev to eudev because
> systemd-udev is absolutely terrible w.r.t. race conditions resulting in
> lockups that kept forcing us into manual intervention situations.
> Mostly on systems with LVM.
> > I don't exactly know what your situation is, but as I said, this
> > proposal wouldn't affect your systems. I'm not talking about lastrites
> > for eudev, just making it the default for new installs.

It would affect new installations.  But yes, we can switch it back to
eudev post install.

> I'm completely against the proposal.
> >>>> I would want some convincing that it was not another step on the road
> >>>> to Gentoo being assimilated by systemd.
> >>>>
> >>>> We had this discussion several years ago when the default became
> >>>> eudev. What's changed?
> >>>
> >>> If systemd folks do make udev inseparable from systemd, then we would
> >>> need eudev to be the default, but as I see it right now, there is not
> >>> a case for it being the default.
> Other than that it works and the systemd version does not.  Might be
> configuration dependent, but I don't expect a default udev
> configuration/system side to not cause LVM breakages when running
> commands as simple as "lvs".  eudev in coparison just works.
> >  I don't know what is going on with your systems, but I suspect possible
> >  configuration dependence.

Ok, simplest mechanism we've found:

Install a system with at least one LV partition and leave some space
available in the VG, then do:

term 1:  watch lvs

term 2:  while true; do lvcreate -L1G -s -ntemp_snap /dev/${vg}/${lv} &&
lvremove /dev/${vg}/temp_snap; done

Give it anywhere from two two five minutes.  Can be hours sometimes. 
But eventually it does die.  Can't say the same for eudev.

> > When are the breakages happening-- just at random or during bootup?

In some cases rebooting is the only way to recover.

Kind Regards,



Reply via email to