operation not permitted on entropy file
freebsd at edvax.de
Wed Aug 13 08:17:16 UTC 2014
On Tue, 12 Aug 2014 16:34:26 -0700, David Benfell wrote:
> On Tue, Aug 12, 2014 at 07:28:32AM +0200, Polytropon wrote:
> > The text is kept in the console buffer until reboot. Of
> > course saving something to /tmp when you have enabled
> > a cleanup for /tmp isn't optimum. In this case, choices
> > like /root/fsck.txt or even /fsck.txt (for temporary
> > storage) would have been okay.
> I'm learning more about this. Most of my experience is with Linux so
> this is where my assumptions come from. First, I didn't know that
> scroll lock was the secret to being able to scroll back in these text
> mode terminals;
Read. The. Key. Captions. :-)
> second, I didn't know that the arrow keys were then
> the appropriate means for doing so;
And the page scroll keys (Page Up, Page Down) also work. Even Home
(go to last line recorded) and End (go to first line recorded -
note "reverse" orientation) can be used.
> and third, I assumed you had to
> reboot after playing in single-user mode.
This usually is not needed, but of course it deletes the
content of the console buffer. After being one in single
user mode, typically do this:
# mount -a
This will mount all file systems according to /etc/fstab and
then leave the emergency shell, continuing (!) the normal
boot process into multi user mode.
> > For the next time: You can use mdconfig to temporarily
> > allocate a RAM disk, then use script to record the whole
> > console session (including fsck output), afterwards run
> > "mount -a" and copy the log fron the RAM disk to a more
> > permanent place. Just in case.
> This may well be coming. I had roughly 48 good hours. Now, it's
> crashing again. I suppose I can't be surprised if the remaining memory
> card has now gone bad (the vendor is sending me replacements for both,
> despite my saying only one had gone bad).
Check the replacements upon arrival, just to be sure.
Sidenote: I also had problems with a chunk of RAM many years
ago, bought at the local shop. During compiling, at some point
I got a "file not found" error for /uss/src/usr.bin/bla/something.
See? /uss, not /usr! After examining the RAM with a memtest CD,
I found two "defective bits", and 'r' and 's' only differ by
that bit. I made a hardcopy of the memtest screen and took this
to the shop. They immediately replaced the RAM, and the computer
would never complain again. :-)
> I realized I had a 32GB partition available for use as a swap
> partition. I had deviated from the default installation by allocating
> an EFI partition. It's manifestly clear that this is not needed. And
> it's more than large enough (actually about twice the needed size) for
> a complete memory dump (I'm presently running on 8GB, but the
> specification is for 16GB). I've gone in with gdisk and changed that
> partition's type, so hopefully the next time, I'll actually get a
> Not that I've figured out what to do with one once I have it.
Just keep in mind you have it. You never know. And having swap
is better than _not_ having swap, no matter how much RAM you
have. Just open a web browser, open some tabs with "Flash" crap
in it, and you'll see how far you get with lousy 8 GB RAM. :-)
> Having changed that file sytem type, it wanted me to reboot. So I did,
> and while doing so, went into single user mode to do fsck -fy. The
> first pass was not clean; but all the messages were about stuff at the
> end. I don't remember it all, but there are something like four things
> here, including some sort of bit map. It seems to be about at least
> part of how the file system keeps track of allocated and unallocated
In most cases, different kinds of errors appear during one fsck
run (related to different aspects of the file system internals).
> I've already turned off background_fsck, but it seems to do a fast
> fsck anyway.
That is correct and intended. A short file system check is _always_
performed, it's a "preen", where minor defects can be repaired
without interaction. A full fsck run can eliminate all problems,
but in hard cases, it requires user interaction for human decisions,
because -y isn't _always_ what you want.
See /etc/rc.d/fsck for what happens at boot related to fsck.
See "man fsck" for more descriptions about the mentioned "modes".
> Right now, at least, that seems undesirable. Is there a
> way to force it to be more thorough?
Not needed. If there _really_ is something wrong with the file
system, first a "preen" run will be done anyway. If that fails,
which implies there are some significant inconsistencies, a
normal fsck will be performed in the foreground as intended.
If it succeeds, booting will continue. If major defects appear,
the user will be prompted to re-run fsck until the file systems
can be marked "clean". Only if _this_ requirement is met, the
normal boot process can continue! Again, this is intended.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions