From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: Drive identifiers Date: Fri, 19 Jan 2018 09:27:17 +0100 Message-ID: <20180119092717.07c220f4@scratchpost.org> References: <87mv1c4kp7.fsf@gnu.org> <86y3kvzypj.fsf@gmail.com> <20180118102914.6cb68394@scratchpost.org> <86shb3j5cx.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecS1I-0003fW-RD for guix-devel@gnu.org; Fri, 19 Jan 2018 03:27:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecS1E-0007L4-KR for guix-devel@gnu.org; Fri, 19 Jan 2018 03:27:28 -0500 In-Reply-To: <86shb3j5cx.fsf@gmail.com> 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: myglc2@gmail.com Cc: Guix-devel > bug#23072. The bug is sill open. =46rom the bug report: >>> "clocksource: Switched to clocksource tsc" That's a Linux kernel message - so grub is innocent. It loaded the Linux k= ernel. I recommend mounting the root by UUID, then it will be found. > 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. It would just be an option. The user could also specify the device by name. Having a declarative specification with non-persistent names in it is dangerous. > 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 > 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). Makes sense. Please file a bug report about it... I think installing the bootloader on multiple devices is the easy part. Does it also require grub.conf on multiple devices or is that part already RAID-aware then?