Home › Forums › TrueRNG Hardware random number generator › Ubuntu 15.04 rngd read errors back
This topic contains 9 replies, has 3 voices, and was last updated by randomly 8 years, 5 months ago.
-
AuthorPosts
-
June 4, 2015 at 9:24 am #1298
Hi everyone!
I noticed that since I updated to Ubuntu 15.04 rngd regularly produces read errors in syslog and eventually closes down completely. As this was an error in the past I went to see what “sudo stty -F /dev/TrueRNG” would produce:
sudo stty -F /dev/TrueRNG speed 9600 baud; line = 0; min = 1; time = 0; -brkint -imaxbel
Looks like the UDEV rules/commands are not executed at boot. So I rebooted and looked on the output too see something out of the ordinary and yes: udev waits 3 minutes to initialize something and eventually gives up or is done with it at exactly those 3 minutes.
As udev doesn’t say what it is waiting for I can only assume that it is the trueRNG udev rule and it fails to load it leading to my issue.
I wonder if others have the same issue and if the team can help me fix it.
Thanks in advance!
June 5, 2015 at 11:47 am #1299OK, I’ve found the error!
Because of some update from Ubuntu 14.10 to 15.04 the syntax of udev rules changed and now it doesn’t parse %k variable.
To fix the issue do the following.
Change
/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000
to
/bin/stty raw -echo -ixoff -F /dev/TrueRNG speed 3000000
and everything works again.
Have fun!
June 5, 2015 at 12:36 pm #1300Thanks for the update, We’ll have to review how we want to handle this change, but for now I’ll link this post.
June 5, 2015 at 4:40 pm #1303Thanks for looking into the matter.
I unfortunately just realized that this didn’t fix my problem for real.I just typed in the stty-command as suggested above, checked if it worked (yes), adjusted the udev-rule, restarted and it still worked. The initialization at boot was gone and the baud rate and flags were set as they should. So I thought I fixed it.
Now after turning my pc off and on again the TRNG fell back into normal mode with low baud and the missing flags. I guess the pc keeps the settings when just restarting?!
Anyways: There seem to be at least two problems with the udev rule when used on Ubuntu 15.04 and I only fixed one of it. I’ll investigate further but in the meantime I’d be glad if somebody else could reproduce this problem.
June 5, 2015 at 5:09 pm #1304Ok, I now can fully reproduce both the scenario when udev rules fail to work and when they work fine.
It fails when I normally boot the computer from being turned off.
It works when I reboot the computer without shutting it down.
I honestly have no idea how anything can be carried over from one session to another when I restart the computer but it has to or otherwise things wouldn’t happen how they do. It seems like as if the udev rules gets executed too early or needs to run twice to work or something.
I’ll continue to try and find a fix it but I must admit that from now on I fly blind and really hope somebody who knows better how udev works can find a solution.
June 17, 2015 at 4:17 pm #1306Do you have the modem-manager package installed by chance? It has a tendency to mess with the serial port looking for modems. I believe we added a blacklist rule to the old udev rules but maybe it isn’t working any more with the updated os.
June 18, 2015 at 9:48 pm #1307I’m not sure if this is related, but I’m on debian jessie 8.1. I noticed that after I upgraded a few packages yesterday (apt-get upgrade) TrueRNG was broken. Unfortunately, I don’t remember which packages I upgraded.
Here are a few things I noticed:
- systemd complains about “invalid key/value pair” which I think is related to the file format of the rules file. It is ASCII text, with CRLF line terminators. I resaved it as just ASCII text and I’m crossing my fingers. It’s working now after a reboot, but the last time, it took a hour before it gave up/reset.systemd-udevd[17049]: invalid key/value pair in file /etc/udev/rules.d/99-TrueRNG.rules on line 7,starting at character 210 (‘\n’)
(I edited the file a little to try a few things, but the format was unchanged when systemd/udevd threw this error)
I was rebuilding/resizing a filesystem, which I assume is why the last day has been lower than usual. The points where it dropped to zero are where the rng daemon would not start and entropy was 0 or very low. It probably would be higher if I removed rng-tools so that the kernel would have relied on good old fashioned entropy collection.
-
This reply was modified 8 years, 5 months ago by
gee-one.
June 19, 2015 at 12:58 am #1309Do you have the modem-manager package installed by chance?
I’m very sorry for my late reply. I will be more responsive now!
To answer your question: I don’t have a package named “modem-manager” installed but I have one installed called “modemmanager” (D-Bus service for managing modems).
Maybe this little missing “-” is the reason why modem isn’t correctly blocked by udev rules?
June 19, 2015 at 8:33 am #1310Here is what I am using now- it seemed to survive a reboot and shutdown. I changed the file format of /etc/udev/rules.d/99-TrueRNG.rules to ASCII text (no CRLF).
I set the feed interval to 30. I think it defaults to 60, which seemed to cause problems.
/etc/default/rng-tools
HRNGDEVICE=/dev/TrueRNG RNGDOPTIONS="--fill-watermark=75% --feed-interval=30"
June 19, 2015 at 2:49 pm #1311PROBLEM SOLVED!
1. Your modem blacklisting rule in udev still works. (I read up on that stuff and now understand.)
2. It’s not a TrueRNG bug but a Systemd/Kernel bug. Basically its systemd-udev-settle.service which tries to run but fails if you use a fake block device storage.
!!!!WARNING!!!!
>>>Don’t use my solution if you use LVM! It may damage your system!<<<
You may only use it if you use no fake block device storage OR if you use LUKS encryption.Solution: Masking this service.
systemctl mask systemd-udev-settle
Thanks to everyone who helped me along the way. I learned a lot in the process.
-
This reply was modified 8 years, 5 months ago by
randomly.
-
This reply was modified 8 years, 5 months ago by
-
AuthorPosts
You must be logged in to reply to this topic.