Bug 681856

Summary:	=sys-apps/sysvinit-2.93: /sbin/reboot doesn't cleanly unmount /dev/sdX anymore
Product:	Gentoo Linux	Reporter:	tt_1 <herrtimson>
Component:	Current packages	Assignee:	Gentoo's Team for Core System packages <base-system>
Status:	RESOLVED WORKSFORME
Severity:	normal
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Attachments:	emerge --info

Description tt_1 2019-03-27 11:57:12 UTC

When rebooting my machine from a terminal via 'reboot' (as root), I run into a forced fs.chk on the next boot due to them not unmounted cleanly before. Journal has to be restored, etc. pp. 

this happens with sysvinit-2.93

it doesn't happen with sysvinit-2.93 when using the gui shutdown button of xfce4

it doesn't happen when downgrading sysvinit to 2.91-r1, in neither of the two cases.

I'm not sure which log to attach?

Comment 1 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev

2019-03-27 12:03:05 UTC

Can you please check if this happens with /sbin/reboot from sys-apps/sysvinit-2.94 as well?

Comment 2 tt_1 2019-03-27 13:44:11 UTC

I'm not sure if I want that. The problem is, that the forced fsck can fail under certain circumstances. This ends up in mounting /dev/sdX as read-only, from there it can't start start anything that needs rw access to /, and other processes depending on it fail to write on / when rebooting. No idea how to get out of this deadlock, but by restoring a backup.

Comment 3 tt_1 2019-03-27 13:45:15 UTC

Created attachment 570926 [details]
emerge --info

Comment 4 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev

2019-03-30 11:15:33 UTC

(In reply to tt_1 from comment #2)
> I'm not sure if I want that. The problem is, that the forced fsck can fail
> under certain circumstances. This ends up in mounting /dev/sdX as read-only,
> from there it can't start start anything that needs rw access to /, and
> other processes depending on it fail to write on / when rebooting. No idea
> how to get out of this deadlock, but by restoring a backup.

Well, that's unfortunate since you seem to be the only one suffering from this issue.
I suppose you tried to remount the / partition read-write without success?

  mount -o remount,rw /

Comment 5 tt_1 2019-05-03 20:42:12 UTC

I'm going to tackle this in the next days. 

openrc-0.41 has gone stable, there were a few bugs I deem suspicious of causing this. Also I had rc_parallel=YES, and it might be that the fsck cmd was interrupted by other things running in parallel mode. 

Also going to make myself a postit with the info on how to remount a read-only partition.

Comment 6 tt_1 2019-05-13 21:04:42 UTC

This might have been the foreshadow of the hd's mechanical fail, which occured today. Will confirm within a week or so.

Comment 7 tt_1 2019-05-21 15:27:41 UTC

I can't reproduce the behavior anymore, the issue might have been solved by the upgrade to openrc-0.41.2, it might have been caused by parallel booting turned on, or it might have happened because of the slowly failing harddisk.