From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8381F1581EE for ; Tue, 01 Apr 2025 17:52:57 +0000 (UTC) Received: from lists.gentoo.org (bobolink.gentoo.org [140.211.166.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: relay-lists.gentoo.org@gentoo.org) by smtp.gentoo.org (Postfix) with ESMTPSA id 6EEE034323B for ; Tue, 01 Apr 2025 17:52:57 +0000 (UTC) Received: from bobolink.gentoo.org (localhost [127.0.0.1]) by bobolink.gentoo.org (Postfix) with ESMTP id DD54E1104C1; Tue, 01 Apr 2025 17:50:55 +0000 (UTC) Received: from mail.muc.de (mail.muc.de [193.149.48.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bobolink.gentoo.org (Postfix) with ESMTPS id 2D8CB1104B1 for ; Tue, 01 Apr 2025 17:50:53 +0000 (UTC) Received: (qmail 55548 invoked by uid 3782); 1 Apr 2025 19:50:51 +0200 Received: from muc.de (p4fe15608.dip0.t-ipconnect.de [79.225.86.8]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 01 Apr 2025 19:50:50 +0200 Received: (qmail 3515 invoked by uid 1000); 1 Apr 2025 17:50:50 -0000 Date: Tue, 1 Apr 2025 17:50:50 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) Message-ID: References: <20241220145053.B361C85A435A@turkos.aspodata.se> <20241220174453.4E33285A435A@turkos.aspodata.se> <581a87bd-2578-47b2-8a68-2decc3db8991@youngman.org.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Archives-Salt: 8aa6bea1-1edb-4e39-876f-46a0b0b8b65d X-Archives-Hash: 1549c5b89af4b39578a0201006656c0d Three and a bit months later... On Sun, Dec 22, 2024 at 13:43:08 +0000, Alan Mackenzie wrote: > Hello, Wol. > On Sun, Dec 22, 2024 at 12:02:49 +0000, Wols Lists wrote: > > On 20/12/2024 17:44, karl@aspodata.se wrote: [ .... ] > > By the way, as to the other point of putting /dev/sda etc on the > > kernel command line, it's the kernel that's messing up and > > scrambling which physical disk is which logical sda sdb et al > > device, so explicitly specifying that will have exactly NO effect > > when your hardware/software combo changes again. > /dev/sda (or, in my case, /dev/nvme0n1), etc. don't, in my experience, > get scrambled by the kernel. They're plugged into the same sockets on > the motherboard from day to day, so unless you're physically inserting > or removing them, you won't have trouble. [ .... ] > > sda, sdb, sdc et al are allocated AT RANDOM by the kernel. > Only in the sense that it may be difficult on a new machine to predict > in advance which physical HDD becomes which sdx. As I said, the > assignment of physical drives to logical devices is repeatable, and > doesn't change from day to day. Wol was right and I was wrong. My two SSDs get allocated randomly to /dev/nvme0n1 and /dev/nvme1n1. Most of the time I didn't notice this since all my partitions apart from /boot (and swap) are RAID-1 devices using the kernel's md facility. However, today I built a new kernel (6.12.21) and wrote it to /boot. Unfortunately, this was on the wrong SSD, because of the scrambling Wol warned me about in December. So I couldn't find the syslinux configuration file which is only on the "first" SSD. It took me most of the day to figure out what had happened. In the end, I fixed the problem by using the UUID for /dev/nvme0n1p1 in the entry for /boot in /etc/fstab. The other partitions which get assembled into MD devices are fine, since it doesn't matter which order they're in. [ .... ] > > You need to use those UUID/GUID things. I know it's a hassle finding out > > whether it's a guid or a uuid, and what it is, and all that crud, but > > trust me they don't change, you can shuffle your disks, stick in another > > SATA card, move it from SATA to USB (BAD move - don't even think of it > > !!!), and the system will still find the correct disk. Indeed. > The trouble being that a kernel command line, or /etc/fstab, using lots > of these is not human readable, and hence is at the edge of > unmaintainability. This maintenance difficulty surely outweighs the > rare situation where the physical->logical assignment changes due to a > broken drive. That's what we've got rescue disks for. So I now have an /etc/fstab which isn't properly human readable. I regret this, but getting the correct partition mounted on /boot was more important. > > Cheers, > > Wol -- Alan Mackenzie (Nuremberg, Germany).