On Lu, 08 iul 19, 10:19:35, Curt wrote: > > I thought you were saying that > '/etc/udev/rules.d/70-persistent-net.rules' remains a valid mechanism > for defining interface names in Buster (fixed). But the release-notes > (hmm, I think they've been modified since I last looked and now state > that that file is no longer "officially" supported by udev---but may > work in some cases). So I wouldn't be filing a bug report against that > stanza any longer, as current situation seems unverifiable. For the record, the current wording (no official support) is based on input from the Debian systemd maintainers. They should know what is supported or not ;) As far as I know the /etc/udev/rules.d/70-persistent-net.rules method can fail to properly rename the interfaces in certain situations which can leave your system without networking. Not nice on remote machines. It is also my understanding that systems with only one interface (of a given type[1]) are pretty safe with it or net.ifnames=0, so the impact on regular[2] desktop/laptop users should be minimal. [1] assuming ethernet cards are always named ethX and wireless cards are always named wlanX by the kernel. I might have had a wireless card that came up as ethX, but that was a long time ago. Still, something to be aware of. [2] one ethernet interface, usually integrated in the motherboard and one (additional) wireless interface for the laptops. Anything more complicated than that might break without warning. > Well, at the very least people should be informed who is likely to be > affected by the bug In my understanding a lot of daemons are affected. Would it make sense to (try to) list them all? > and for those using amd64 how to check for the RDRAND > instruction, I agree that checking for the RDRAND instruction would indeed be a good addition. Someone (tm) needs to do the research and come up with a patch. As I currently don't own any amd64 systems I can only offer to support with the wording, process of submitting the patch, etc. > as well as what to do about it if they don't have it (that's what I'd > like to know, at any rate). haveged is mentioned in the Release Notes. jitterentropy-rngd was mentioned here on list as a newer alternative to haveged. Using an external hardware random generator is another option I know of, possibly the most secure, if you trust the implementation. I considered all of them. Ultimately I settled on none, because I only get about 5 seconds delay on my PINE A64+ (arm64): amp@pine64:~$ sudo dmesg | grep 'random.*done' [ 6.785377] random: fast init done [ 11.632783] random: crng init done Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature