From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2@gmail.com Subject: Re: Drive identifiers Date: Thu, 18 Jan 2018 19:43:54 -0500 Message-ID: <86po66isol.fsf@gmail.com> References: <87mv1c4kp7.fsf@gnu.org> <86y3kvzypj.fsf@gmail.com> <20180118102914.6cb68394@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecKmm-0000ck-8g for guix-devel@gnu.org; Thu, 18 Jan 2018 19:44:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecKmj-00030h-5n for guix-devel@gnu.org; Thu, 18 Jan 2018 19:44:00 -0500 In-Reply-To: <20180118102914.6cb68394@scratchpost.org> (Danny Milosavljevic's message of "Thu, 18 Jan 2018 10:29:14 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: Guix-devel On 01/18/2018 at 10:29 Danny Milosavljevic writes: [...] > Maybe we could make the user specify the serial number in the operating-system > bootloader-configuration. Installing the bootloader to the wrong > drive would be very bad otherwise. Also, it's not exactly declarative if the > labels sda, sdb etc can move around - and reconfiguring / booting ends up like > a game of musical chairs. > > Although if a drive fails and an administrator replaces it by a new drive, > one would have to change the operating-system configuration and reconfigure > (which could potentially download gigabytes of data and take hours). > > Not ideal. > > Maybe store the original serial number into a file on disk and make Guix > fall back to checking those in a second pass (with a warning). > > (Guix could still call the bootloader's installer with the name of the > device file it found out - so it wouldn't be an involved change) > > We would still have to check what happens with the hard drive emulators of > CD-ROMs - do these have a unique persistent serial number? Hi Danny, I commented in a separate post on requiring our users to provide the drive SN in the config file. Here I comment on consequences of having the SN of a HD in a file held by that HD. IMO this is like having the directory name in a file held by the directory. Both raise the same issue: the file is no longer relocatable. In our case, as you point out, this creates a new error case. Unfortunately we can't possibly know the best way to handle it. E.G.: If the user has created an image backup of a mission-critical GuixSD server and if they start it on a second server as a warm-backup and if they have forgotten to change critical identify files (say hostname) and if this can cause both servers to become corrupted, halting on this error might be helpful. But first we should consider how many "ifs" I used to construct this hypothetical downside. Maybe we are protecting against very unlikely downsides. Second: if we halt the user may well say, "Yep, it's an image BU", override the error, and end up in the same fix ;-) OTOH, if our user is feverishly trying to start the image because the primary server failed, halting hurts the user. I expect that, in practice, the latter case will be much more likely than the former. HTH - George