mounting errors

David Henderson dhenderson at digital-pipe.com
Mon Feb 27 15:57:03 UTC 2017


Thanks for the follow-up Jody.  I guess I have no choice but to do so...

Dave


On 2/24/17, Jody Bruchon <jody at jodybruchon.com> wrote:
> On 2017-02-24 08:49, David Henderson wrote:
>> Thanks for the tip Rob!  So it looks like my only resolution to this
>> problem is the dmesg silencing?  The only issue I see with that is
>> that perhaps something I need to see won't get shown.
> Setting the level higher will restrict immediate console output to more
> and more critical messages only; since I administer all of my machines
> remotely, I tend to see zero console logging and find that the rare
> instances I have console logging going on, the messages tend to mangle
> program output or the command I'm typing when I least expect it.
> Increasing the urgency threshold for console logging will allow truly
> severe problems like a disk command failure to still be logged to the
> console while preventing simple warnings from polluting the console. I
> prefer to run dmesg manually to read these warnings.
>
> I look at it this way: if there's a problem then someone will go out of
> the way to read the logs and see what warning messages are present, but
> if there's not really a problem (as in this case) they'll never see the
> messages because the operation succeeded.
>
> An example I run into a lot: if you mount a journaled HFS+ filesystem it
> will force it to be read-only unless you pass '-o rw,force' and a kernel
> warning will be logged saying so. I don't see that on my console, but
> when I try to write to the filesystem I'll get an error and see the
> warning message when I run dmesg. Then I know to umount, mount -o
> rw,force, and resume working as usual.
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>


More information about the busybox mailing list