all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: myglc2@gmail.com
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: Drive identifiers
Date: Thu, 18 Jan 2018 19:43:54 -0500	[thread overview]
Message-ID: <86po66isol.fsf@gmail.com> (raw)
In-Reply-To: <20180118102914.6cb68394@scratchpost.org> (Danny Milosavljevic's message of "Thu, 18 Jan 2018 10:29:14 +0100")

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

  parent reply	other threads:[~2018-01-19  0:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 12:43 Installation Gábor Boskovits
2018-01-17 14:35 ` Installation Ludovic Courtès
2018-01-17 15:47   ` Installation Ricardo Wurmus
2018-01-17 19:35     ` Installation Gábor Boskovits
2018-01-18 10:27       ` Installation Ludovic Courtès
2018-01-18 10:29     ` Installation Ludovic Courtès
2018-01-18 12:05       ` Installation ng0
2018-01-18 15:11         ` Installation Ricardo Wurmus
2018-01-18 16:41           ` Installation myglc2
2018-01-22  4:38       ` Installation Chris Marusich
2018-01-22  8:29         ` Installation Gábor Boskovits
2018-01-18  2:29   ` Installation George myglc2 Clemmer
2018-01-18  9:29     ` Drive identifiers Danny Milosavljevic
2018-01-18  9:39       ` Danny Milosavljevic
2018-01-18 10:32         ` Ludovic Courtès
2018-01-18 11:01           ` Danny Milosavljevic
2018-01-19 14:35           ` Danny Milosavljevic
2018-01-18 20:10       ` myglc2
2018-01-19  8:27         ` Danny Milosavljevic
2018-01-19  0:43       ` myglc2 [this message]
2018-01-19  7:22         ` Danny Milosavljevic
2018-01-19 16:42         ` Ricardo Wurmus
2018-01-24 14:12           ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86po66isol.fsf@gmail.com \
    --to=myglc2@gmail.com \
    --cc=dannym@scratchpost.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.