[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fix for no ssh

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 

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 

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,

Attachment: signature.asc
Description: PGP signature

Reply to: