Date: Wed, 13 Aug 2014 10:17:13 +0200 From: Polytropon <freebsd@edvax.de> To: David Benfell <benfell@parts-unknown.org> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: operation not permitted on entropy file Message-ID: <20140813101713.9fd24296.freebsd@edvax.de> In-Reply-To: <20140812233426.GA25757@home.parts-unknown.org> References: <20140810124433.da498898.freebsd@edvax.de> <20140810224038.GD24036@home.parts-unknown.org> <20140811101822.41851cc7.freebsd@edvax.de> <20140811142707.GA10186@home.parts-unknown.org> <CA%2BtpaK2RC0w7Y4etxs%2Byx59_gAURNEtB38h=sV8pEFkBRWVFWQ@mail.gmail.com> <20140811171653.b7c60e58.freebsd@edvax.de> <20140811153535.GA30506@home.parts-unknown.org> <20140811183912.ef0f20a6.freebsd@edvax.de> <20140812022709.GA84770@home.parts-unknown.org> <20140812072832.da0166dc.freebsd@edvax.de> <20140812233426.GA25757@home.parts-unknown.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 # exit 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 > dump. > > 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 > blocks. 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. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140813101713.9fd24296.freebsd>