es ===> arch/x86_64
Given a quick look at the Makefile in that directory I'm guessing it
needs to be re-written to serialize the build of the three headers
gthr.h, gthr-single.h, and gthr-posix.h, but I'm not sure exactly how to
accomplish that in this context.
--
At Fri, 10 May 2019 13:02:05 -0700, "Greg A. Woods" wrote:
Subject: Re: "route_enqueue: queue full, dropped message" blast from a 8.99.32
amd64 domU
>
> During normal operation I see just over 8000/s (and with the console
> spewing there are only about 200/s more
At Wed, 11 Dec 2019 17:25:17 -0800, "Greg A. Woods" wrote:
Subject: unable to boot amd64-uefi-install from USB stick on a MacBook2,1
>
> However no matter which option I selected, including a "boot netbsd -vs"
> from the boot prompt, would do anything more than
At Thu, 9 Jan 2020 01:19:39 +0100, Joerg Sonnenberger wrote:
Subject: Re: unable to boot amd64-uefi-install from USB stick on a MacBook2,1
>
> On Wed, Jan 08, 2020 at 04:08:40PM -0800, Greg A. Woods wrote:
> > However in searching related things I just came across a reminder abou
kes the cursor disappear, but does not finish the shutdown).
However still nothing is printed on the console by the kernel.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgps7RkY6Z0Ct.pgp
Description: O
t 5MB/s). (Unfortunately the ufs.kext in the
latest macOS 10.6.8 that'll run on this machine won't mount NetBSD a
filesystem.)
The next best would be to examine the diffs between 7.99.5 and 8.0 I
guess, but I'm not too sure where to start.
--
many people have kept intermediate builds or
build products from so long ago.
Anyway that's why I guess the problem appeared between 7.99.5 and 8.0
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc.
system, and so
the chances of me making it support filesystem writing is unlikely.
Has anyone by any chance ported the real UFS code (e.g. using libukfs)
to work with (OSX)FUSE on a foreign platorm?
--
Greg A. Woods
Kelowna, BC +1 250 762-7675
At Thu, 23 Jan 2020 15:38:27 -0800, "Greg A. Woods" wrote:
Subject: Re: unable to boot amd64-uefi-install from USB stick on a MacBook2,1
>
> At Thu, 23 Jan 2020 06:56:26 +, m...@netbsd.org wrote:
> Subject: Re: unable to boot amd64-uefi-install from USB stick on a Mac
. I.e. multiuser boot worked A-OK.
Does any of this look even remotely familiar to anyone else?
Oh, and note also that my build was done with:
CPUFLAGS = -march=i586 -mtune=pentiumpro
I'll try another build with no CPUFLAGS, and if that similarly fails
I'll try a stock offic
x.html
Perhaps you could point to a specific thread or message?
I've never found anything there explaining the actual rationale for Hg.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpjjXGdb
At Wed, 22 Apr 2020 21:08:46 -0700, "Greg A. Woods" wrote:
Subject: odd behaviour of some programs on i386 cross-built from amd64
>
> # od
> od: "8/2 " %06o " "\n"": bad format
> # file /usr/bin/od
> /usr/bin/od:
At Mon, 27 Apr 2020 21:17:04 -0700, "Greg A. Woods" wrote:
Subject: Re: odd behaviour of some programs on i386 cross-built from amd64
>
> One of the kernels seems to be the same too, assuming one takes into
> account the obvious difference in vers.o:
>
>textdat
At Tue, 28 Apr 2020 16:05:10 -0700, "Greg A. Woods" wrote:
Subject: Re: odd behaviour of some programs on i386 cross-built from amd64
>
> I guess now I'll have to dig into my local kernel changes to see what
> might be incompatible with a 32-bit system. Maybe I can also t
the whole
tree with the original error to make that less arduous to do. Oh well,
I guess it only takes about 4 hours on my speediest build machine.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpL_axIbcpDS.pgp
Description: OpenPGP Digital Signature
rces, but
there's also some ongoing doubt about this.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpZVBBmAGt5E.pgp
Description: OpenPGP Digital Signature
At Wed, 13 May 2020 07:53:28 +0200, Thomas Klausner wrote:
Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>
> On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote:
> > For one, Mercurial has no staging area. That removes one level of
> >
ting metadata for those changes, to the upstream project's
repository.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpZCTTBhVeGA.pgp
Description: OpenPGP Digital Signature
At Wed, 13 May 2020 21:30:29 +0200, Joerg Sonnenberger wrote:
Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>
> On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote:
> > At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote:
> >
> &g
y that -- a history
meant to be read and remembered by the humans who come afterwards.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpcF6DD4_705.pgp
Description: OpenPGP Digital Signature
same time), not why (nor how the decision was arrived at).
> > I've never found anything there explaining the actual rationale for Hg.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
ere, and how do I find it without carefully
reading everything related?
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpOBR7Sog1Gx.pgp
Description: OpenPGP Digital Signature
did indeed think LOCKDEBUG was
supposed to be a kernel-only option (thus my mistaken assumption that
defining it globally would be OK).
I don't remember what the downtime was on that i386 before I restarted
it recently, but it would have been several years -- before rump no
doubt.
--
B _glapi_tls_Context
0008 B _glapi_tls_Dispatch
U stub_init_once
U table_noop_array
T u_current_destroy
0001 T u_current_init
0002 T u_current_set_context
002c T u_current_set_table
--
At Mon, 01 Jun 2020 21:29:34 -0700, "Greg A. Woods" wrote:
Subject: static linking glxgears and glxinfo now fails (mult. def.
_glapi_tls_Context, etc.)
>
> Perhaps common "global" variables in TLS aren't being merged by the
> linker? Maybe I can/should just tu
lxcurrent.c (i.e. as
opposed to just declarations so they can properly share the same storage
with the instances defined in u_context.c). I'm not knowledgeable
enough about all the compiler and linker magic that makes TLS work to
know one way or another.
--
xbd4: using event channel 12
...
boot device: xbd4
root on xbd4a dumps on xbd4b
root file system type: cd9660
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpyhCAjH0HNg.pgp
Description: OpenPGP Digital Signature
At Tue, 9 Jun 2020 00:00:17 +0200, Manuel Bouyer wrote:
Subject: Re: regression: xen domU no longer supports "type=cdrom" vbd disk
>
> On Mon, Jun 08, 2020 at 02:26:39PM -0700, Greg A. Woods wrote:
> > I use xl.cfg "disk" entries like the following to mount a
e_ first asking what sets to install and
then that the default selected sets would never include ones that are
not available (though selecting an unavailable one could still work and
ask you separately where to get it from instead) and a "full
installation" would just try t
At Thu, 23 Jan 2020 15:38:27 -0800, "Greg A. Woods" wrote:
Subject: Re: unable to boot amd64-uefi-install from USB stick on a MacBook2,1
>
> At Thu, 23 Jan 2020 06:56:26 +, m...@netbsd.org wrote:
> Subject: Re: unable to boot amd64-uefi-install from USB stick on a Mac
At Sat, 18 Jan 2020 19:37:03 -0800, "Greg A. Woods" wrote:
Subject: Re: unable to boot amd64-uefi-install from USB stick on a MacBook2,1
>
> Now the video mode changes (to full-screen, with a solid large block
> cursor, as opposed to the small box of text centred on the screen
At Tue, 09 Jun 2020 21:02:08 -0700, "Greg A. Woods" wrote:
Subject: Re: unable to boot amd64-uefi-install from USB stick on a MacBook2,1
>
> Now I end up with sometimes a hang after it prints a bunch of addresses
> in a mem[] array, but other times it loads the kernel and dis
At Tue, 09 Jun 2020 22:01:41 -0700, "Greg A. Woods" wrote:
Subject: unable to boot NetBSD-9.99.64-amd64-install.img on a MacBook7,1
>
> Most interestingly if I do some playing at the boot prompt first such
> that there is lots of white text in the small centre area, then try t
quot; should more generically be called.
We do have one example of such lists already supported in NetBSD:
/etc/hosts.allow and /etc/hosts.deny
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpXkBT7UamvB.pgp
Description: OpenPGP Digital Signature
At Sat, 13 Jun 2020 22:03:39 -0700, "Greg A. Woods" wrote:
Subject: Re: unable to boot NetBSD-9.99.64-amd64-install.img on a MacBook7,1
>
> At Tue, 09 Jun 2020 22:01:41 -0700, "Greg A. Woods" wrote:
> Subject: unable to boot NetBSD-9.99.64-amd64-install.img
nly protects things installed via pkgsrc, and there's still
the risk of subsequently needing to install a binary package built for
an older release which needs one of these "obsolete" files, but at least
pkg_add can (be made to if it doesn't already) notice this and abor
.
sd0 at scsibus0 target 0 lun 0: disk fixed
sd0: 465 GB, 476416 cyl, 64 head, 32 sec, 512 bytes/sect x 975699968 sectors
sd1 at scsibus0 target 1 lun 0: disk fixed
sd1: 544 GB, 557568 cyl, 64 head, 32 sec, 512 bytes/sect x 1141899264 sectors
--
Gr
At Wed, 01 Jul 2020 17:57:08 -0700, "Greg A. Woods" wrote:
Subject: weird occasional "Resource exhaustion" errors when linking
GENERIC_KASLR
>
> I've been using a stock 9.0 amd64 install to build my -current tree and
> found it failing with a "Resource e
193342.396989] dk6 at sd2: "EFI system", 262144 blocks at 2048, type: msdos
[ 193342.396989] dk7 at sd2: "d3aa0396-d911-4aac-baa8-f2478557d31a", 7544832
blocks at 264192, type: ffs
I'm guessing it's a software bug with bad locking order somewhere.
--
at such a thing might be a bit hard to arrange for in NetBSD.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpvllmWWoiDK.pgp
Description: OpenPGP Digital Signature
el console. E.g. on an EFI system, perhaps through a custom EFI
driver? And for uBoot systems too?
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpFUqYZ0ZSmB.pgp
Description: OpenPGP Digital Signature
f difference.
Thank you for the idea though, and also thank you for pointing out the
alternate framebuffer driver that might also be worth looking into.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
FLAGS STRUCT LWP * NAME WAIT
29079>29079 7 0 100 8693578524c0 tpgsqltime
I do have a full kernel core dump, but it's 32GB (345M compressed), and
probably contains data I don't want to share.
--
Gre
At Mon, 06 Jul 2020 13:13:03 -0700, "Greg A. Woods" wrote:
Subject: Re: NetBSD-7.0 boots OK and NetBSD-8.0 hangs/crashes during boot on a
MacBook7,1
>
> Or indeed any device with any kind of USB port, e.g. a laptop.
Oh, and I wanted to mention something else that I'
At Thu, 09 Jul 2020 18:16:26 -0700, "Greg A. Woods" wrote:
Subject: USB console support "was: NetBSD-7.0 boots OK and NetBSD-8.0
hangs/crashes during boot on a MacBook7,1)
>
> Oh, and I wanted to mention something else that I'd forgotten about but
> stumbled acr
o dump, not enough free space in /var/crash
$ df -h /var/crash/
FilesystemSize Used Avail %Cap MountedOn
/dev/dk2 3.9G 1.5G 2.2G 40% /var
At Thu, 09 Jul 2020 18:03:23 -0700, "Greg A. Woods" wrote:
Subject: is this crash while coredumping to NFS
ot/shells/heirloom-sh/work/heirloom-sh-050706/mapmalloc.c:303:
first defined here
Should I send-pr this? Is there any possibility of an "easy" fix?
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote
At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote:
Subject: Re: recent changes to pthread_fork.c:fork() cause static linking to
fail if the app provides its own malloc()
>
> On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
> > I think it is the following
g on what the internal malloc() uses
to obtain heap space).
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpKFk8TXbGnF.pgp
Description: OpenPGP Digital Signature
At Sat, 11 Jul 2020 23:29:05 -0700, "Greg A. Woods" wrote:
Subject: Re: is this crash while coredumping known? (forget the link to NFS)
>
> So it doesn't seem like this crash has anything to do with NFS after all.
This crash is ongoing for me.
I'll be away for a coup
lel (e.g. if ${.MAKE.JOBS} is set and
greater than one in the makefile then pass a '-j ${.MAKE.JOBS}' option
to the script).
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp1PW6p7nzys.pgp
Description: OpenPGP Digital Signature
op.
nbmake: stopped in /work/woods/m-NetBSD-5/tools/gcc
Note there are also lots of other new warnings from a newer compiler
building the older toolchain!
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp9gBzANraAN.pgp
Description: OpenPGP Digital Signature
ods/m-NetBSD-current-new/external/bsd/libc++/lib";
/build/woods/b2/current-amd64-amd64-tools/bin/nbmake realall
*** Error code 1
Stop.
nbmake: stopped in /work/woods/m-NetBSD-current-new/external/bsd/libc++/lib
11:32 [102] $ mynbmake -v MKDEBUG
yes
11:32 [103] $ mynbmake -v MKD
_t *ptc_mutex; /* Current mutex */
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpyKO6vyn83x.pgp
Description: OpenPGP Digital Signature
id argument
tc-se:
tc-end: 1615494985.880185, ulimit_redirection_interaction, failed, atf-check
failed; see the output of the test for details
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpg
2943 ffs
dkctl: /dev/mapper/rvg0-nbtest.0: addwedge: Inappropriate ioctl for device
So it looks like I'm back to using plain MBR for domUs again, at least
for my next round of Xen server rebuilds.
--
Greg A. Woods
Kelowna, BC +1 250 762-7
ug printfs to the shell too, but I'm currently
stymied by another problem (I can't access the domU filesystem from the
dom0, and until I can get a complete rebuild to finish so I can do a
full reinstall of the domU, accessing the FS from the dom0 would be the
only easy way I have of injecti
orced (i.e. if the ulimit for
open FDs is not kept lower than the number of currently open FDs);
though I have not done any other kind of test to be sure the data sent
to a multi-digit FD is actually received from the given FD.
--
Greg A. Woods
Ke
on up an xbd0
to try this again on a newer, and less critical, Xen server.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpMHuyGSLKTh.pgp
Description: OpenPGP Digital Signature
${CTFCONVERT_RUN}
+ ${COMPILE_LINK.c} -o ${.TARGET} y.tab.c ${LDLIBS}
+# XXX: disable for now
+# ${CTFCONVERT_RUN}
rm -f y.tab.c
.y.c:
${YACC.y} ${.IMPSRC}
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpPGRHrsBSaZ.pgp
Description: OpenPGP Digital Signature
At Sun, 21 Mar 2021 16:44:31 -0700, "Greg A. Woods" wrote:
Subject: sys.mk broken for single-suffix rules since 1.144 (2021/11/09)
Sorry, make that 2020/11/09, of course :-)
Also this only applies to a few platforms (i386, x86_64, and aarch64),
and when the Makefile used someh
een some interaction with other third-party Makefiles (probably none
within NetBSD itself though, though of course I'll have to scan my tree
just to be sure I haven't forgotten fixing something somewhere).
--
Greg A. Woods
Kelowna, BC
that code is doing and why.
> ps: attempting to follow fd usages inside sh
> is not something for the faint of heart.
Indeed. As I was staring at it a couple of weeks ago I was
coincidentally reminded of Gosling Emacs -- maybe that sh code could
borrow Gosling's skull and crossed bones co
/robohack/experiments/blob/master/tintervals-merge.py
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpGgb2m4wtXQ.pgp
Description: OpenPGP Digital Signature
ng
machine
At least on this next reboot all the right versions of the right bits
started!
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpNLASee644w.pgp
Description: OpenPGP Digital Signature
2021]exec: mount_ffs -o rw /dev/dk2 /var
[Wed Mar 24 20:49:30 2021]/dev/dk2 on /var type ffs (local, fsid: 0xa802/0x78b,
reads: sync 1 async 0, writes: sync 2 async 0)
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpeOBU3AaVgV.pgp
Description: OpenPGP Digital Signature
lf._config = {'authkey': AuthenticationString(os.urandom(32)),
KeyboardInterrupt
*** Error code 1 (ignored)
*** Signal 2
*** Signal 2
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpWjPEXKgaka.pgp
Description: OpenPGP Digital Signature
f entropy
[ 579202.264290] entropy: pid 7248 (cat) blocking due to lack of entropy
[ 579669.831978] entropy: ready
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
At Tue, 30 Mar 2021 10:06:19 -070
At Tue, 30 Mar 2021 23:53:43 +0200, Manuel Bouyer
wrote:
Subject: Re: nothing contributing entropy in Xen domUs? (causing python3.7
rebuild to get stuck in kernel in "entropy" during an "import" statement)
>
> On Tue, Mar 30, 2021 at 02:40:18PM
y,
and I tried to enable one and was given a nice error message about this
not being possible, then I would have looked elsewhere to find out how
to give the system more bits of entropy. As is in my Xen domU system
the output of "rndctl -l" leads me to believe all of my devices are
coll
, v
# sysctl kern.entropy
kern.entropy.collection = 1
kern.entropy.depletion = 0
kern.entropy.consolidate = -23552
kern.entropy.gather = -23552
kern.entropy.needed = 256
kern.entropy.pending = 0
kern.entropy.epoch = 19
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpMsnaVWfOo5.pgp
Description: OpenPGP Digital Signature
how to seed it -- but that's not the problem -- the hardware
should be providing plenty of entropy.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpfwaVZQJ63E.pgp
Description: OpenPGP Digital Signature
rs, &value, sizeof value, sizeof value * NBBY);
}
void
_rnd_add_uint64(struct krndsource *rs, uint64_t value)
{
- rnd_add_data(rs, &value, sizeof value, 0);
+ rnd_add_data(rs, &value, sizeof value, sizeof value * NBBY);
}
/*
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp_AompQk1f3.pgp
Description: OpenPGP Digital Signature
s_mountroot pointer).
So I'm lost -- any hints? Is it from bounds_check_with_label()? How?
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp1QhMimCiG1.pgp
Description: OpenPGP Digital Signature
At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > Date: Sat, 03 Apr 2021 12:24:29 -0700
> > From: "Greg A. Woods"
> >
> > Updating a system, even on -current, shouldn't c
;m sure they
> can be picked by someone who knows what they're doing, and better security
> is available, at a price, but a nice happy medium is what fits me best.
Indeed again.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 R
data is generated even
>if the Entropy Source is not operating as well as predicted.
"design" != implementation
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpg86syab6rB.pgp
Description: OpenPGP Digital Signature
sc_info & VDISK_READONLY))
- return EROFS;
+ return EACCES;
DPRINTF(("xbdopen(%" PRIx64 ", %d)\n", dev, flags));
return dk_open(&sc->sc_dksc, dev, flags, fmt, l);
--
Greg A. Woo
e code I fixed with my patch that was at fault.
I told the system to "count" the entropy being gathered by the
appropriate driver(s), but it was being ignored entirely.
After my fix the system behaved as I told it to.
--
Greg A. Woods
Kelowna, BC
rom various devices that my systems (virtual and real)
actually have.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpkw5j9Fv1Vg.pgp
Description: OpenPGP Digital Signature
D
> will however be ... a more challenging problem.
Leaving things like that would be totally silly.
With my patch the old way of gathering entropy from devices works just
fine as it always did, albeit with the second patch it does require a
tiny bit of extra configuration.
--
chines, I don't have any worry
whatsoever at the moment about one VM guest spying on, or influencing
the PRNG, in another. Zero worry. They're all _me_. I don't need some
theoretically perfect level of protection from myself.
--
Gr
device drivers that could feed sufficiently random data to
the entropy pool, and then to recommend a suitable value for
rndctl_flags in /etc/rc.conf.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp1Of0SebF9S.pgp
Description: OpenPGP Digital Signature
kernel's behaviour to match the documentation and tools
(specifically rndctl). That the core of it it is just a two-line patch
makes this fix extremely satisfying.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc.
might be hiding out in my garage.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgps8MDVICM_D.pgp
Description: OpenPGP Digital Signature
printf("entropy: pid %d (%s) blocking due to lack of
entropy\n", /* xxx uprintf() instead/also? */
curproc->p_pid, curproc->p_comm);
if (ISSET(flags, ENTROPY_SIG)) {
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpF1LIq_XrV5.pgp
Description: OpenPGP Digital Signature
ead-only when necessary. An attempt to open a wedge
> read-write on a read-only opened parent device then has to fail.
Yes, this makes sense.
> I'm testing a patch for that...
Excellent! Thank you very much!
--
Greg A. Woods
Kelowna, BC
the system already has. If interrupted, either
the old seed or the new seed will be in place.
The code seems to concur.
Also the system re-saves the $random_file via /etc/security
(unconditionally, i.e. always, but only if $random_file is set).
--
put a "sleep 30" or whatever in
front of it and hope that's enough and that it's still not too
predictable.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpRUdV5ZZmgF.pgp
Description: OpenPGP Digital Signature
At Mon, 5 Apr 2021 15:37:49 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> >
> > BTW, to me reusing the same entropy on every reboot seems less secure.
>
&g
needed: (no description)
17:27 [1.832] # sysctl -d kern.entropy.pending
kern.entropy.pending: (no description)
17:27 [1.833] # sysctl -d kern.entropy.epoch
kern.entropy.epoch: (no description)
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp6vc6Eur6UN.pgp
Description: OpenPGP Digital Signature
tly seeing
would be one step closer, and should be extremely easy.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpOxcINx3I65.pgp
Description: OpenPGP Digital Signature
At Tue, 6 Apr 2021 20:21:43 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> >
> > And the stock implementation has no possibility of ever providing an
> > in
At Wed, 7 Apr 2021 09:52:29 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 03:12:45PM -0700, Greg A. Woods wrote:
> > > Isn't it as simple as:
> > >
> > > dd bs=32 if=/dev/urandom
ces, and
that's also a situation that includes many of us.
It doesn't have to be the default.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpiP2WuJhrQy.pgp
Description: OpenPGP Digital Signature
PERBLOCKS? [yn] n
ADD CYLINDER GROUP CHECK-HASH PROTECTION? [yn] n
** Last Mounted on
** Root file system
** Phase 1 - Check Blocks and Sizes
PARTIALLY TRUNCATED INODE I=28
SALVAGE? [yn] n
PARTIALLY TRUNCATED INODE I=112
SALVAGE? [yn] ^Cda0: disk error cmd=write 8145-8152 status: fffe
#
* FILE SYSTEM MARKED DIRTY *
#
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgp0TQ7zS9Hhk.pgp
Description: OpenPGP Digital Signature
ere.
There's a definite pattern of corruption anyway -- I just can't explain
it well enough yet.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpX0mMSVXy0W.pgp
Description: OpenPGP Digital Signature
Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
32740 files, 2349557 used, 1431650 free (538 frags, 178889 blocks, 0.0%
fragmentation)
--
Greg A. Woods
Kelowna, BC +1 250 762-7675
f:789520 1601 4.2BSD 0 0 0 # (Cyl. 0*-386*)
disklabel: boot block size 0
disklabel: super block size 0
# fsck -n /dev/vnd0f
** /dev/rvnd0f (NO WRITE)
BAD SUPER BLOCK: CAN'T FIND SUPERBLOCK
/dev/rvnd0f: CANNOT FIGURE OUT SECTORS PER CYLINDER
--
At Sun, 11 Apr 2021 13:23:31 -0700, "Greg A. Woods" wrote:
Subject: one remaining mystery about the FreeBSD domU failure on NetBSD
XEN3_DOM0
>
> In fact it only seems to be fsck that complains, possibly along
> with any attempt to write to a filesystem, that causes problems.
1 - 100 of 203 matches
Mail list logo
