On Tue, Jun 28, 2016 at 6:24 AM, Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > On Sun, Jun 26, 2016 at 12:33 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> > wrote: >> >> >> On Sat, Jun 25, 2016, 8:26 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: >>> >>> I recently upgraded my wife's laptop to an Acer with a fairly stock >>> i5-6200U system using the UFEI boot (that was an adventure) >>> >>> About a month ago I started getting strange issues. Not lockups per se >>> but it seems that the drive is somehow going into read only. Since that's >>> the case after it starts nothing is getting written to disk (includes >>> journal entries). >> >> >> Include rd.break=pre-mount as a boot parameter. Then manually mount the >> root volume to /sysroot >> >> There may be messages in the same console, or you may need to use dmesg. >> Screen capture those error messages. > > > That laptop actually boots and about half the time it makes it through the > whole day before it goes on the fritz... It looks like your suggestion is if > the volume was always readonly... At a minimum we need kernel messages for when it's misbehaving to get an idea why the fs is mounting read only. The journal is even better, but if at boot time the system will not mount rootfs rw, then the journal can't be written to stable media and is lost on a hard reset. >From a successful boot you could do 'systemctl enable debug-shell.service' which will get you a console on tty9 much much earlier in the boot process, where maybe if you end up in this read only state again, you can switch to tty9 and write out the current boot journal to a thumb drive or even to the /boot partition by mounting it somewhere. Another option is to let us know what file system this is, and what results you get if you boot from Fedora install media, and run a file system check on the root file system. > An additional quirk I discovered, most of the time I can attempt a ssh > connection but it doesn't matter which user I try, it always says it's a bad > password even though I'm sure it's correct. In that case it's file corruption. Could be a slowly imploding file system. Could be a slowly dying drive that's returning spurious data. So in addition to a file system check, you could supply the results from 'smartctl -x /dev/sdX' And still another thing you could do is grab a few days worth of journal using 'sudo journalctl --since=-3days > journal_3days.log' and put that up somewhere and post the URL here. Maybe there are clues of what the problem is buried in a successful boot where there was a read write root. -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
