Re: odd /dev/random behavior with dd ?
> Hi, 'dd' seems to behave different if the 'if' is /dev/random > than if it is anything else, e.g. /dev/zero: > > # sh > # dd if=/dev/zero of=zero.out bs=65536 count=1 > 1+0 records in > 1+0 records out > 65536 bytes transferred in 0.001 secs (65536000 bytes/sec) rnd(4) says: Applications should read from /dev/urandom, or the sysctl(7) variable kern.arandom, when they need randomly generated data, e.g. key material for cryptography or seeds for simulations. (The sysctl(7) variable kern.arandom is limited to 256 bytes per read, but is otherwise equivalent to reading from /dev/urandom and always works even in a chroot(8) environment without requiring a populated /dev tree and without opening a file descriptor, so kern.arandom may be preferable to use in libraries.) I guess the behaviour of kern.arandom is also enforced for /dev/random. "Whoever needs more than 256 bits to seed their crypto algorithm?" /dev/urandom does not, and as long as the rnd subsystem is initialized, it should be equivalent to /dev/random if I understand correctly. Regards, - Håvard
Re: NetBSD_10.0_BETA boot issues
On Wed, Jan 04, 2023 at 02:07:04PM -0600, Robert Nestor wrote: > Be happy to try and provide more info if someone has suggestions. Is this the same machine as in https://gnats.netbsd.org/56737 ? As Rin asked there: we need the full dmesg output of the machine. Martin
Is this normal floppy behavior?
There are a bunch of files on the floppy when mounted; I delete them all; but then, there is a large amount of 'used' space! unmounting + remounting 'fixes' this problem. *# mount_msdos /dev/sd2a /a* *# ls -l /atotal 2drwxr-xr-x 1 root wheel512 Jan 4 13:11 System Volume Information/-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.0*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.1*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.10*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.11*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.12*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.13*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.14*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.15*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.16*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.17*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.18*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.19*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.2*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.20*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:22 six.21*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.3*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.4*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.5*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.6*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.7*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.8*-rwxr-xr-x 1 root wheel 65536 Jan 4 21:21 six.9*-rwxr-xr-x 1 root wheel275 Jan 4 21:22 six.bat*# df -h /aFilesystem Size Used Avail %Cap Mounted on/dev/sd2a 1.4M 1.4M 14K 99% /a# rm -rf /a/*zsh: sure you want to delete all 24 files in /a [yn]? y# ls -l /a# df -h /aFilesystem Size Used Avail %Cap Mounted on/dev/sd2a 1.4M 517K 907K 36% /a# umount /a# mount_msdos /dev/sd2a /a# ls -l /a# df -h /aFilesystem Size Used Avail %Cap Mounted on/dev/sd2a 1.4M 17K 1.4M 1% /a*
odd /dev/random behavior with dd ?
Hi, 'dd' seems to behave different if the 'if' is /dev/random than if it is anything else, e.g. /dev/zero: *# sh # dd if=/dev/zero of=zero.out bs=65536 count=11+0 records in1+0 records out65536 bytes transferred in 0.001 secs (65536000 bytes/sec)# ls -l zero.out-rw-r--r-- 1 root wheel 65536 Jan 4 21:30 zero.out# dd if=/dev/random of=random.out bs=65536 count=10+1 records in0+1 records out32 bytes transferred in 0.001 secs (32000 bytes/sec)# ls -l random.out-rw-r--r-- 1 root wheel 32 Jan 4 21:30 random.out# dd if=/dev/random of=random.out.2 bs=65536 count=20480+2048 records in0+2048 records out65536 bytes transferred in 0.054 secs (1213629 bytes/sec)# ls -l random.out.2-rw-r--r-- 1 root wheel 65536 Jan 4 21:31 random.out.2# uname -aNetBSD arm64 9.99.102 NetBSD 9.99.102 (MIKE64) #0: Wed Oct 26 22:54:20 UTC 2022 mac@arm64:/usr/obj/sys/arch/evbarm/compile/MIKE64 evbarm* Am I doing something stupid? Thanks! Mike
NetBSD_10.0_BETA boot issues
The old problem of IDENTIFY failed and WDCTL_RST failed on the boot disk doesn’t seem to be completely fixed in the current 10.0_BETA builds. When I try to capture the boot output on a serial console it never seems to show up, but when the boot output is sent to the main monitor it seems to fail about 90% of the time. The HW I’m using boots and runs fine with Windows 10, Linux and NetBSD 9.2 using the same disks that show the error in 10.0_BETA, so I’m pretty sure it’s not a disk or other HW problem with my system. Sometimes the boot log shows the “auto configuration error: IDENTIFY failed” and then can’t find any of the partitions on the disk. When this happens it stops because it can’t locate the boot device. Other times it reports this error but then goes on to find the partitions and seems to boot up and run successfully. Usually during boot it reports WDCTL_RST failed and never configures the disk then crashes during the boot sequence. I’ve seen this booting with either BIOS or UEFI, but only with 10.0_BETA and never with 9.2. The system is an HP 6200 with 3 SATA ports. Windows 10 is on a disk on SATA port 0. The boot problem happens regardless of which SATA port the NetBSD disk is attached to. Be happy to try and provide more info if someone has suggestions.
Re: Wiki page review
On Tue, Jan 3, 2023 at 11:54 PM Brook Milligan wrote: > > I have written a page for the NetBSD Wiki on how to build bootable ARM images > using build.sh (see the attached PDF version). Before I commit it, I would > appreciate feedback regarding its clarity and completeness. If anyone is > willing to go through the process described, that would be ideal as a > verification of correctness. > > For now, it is linked under Tutorials -> System; if there is a better > location, please advise. I'm not a fan of the word "concrete" in this context, and it might not translate well to other languages. At the end of the introduction section there is a point that says "Install U-boot boot blocks." For clarity I might say "Install U-boot boot blocks on build system." or add "from pkgsrc" just to try to clarify. Is the list of hardware supported by this method limited to what bootblocks are available through U-boot? If that wasn't answered it might be nice to say it. Otherwise, good stuff. I have some ARM devices and I'm not familiar enough with how they boot. I just get an image from somewhere, write it, and go happily ignorant of how it actually works. I might try my own build for the heck of it now. Andy
