From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (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 A3F3D1580FD for ; Sun, 22 Dec 2024 12:02:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A720AE08A8; Sun, 22 Dec 2024 12:02:53 +0000 (UTC) Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) (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 pigeon.gentoo.org (Postfix) with ESMTPS id 68090E07D8 for ; Sun, 22 Dec 2024 12:02:53 +0000 (UTC) Received: from host81-152-157-204.range81-152.btcentralplus.com ([81.152.157.204] helo=[192.168.1.99]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1tPKfa-000000004CI-ANbQ for gentoo-user@lists.gentoo.org; Sun, 22 Dec 2024 12:02:51 +0000 Message-ID: <581a87bd-2578-47b2-8a68-2decc3db8991@youngman.org.uk> Date: Sun, 22 Dec 2024 12:02:49 +0000 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 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-user] Fun with mdadm (Software RAID) To: gentoo-user@lists.gentoo.org References: <20241220145053.B361C85A435A@turkos.aspodata.se> <20241220174453.4E33285A435A@turkos.aspodata.se> Content-Language: en-GB From: Wols Lists In-Reply-To: <20241220174453.4E33285A435A@turkos.aspodata.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: cd797967-abbe-4b95-9a24-6f4324e87ae2 X-Archives-Hash: 9dbc4dcb368df055a1ee2ffcdb94a5d9 On 20/12/2024 17:44, karl@aspodata.se wrote: >> If I understand things correctly, with this mechanism one can have the >> kernel assemble the RAID arrays at boot up time with a modern metadata, >> but still without needing the initramfs. My arrays are still at >> metadata 0.90. > Please tell if you make booting with metadata 1.2 work. > I havn't tested that. It is NOT supported. The kernel has no code to do so, you need an initramfs. That said, nowadays I believe you can actually load the initramfs into the kernel so it's one monolithic blob ... 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. I guess it was the fact your rescue disk booted from CDROM or whatever made THAT sda, and pushed the other disks out of the way. sda, sdb, sdc et al are allocated AT RANDOM by the kernel. It just so happens that the "seed" rarely changes, so in normal use the same values happen to get chosen every time - until something DOES change, and then you wonder why everything falls over. The same is also true of md127, md126 et al. If your raid counts up from md1, md2 etc then those I believe are stable, but I haven't seen them for pretty much the entire time I've been involved in mdraid (maybe a decade or so?) 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. Cheers, Wol