From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DF6D81388BF for ; Wed, 17 Feb 2016 08:25:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8A2ED21C027; Wed, 17 Feb 2016 08:25:04 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 96BEF21C00A for ; Wed, 17 Feb 2016 08:25:03 +0000 (UTC) Received: from eris.local (dynamic-adsl-84-220-90-108.clienti.tiscali.it [84.220.90.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 6F9CA340BFB for ; Wed, 17 Feb 2016 08:25:02 +0000 (UTC) Subject: Re: [gentoo-dev] rfc: Does OpenRC really need mount-ro To: gentoo-dev@lists.gentoo.org References: <20160216180533.GB1450@whubbs1.gaikai.biz> From: Luca Barbato X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 17 Feb 2016 09:24:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20160216180533.GB1450@whubbs1.gaikai.biz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: e98f34b4-c678-4026-b251-d511d8ed8ecb X-Archives-Hash: 7a6a223b33ce323f5eed83375be138b8 On 16/02/16 19:05, William Hubbs wrote: > All, > > I have a bug that points out a significant issue with > /etc/init.d/mount-ro in OpenRC. > > Apparently, there are issues that cause it to not work properly for file > systems which happen to be pre-mounted from an initramfs [1]. Who is using that file system? Ideally if "we" are the last user of the file system it should be safe to mount ro it as well. In general this happens when there is a "too smart to fit /" filesystem in use. In general that means that the same stuff used in /usr to mount it should live in the initrd... In general deprecating split-/usr moves the problem in in supporting fat initrds to begin with. (I guess needing a boot filesystem that is fuse based and needs rabbitmq or postgresql might be extra fun btw). > This service only exists in the Linux world; there is no equivalent in > OpenRC for any other operating systems we support. Given it is a safety feature I do not know how the other kernels achieve the same out of box. > The reason it exists is very vague to me; I think it has something to do > with claims of data loss in the past. I think any fuse-supporting system should have it for more or less obvious reasons (see the evil example above). lu