From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2@gmail.com Subject: Re: Drive identifiers Date: Thu, 18 Jan 2018 15:10:06 -0500 Message-ID: <86shb3j5cx.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]:37287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecGVq-0004x3-Fq for guix-devel@gnu.org; Thu, 18 Jan 2018 15:10:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecGVl-0003v6-Gu for guix-devel@gnu.org; Thu, 18 Jan 2018 15:10:14 -0500 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: >> IIRC the details are: when running on a system disk (say: /dev/sda) and >> installing to new disk (say: /dev/sdb) you must set the bootloader >> target to /dev/sdb so the boot loader will be copied to the new system > ^ > | > +--- we could change that to enable specifying a model and > serial number > >> disk. > >> But, at least on my servers, when I remove the original system >> disk, the new disk system becomes /dev/sda, and the bootloader fails. > > It does? What error message does it fail with? Does the grub shell > still start? I am recounting what I experienced almost 2 years ago, see bug#23072. The bug is sill open. [...] > 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. [...] I would not recommend doing this because forcing the specification of serial number would further complicate the system config process for all users but provide insurance that, at best, would protect only the small subset of users with multiple drives. IOW, it would force everybody to buy insurance that single drive guixSD users will never need, and savvy sysadmins won't want. WRT multi-drive systems, the most pressing issue involves raided system drives. (e.g, see my config below). This works great but has a HUGE vulnerability: When the raid member holding the bootloader fails (e.g. "/dev/nvme0n1" below) the system is unbootable. On my Debian systems I easily fix this by duplicating the boot loader to all the raid members. But this doesn't work on GuixSD because the bootloader is constantly changing. So the most pressing need, IMO, is to provide a way to maintain the bootloader on multiple targets (e.g., all the mapped devices in "/dev/md3" below). ;; RAID1 root using 1 NVMe SSD + 2 HDs (bootloader (grub-configuration (target "/dev/nvme0n1") (terminal-outputs '(console)) (terminal-inputs '(serial console)) (serial-speed 115200) )) (initrd (lambda (file-systems . rest) (apply base-initrd file-systems #:extra-modules '("raid1") rest))) (mapped-devices (list (mapped-device (source '("/dev/nvme0n1p1" "/dev/sda1" "/dev/sdb1")) (target "/dev/md3") (type raid-device-mapping)))) (file-systems (cons (file-system (title 'device) (device "/dev/md3") (mount-point "/") (type "ext4") (dependencies mapped-devices)) %base-file-systems)) (swap-devices '("/dev/nvme0n1p2" )) HTH - George