Frandom is a fast random number generator. Is there a chance that gentoo includes it in portage? Thanks Reproducible: Always
Are you talking about http://sourceforge.net/projects/frandom/ which had last release more than 1200 days ago, with version 1.0 and release highlight being Linux 2.6.19 support? I think you might want to reconsider your request...
(In reply to comment #1) > Are you talking about http://sourceforge.net/projects/frandom/ which had last > release more than 1200 days ago, with version 1.0 and release highlight being > Linux 2.6.19 support? > > I think you might want to reconsider your request... > That version, yes :) I've tried it on a 2.6.33 kernel and works, and the algorithm is based on RC4 so I don't see a reason for not supporting it. Of course, you may not agree with this, and in that case I'll write an ebuild for my personal use. The only thing that fails on my ebuild attempt is that if I put emake (or make), it's translated to 'make -C /lib/modules/2.6.33-gentoo-r2/build SUBDIRS=/var/tmp/portage/sys-kernel/frandom-1.0/work/frandom-1.0 modules' (which fails) and I don't know how to do that 'make' means 'make'. Is there any documentation that I can read? Thanks. PS: Sorry for my English.
(In reply to comment #2) > (In reply to comment #1) > > Are you talking about http://sourceforge.net/projects/frandom/ which had last > > release more than 1200 days ago, with version 1.0 and release highlight being > > Linux 2.6.19 support? > > > > I think you might want to reconsider your request... > > > That version, yes :) I've tried it on a 2.6.33 kernel and works, and the > algorithm is based on RC4 so I don't see a reason for not supporting it. > Of course, you may not agree with this, and in that case I'll write an ebuild > for my personal use. Ah, I didn't know you had tested it on something new... it's ok then!
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Are you talking about http://sourceforge.net/projects/frandom/ which had last > > > release more than 1200 days ago, with version 1.0 and release highlight being > > > Linux 2.6.19 support? > > > > > > I think you might want to reconsider your request... > > > > > That version, yes :) I've tried it on a 2.6.33 kernel and works, and the > > algorithm is based on RC4 so I don't see a reason for not supporting it. > > Of course, you may not agree with this, and in that case I'll write an ebuild > > for my personal use. > > Ah, I didn't know you had tested it on something new... it's ok then! > I was unable to load the lkm, but it seems to compile fine.
I've installed it by hand doing this: install -D frandom.ko /lib/modules/$(uname -r)/kernel/drivers/misc/frandom.ko depmod -a modprobe frandom mknod /dev/frandom c 235 11 mknod /dev/erandom c 235 12 chmod 444 /dev/frandom /dev/erandom I've based the execution on the AUR (from Archlinux) frandom package. Thank you very much for doing this :)
Created attachment 236567 [details] ebuild proposal for frandom-1.0.ebuild as sys-apps/frandom Well I was bored, so I read linux-mod.eclass, and here is an ebuild. It compiles, install, merges fine, repoman likes it. Uses mirror:// to fetch. I added the necessary udev rules for the lkm. /dev/frandom is really damn fast on my system, able to generate 1GB of pseudo-random data at 188MB/s.
Created attachment 236577 [details] ebuild proposal for frandom-1.0.ebuild as sys-apps/frandom New improved version: * use ${KV_FULL} rather than the Makefile's uname -r invocation * a few other changes
(In reply to comment #7) > Created an attachment (id=236577) [details] > ebuild proposal for frandom-1.0.ebuild as sys-apps/frandom > > New improved version: > * use ${KV_FULL} rather than the Makefile's uname -r invocation > * a few other changes > I've tried the first version of the ebuild, and no frandom nor erandom devices are created. Does the ebuild need to call mknod?
I *think* you might just have to restart udev and then modprove the module. Or modprobe and restart.
(In reply to comment #9) > I *think* you might just have to restart udev and then modprove the module. Or > modprobe and restart. > I've rebooted the machine and I've done a modprobe and a "/etc/init.d/udev restart" with no luck... Anyway, thank you very much for the good job, doing a mknod by hand doesn't hurt :)
Created attachment 241895 [details] frandom-1.0.ebuild (In reply to comment #10) > (In reply to comment #9) > > I *think* you might just have to restart udev and then modprove the module. Or > > modprobe and restart. > > > > I've rebooted the machine and I've done a modprobe and a "/etc/init.d/udev > restart" with no luck... Anyway, thank you very much for the good job, doing a > mknod by hand doesn't hurt :) Got the same issue. Devices are missing, so I just made myself a little udev rule for this. Don't know if those magic lines under "vboxdrv" comment should do the trick, but looks like they don't.
Created attachment 241897 [details] frandom/frandom-1.0.ebuild This is the correct attachment. (:
Created attachment 241899 [details] frandom/files/60-frandom.rules And udev rules.
Created attachment 285447 [details] Working ebuild for version 1.1 Just needed to change the URI from earlier ebuild...
Created attachment 285461 [details] frandom-1.1.ebuild I did some more changes. We should use .rules file from the tarball as it seems to work fine.
Don't know if that's the reason, but looks like i found a bug in frandom. Kernel configured with CONFIG_SLUB=y works fine, but with CONFIG_SLAB=y (changing SLAB allocator) loading the module ends like this: insmod: error inserting '/lib/modules/3.2.1/misc/frandom.ko': -1 Unknown symbol in module dmesg gives a hint: [ 635.150632] frandom: Unknown symbol kmalloc_caches (err 0) Could someone try it? (if frandom has some users here… ;)
Created attachment 316223 [details] Updated; changed to install udev rules to /lib/udev/rules.d
The package works still with the current kernels. There are two things to fix about it though. Firstly, installing into /etc/udev/rules.d/10-frandom.rules should be replaced by /lib/udev/rules.d/10-frandom.rules (the new location, as I got a message in that sense on booting). Secondly and, possibly, most importantly, I got my 3.5.4-hardened kernel at booting today complain that: udev[1044]: Name="%k" is ignored because it breaks kernel supplied names, please remove it from /etc/udev/rules.d/10-frandom.rules:8 I currently have not time to study the matter and possibly learn how to do it, but I hope someone of you big Gentoo guys can do it in a matter of few minutes. Hopefully! (and if I am not asking too much, I had to copy manually the message of today. Turning on debugging would be too much output, esp. because grsec.log itself carries much, but how do I get the messages at booting, without too much output, just those that I see at booting, written down in some logs. Is there a simple way? Of course, if I am not asking too much. Thanx!) I used this unsigned ebuild to make a page on building ebuilds for absolute beginners: http://en.gentoo-wiki.com/wiki/Talk:Writing_Ebuilds Cheers!
Works fine here with linux 3.12.0-rc5. The only thing is a QA notice: * QA Notice: udev rules should be installed in /lib/udev/rules.d: * etc/udev/rules.d/10-frandom.rules Speed comparison on my "Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz": /dev/urandom: ~ 13MByte/s /dev/frandom: ~200MByte/s Thanks for the ebuild, awesome piece of software!
Works fine on Linux 4.0.9. This module is so useful that it deserves to be made part of the default patches applied to the kernel, not as a separate package (though this option should not be excluded).
^ I installed it by following instructions in the frandom package, not by using the ebuild.
ebuild is working, too.
I honestly have no idea why anyone wants this, but it's in portage now.
