a new install - - - putting the system on raid

a new install - - - putting the system on raid

[o1bigtenor]

Greetings

https://raid.wiki.kernel.org/index.php/SATA_RAID_Boot_Recipe

Found the above recipe - - - the preface there is that this is
an existing system.

I am wanting to have all of /efi/boot, /, swap, /tmp, /var, /usr and
/usr/local on one raid-1 array and a second array for /home - - -
on a new install.

I have tried the following:

1. make large partition on each drive
2. set up raid array (2 separate arrays)
3. unable to place partitions on arrays

1. set up the same partitions on each set of drives
    (did allocate unused space between each partition)
2. was only allowed one partition from each drive for the array

Neither option seems able to give me what I want.
(More security - - - less likely to lose both drives (2 M2s and 2 SSDs).)

Is my only option to set up the arrays and then use LVM2 on top?
(One more point of failure so would rather not.)

Is there another option somewhat like the method outlined above - - -
recipe is some over 10 years old - - - or is this the only way to do things?

Please advise.

TIA

Re: a new install - - - putting the system on raid

[Wols Lists]

On 23/06/2022 13:11, o1bigtenor wrote:
> Greetings
> 
> https://raid.wiki.kernel.org/index.php/SATA_RAID_Boot_Recipe
> 
> Found the above recipe - - - the preface there is that this is
> an existing system.
> 
> I am wanting to have all of /efi/boot, /, swap, /tmp, /var, /usr and
> /usr/local on one raid-1 array and a second array for /home - - -
> on a new install.

/efi/boot (a) must be fat32, and (b) must be a "top level" partition. 
Okay, that's not totally true, but near enough, and scuppers your plan 
straight off ...

swap - why mirror it? If you set the fstab priorities to the same value, 
you get a striped raid-0 for free.

/tmp - is usually tmpfs nowadays, if you need disk backing, just make 
sure you've got a big-enough swap (tmpfs defaults to half ram, make it 
bigger and let it swap).
> 
> I have tried the following:
> 
> 1. make large partition on each drive
> 2. set up raid array (2 separate arrays)
> 3. unable to place partitions on arrays

Should be able to, but as above for your first array it won't actually 
work ...
> 
> 1. set up the same partitions on each set of drives
>      (did allocate unused space between each partition)
> 2. was only allowed one partition from each drive for the array
> 
> Neither option seems able to give me what I want.
> (More security - - - less likely to lose both drives (2 M2s and 2 SSDs).)
> 
> Is my only option to set up the arrays and then use LVM2 on top?
> (One more point of failure so would rather not.)

Well. I'm using lvm, it's normal practice, but again won't work for your 
first array ...
> 
> Is there another option somewhat like the method outlined above - - -
> recipe is some over 10 years old - - - or is this the only way to do things?

/boot/efi on its own partition

swap - its own partition

/tmp - tmpfs

/ (including /var and /usr) on one array

/home on the other array
> 
> Please advise.
> 
I've not done it, it's on my list of things to try, but you could put 
/boot/efi on v1.0 superblock raid-1 array and format it fat32. Make sure 
you know what you're doing!

That basically leaves swap and /tmp as your only unprotected partitions, 
neither of which is expected to survive any computer problems intact 
anyway (swap depends on your current session, and/tmp is *defined* as 
volatile and lost on shutdown.

My setup only has the one (raid-5) array for all my "real" partitions, 
and I've got lvm to give me / and /home (and others). It also gives me 
some degree of backup capability, as I just take snapshots. Running 
gentoo, that gives me security when I update the system every weekend :-)

https://raid.wiki.kernel.org/index.php/System2020

Cheers,
Wol

ESP and its file system (Re: a new install - - - putting the system on raid)

[Paul Menzel]

Dear Wol,


Am 23.06.22 um 14:56 schrieb Wols Lists:

[…]

> /efi/boot (a) must be fat32,
Just a minor (theoretical) correction. To my knowledge the UEFI 
specification requires the UEFI firmware to be able to read a (UEFI) FAT 
partition, but if you are lucky or control the firmware stack, the ESP 
can be formatted with any filesystem.


Kind regards,

Paul

Re: a new install - - - putting the system on raid

[Pascal Hambourg]

Le 23/06/2022 à 14:56, Wols Lists wrote :
> On 23/06/2022 13:11, o1bigtenor wrote:
>>
>> I am wanting to have all of /efi/boot, /, swap, /tmp, /var, /usr and
>> /usr/local on one raid-1 array and a second array for /home - - -
>> on a new install.
> 
> /efi/boot (a) must be fat32, and (b) must be a "top level" partition. 

Right, the UEFI firmware would not be able to read an EFI partition 
inside a partitioned software RAID array, and even on most unpartitioned 
RAID arrays. The most you can do is create a RAID1 array with superblock 
1.0 and use it all as an EFI partition but registering EFI boot entries 
for each EFI RAID member will be tricky.

> swap - why mirror it?

For redundancy, of course.

> If you set the fstab priorities to the same value, 
> you get a striped raid-0 for free.

Without any redundancy. What is the point of setting up RAID1 for all 
the rest and see your system crash pitifully when a drive fails because 
half of the swap suddenly becomes unreachable ?

>> I have tried the following:
>>
>> 1. make large partition on each drive
>> 2. set up raid array (2 separate arrays)
>> 3. unable to place partitions on arrays
> 
> Should be able to

Yes, RAID arrays should be partitionable by default. But your installer 
may not support it. LVM over RAID may be more widely supported.

>> 1. set up the same partitions on each set of drives
>>      (did allocate unused space between each partition)
>> 2. was only allowed one partition from each drive for the array

That sounds sensible. A RAID array with several partitions on the same 
drive does not make much sense. You must create a RAID array for each 
partition set.

Re: a new install - - - putting the system on raid

[Wols Lists]

On 23/06/2022 19:54, Pascal Hambourg wrote:
>> If you set the fstab priorities to the same value, you get a striped 
>> raid-0 for free.
> 
> Without any redundancy. What is the point of setting up RAID1 for all 
> the rest and see your system crash pitifully when a drive fails because 
> half of the swap suddenly becomes unreachable ?

Why would it crash? Firstly, the system shouldn't be swapping. MOST 
systems, under MOST workloads, don't need swap.

And secondly, the *system* should not be using swap. User space, yes. So 
a bunch of running stuff might crash. But the system should stay up.

Raid is meant to protect your data. The benefit for raiding your swap is 
much less, and *should* be negligible.

Cheers,
Wol

Re: a new install - - - putting the system on raid

[Pascal Hambourg]

Le 23/06/2022 à 23:39, Wols Lists a écrit :
> On 23/06/2022 19:54, Pascal Hambourg wrote:
>>> If you set the fstab priorities to the same value, you get a striped 
>>> raid-0 for free.
>>
>> Without any redundancy. What is the point of setting up RAID1 for all 
>> the rest and see your system crash pitifully when a drive fails 
>> because half of the swap suddenly becomes unreachable ?
> 
> Why would it crash?

Do you really believe a program can lose some of its data and still 
behave as if nothing happened ? If that were true, then why not just 
discard data instead of swap them out when memory is short ?

> Firstly, the system shouldn't be swapping. MOST 
> systems, under MOST workloads, don't need swap.

Conversely, some systems, under some workloads, do need swap. And when 
they do, swap needs to be as reliable as any other storage space.

> And secondly, the *system* should not be using swap. User space, yes. So 
> a bunch of running stuff might crash. But the system should stay up.

Firstly, the *system* is not only the kernel. Many user space processes 
are part of the *system*. Secondly, you were the one who wrote:

"/tmp - is usually tmpfs nowadays, if you need disk backing, just make 
sure you've got a big-enough swap (tmpfs defaults to half ram, make it 
bigger and let it swap)."

> Raid is meant to protect your data. The benefit for raiding your swap is 
> much less, and *should* be negligible.

No, this is what backup is meant to. RAID does not protect your data 
against accidental or malicious deletion or corruption. RAID is meant to 
provide availabity. The benefit of having everything including swap on 
RAID is that the system as a whole will continue to operate normally 
when a drive fails.

Re: a new install - - - putting the system on raid

[Wol]

On 23/06/2022 23:27, Pascal Hambourg wrote:
> 

>>
>> Why would it crash?
> 
> Do you really believe a program can lose some of its data and still 
> behave as if nothing happened ? If that were true, then why not just 
> discard data instead of swap them out when memory is short ?

No ...
> 
>> Firstly, the system shouldn't be swapping. MOST systems, under MOST 
>> workloads, don't need swap.
> 
> Conversely, some systems, under some workloads, do need swap. And when 
> they do, swap needs to be as reliable as any other storage space.

And if your system is one of the ?majority? that shouldn't swap, the 
cost/benefit analysis is COMPLETELY different for swap than for main 
storage. So don't treat them the same.
> 
>> And secondly, the *system* should not be using swap. User space, yes. 
>> So a bunch of running stuff might crash. But the system should stay up.
> 
> Firstly, the *system* is not only the kernel. Many user space processes 
> are part of the *system*. Secondly, you were the one who wrote:
> 
> "/tmp - is usually tmpfs nowadays, if you need disk backing, just make 
> sure you've got a big-enough swap (tmpfs defaults to half ram, make it 
> bigger and let it swap)."
> 
And? /tmp is *explicitly* not to be trusted in the event of problems. If 
you lose a disk and it takes /tmp out, sorry. If the tmp-cleaner decides 
to do a random "rm /tmp/*" at an inconvenient moment, well, if the 
system can't handle it then whoever set the system up (or wrote the 
program) was incompetent. Sorry. It's true. (And, no, I'm not claiming 
to be a competent person :-)

>> Raid is meant to protect your data. The benefit for raiding your swap 
>> is much less, and *should* be negligible.
> 
> No, this is what backup is meant to. RAID does not protect your data 
> against accidental or malicious deletion or corruption. RAID is meant to 
> provide availabity. The benefit of having everything including swap on 
> RAID is that the system as a whole will continue to operate normally 
> when a drive fails.

And how does backup protect your data when the system crashes? You know, 
all that web-shop data that is fresh and new and arrived after the most 
recent backup 5mins ago? But that is probably irrelevant to most people :-)

(Oh, and I didn't tell o1bigtenor NOT to raid his swap. I asked him WHY 
he would want to. Maybe he has good reason. But I know him of old, and 
have good reason to suspect he's going OTT.)

You need to know what the threats are, what the mitigations are, and 
what strategies are RELEVANT. And you need different strategies for 
long-term, short-term, and immediate protection/threats.

I run xosview. Even with gentoo, and a massive tmpfs, swap in-use sits 
at 0B practically ALL the time. Why would I want to protect it? On the 
other hand, my data sits on raid-5 on top of dm-integrity - protected 
against both disk corruption and disk loss.

And then I usually forget I've got a massive disk sitting there for 
backup. Losing a hard drive doesn't cross my mind, because in pretty 
much 30 years I personally have yet to lose a disk. I know I'm lucky, 
I've recovered other people who have, but ...

As I say, different risks, different mitigations...

Cheers,
Wol

Re: a new install - - - putting the system on raid

[Pascal Hambourg]

Le 24/06/2022 à 01:44, Wol a écrit :
> On 23/06/2022 23:27, Pascal Hambourg wrote:
>>
>>> Firstly, the system shouldn't be swapping. MOST systems, under MOST 
>>> workloads, don't need swap.
>>
>> Conversely, some systems, under some workloads, do need swap. And when 
>> they do, swap needs to be as reliable as any other storage space.
> 
> And if your system is one of the ?majority? that shouldn't swap, the 
> cost/benefit analysis is COMPLETELY different for swap than for main 
> storage. So don't treat them the same.

If your system should not swap, then why use any swap at all ?

>>> And secondly, the *system* should not be using swap. User space, yes. 
>>> So a bunch of running stuff might crash. But the system should stay up.
>>
>> Firstly, the *system* is not only the kernel. Many user space 
>> processes are part of the *system*. Secondly, you were the one who wrote:
>>
>> "/tmp - is usually tmpfs nowadays, if you need disk backing, just make 
>> sure you've got a big-enough swap (tmpfs defaults to half ram, make it 
>> bigger and let it swap)."
>>
> And? /tmp is *explicitly* not to be trusted in the event of problems. If 
> you lose a disk and it takes /tmp out, sorry.

Source ?

> If the tmp-cleaner decides 
> to do a random "rm /tmp/*" at an inconvenient moment, well, if the 
> system can't handle it then whoever set the system up (or wrote the 
> program) was incompetent.

Cleaning /tmp is not the same as loosing access to it. Opened files are 
still accessible.

>>> Raid is meant to protect your data. The benefit for raiding your swap 
>>> is much less, and *should* be negligible.
>>
>> No, this is what backup is meant to. RAID does not protect your data 
>> against accidental or malicious deletion or corruption. RAID is meant 
>> to provide availabity. The benefit of having everything including swap 
>> on RAID is that the system as a whole will continue to operate 
>> normally when a drive fails.
> 
> And how does backup protect your data when the system crashes? You know, 
> all that web-shop data that is fresh and new and arrived after the most 
> recent backup 5mins ago?

Use RAID, so that the system does not crash when a drive fails.

> (Oh, and I didn't tell o1bigtenor NOT to raid his swap. I asked him WHY 
> he would want to. Maybe he has good reason. But I know him of old, and 
> have good reason to suspect he's going OTT.)

I think you do not need a good reason to have swap on RAID when all the 
rest is on RAID. It is the other way around : you need a good reason not 
to have swap on RAID.

> I run xosview. Even with gentoo, and a massive tmpfs, swap in-use sits 
> at 0B practically ALL the time. Why would I want to protect it?

Because you may not want anything to crash when a drive fails while the 
swap is used. If you don't care, well, don't protect the swap.

Re: a new install - - - putting the system on raid

[Wols Lists]

On 25/06/2022 09:27, Pascal Hambourg wrote:
> Le 24/06/2022 à 01:44, Wol a écrit :
>> On 23/06/2022 23:27, Pascal Hambourg wrote:
>>>
>>>> Firstly, the system shouldn't be swapping. MOST systems, under MOST 
>>>> workloads, don't need swap.
>>>
>>> Conversely, some systems, under some workloads, do need swap. And 
>>> when they do, swap needs to be as reliable as any other storage space.
>>
>> And if your system is one of the ?majority? that shouldn't swap, the 
>> cost/benefit analysis is COMPLETELY different for swap than for main 
>> storage. So don't treat them the same.
> 
> If your system should not swap, then why use any swap at all ?

Same reason I do? I have a whole bunch of rarely used, and not-at-all 
critical tmpfs's, so the system occasionally spills into swap. A system 
failure is no grief - reboot, carry on where it left off ...
> 
>>>> And secondly, the *system* should not be using swap. User space, 
>>>> yes. So a bunch of running stuff might crash. But the system should 
>>>> stay up.
>>>
>>> Firstly, the *system* is not only the kernel. Many user space 
>>> processes are part of the *system*. Secondly, you were the one who 
>>> wrote:
>>>
>>> "/tmp - is usually tmpfs nowadays, if you need disk backing, just 
>>> make sure you've got a big-enough swap (tmpfs defaults to half ram, 
>>> make it bigger and let it swap)."
>>>
>> And? /tmp is *explicitly* not to be trusted in the event of problems. 
>> If you lose a disk and it takes /tmp out, sorry.
> 
> Source ?

Linux Filesystem Hierarchy Standard? The presence of ANY files in /tmp 
is not to be trusted - even if you created it ten seconds ago ...
> 
> 
>> (Oh, and I didn't tell o1bigtenor NOT to raid his swap. I asked him 
>> WHY he would want to. Maybe he has good reason. But I know him of old, 
>> and have good reason to suspect he's going OTT.)
> 
> I think you do not need a good reason to have swap on RAID when all the 
> rest is on RAID. It is the other way around : you need a good reason not 
> to have swap on RAID.
> 
>> I run xosview. Even with gentoo, and a massive tmpfs, swap in-use sits 
>> at 0B practically ALL the time. Why would I want to protect it?
> 
> Because you may not want anything to crash when a drive fails while the 
> swap is used. If you don't care, well, don't protect the swap.

And most people nowadays - certainly on a single-user system - will have 
no reason to care. Certainly my system, with 32GB of ram, is very 
unlikely to spill into swap in normal operation ...

Cheers,
Wol

Re: a new install - - - putting the system on raid

[Pascal Hambourg]

Le 25/06/2022 à 13:41, Wols Lists wrote :
> On 25/06/2022 09:27, Pascal Hambourg wrote:
>> Le 24/06/2022 à 01:44, Wol wrote :
>>>
>>> And? /tmp is *explicitly* not to be trusted in the event of problems. 
>>> If you lose a disk and it takes /tmp out, sorry.
>>
>> Source ?
> 
> Linux Filesystem Hierarchy Standard? The presence of ANY files in /tmp 
> is not to be trusted - even if you created it ten seconds ago ...

This is not the same as /tmp becoming unusable at all.

As I wrote (and you cut), open files are not deleted and can still be 
read and written to until they are closed. They are only unlinked from 
the directory tree. It is actually rather common to unlink temporary 
files just after opening them, so that they are deleted automatically 
when they are closed.

swapping (was "Re: a new install - - - putting the system on raid")

[David T-G]

...and then Wols Lists said...
% 
...
% And most people nowadays - certainly on a single-user system - will have no
% reason to care. Certainly my system, with 32GB of ram, is very unlikely to
% spill into swap in normal operation ...

... but my desktop, with 16G of RAM and 64G of swap, routinely runs along
at about half used.  There are lits of different configs out there :-)


% 
% Cheers,
% Wol


HAND

:-D
-- 
David T-G
See http://justpickone.org/davidtg/email/
See http://justpickone.org/davidtg/tofu.txt

Re: a new install - - - putting the system on raid

[Roman Mamedov]

On Fri, 24 Jun 2022 00:27:45 +0200
Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:

> > Raid is meant to protect your data. The benefit for raiding your swap is 
> > much less, and *should* be negligible.
> 
> No, this is what backup is meant to. RAID does not protect your data 
> against accidental or malicious deletion or corruption. RAID is meant to 
> provide availabity. The benefit of having everything including swap on 
> RAID is that the system as a whole will continue to operate normally 
> when a drive fails.

I think the key decider in whether or not a RAIDed swap should be a must-have,
is whether the system has hot-swap bays for drives.

Also, it seemed like the discussion began in the context of setting up a home
machine, or something otherwise not as mission-critical. And in those cases,
almost nobody will have hot-swap.

As such, if you have to bring down the machine to replace a drive anyway, might
as well tolerate the risk of it going down with a bang (due to a part of swap
going away), and enjoy a faster swap on either RAID0 or multiple independent
swap zones for the rest of the time.

-- 
With respect,
Roman

Upgrading motherboard + CPU

[Alexander Shenkin]

Hi all,

I have 1 RAID6 (root) and 1 RAID1 (boot) array running across 7 drives 
in my Ubuntu 20.04 system.  I bought a new motherboard and CPU that I'd 
like to replace my current ones.  In non-raid systems, I get the sense 
that it's not a very risky operation.  However, I suspect RAID makes it 
more tricky.  Wondering if anyone can offer any advice here?  Do I have 
to make sure sata cables are plugged into corresponding ports in the new 
motherboard?  etc.  Many thanks in advance.

Allie

Re: Upgrading motherboard + CPU

[Roman Mamedov]

On Fri, 24 Jun 2022 11:27:08 -0700
Alexander Shenkin <al@shenkin.org> wrote:

> I have 1 RAID6 (root) and 1 RAID1 (boot) array running across 7 drives 
> in my Ubuntu 20.04 system.  I bought a new motherboard and CPU that I'd 
> like to replace my current ones.  In non-raid systems, I get the sense 
> that it's not a very risky operation.  However, I suspect RAID makes it 
> more tricky.

Luckily with software RAID using mdadm it does not.

> Wondering if anyone can offer any advice here?  Do I have to make sure sata
> cables are plugged into corresponding ports in the new motherboard?

No, the order of cables is unimportant. Just plug everything in, and it should
work.

May have to check in BIOS that it doesn't require a UEFI boot partition, but
allows to boot from a legacy-style bootloader, in settings such as "Launch
CSM: Enabled" and "Boot device control: (UEFI and) Legacy".

-- 
With respect,
Roman

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

Fantastic, thanks Roman.

On 6/24/2022 11:44 AM, Roman Mamedov wrote:
> On Fri, 24 Jun 2022 11:27:08 -0700
> Alexander Shenkin <al@shenkin.org> wrote:
> 
>> I have 1 RAID6 (root) and 1 RAID1 (boot) array running across 7 drives
>> in my Ubuntu 20.04 system.  I bought a new motherboard and CPU that I'd
>> like to replace my current ones.  In non-raid systems, I get the sense
>> that it's not a very risky operation.  However, I suspect RAID makes it
>> more tricky.
> 
> Luckily with software RAID using mdadm it does not.
> 
>> Wondering if anyone can offer any advice here?  Do I have to make sure sata
>> cables are plugged into corresponding ports in the new motherboard?
> 
> No, the order of cables is unimportant. Just plug everything in, and it should
> work.
> 
> May have to check in BIOS that it doesn't require a UEFI boot partition, but
> allows to boot from a legacy-style bootloader, in settings such as "Launch
> CSM: Enabled" and "Boot device control: (UEFI and) Legacy".
> 

Re: Upgrading motherboard + CPU

[Wol]

On 24/06/2022 19:46, Alexander Shenkin wrote:
> Fantastic, thanks Roman.
> 
> On 6/24/2022 11:44 AM, Roman Mamedov wrote:
>> On Fri, 24 Jun 2022 11:27:08 -0700
>> Alexander Shenkin <al@shenkin.org> wrote:
>>
>>> I have 1 RAID6 (root) and 1 RAID1 (boot) array running across 7 drives
>>> in my Ubuntu 20.04 system.  I bought a new motherboard and CPU that I'd
>>> like to replace my current ones.  In non-raid systems, I get the sense
>>> that it's not a very risky operation.  However, I suspect RAID makes it
>>> more tricky.
>>
>> Luckily with software RAID using mdadm it does not.
>>
Just make sure fstab (and anywhere else you may have manually altered) 
is using uuids, and not device references (like /dev/sdxn).

Oh - and EFI / BIOS will always look for device 1. So that's a minor pain.

And both of those rules apply raid or not :-)

Cheers,
Wol

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

Smart, thanks Wol.  I'm good on the UUIDs.  Not sure what you mean by 
'device 1' though?

On 6/24/2022 12:14 PM, Wol wrote:
> On 24/06/2022 19:46, Alexander Shenkin wrote:
>> Fantastic, thanks Roman.
>>
>> On 6/24/2022 11:44 AM, Roman Mamedov wrote:
>>> On Fri, 24 Jun 2022 11:27:08 -0700
>>> Alexander Shenkin <al@shenkin.org> wrote:
>>>
>>>> I have 1 RAID6 (root) and 1 RAID1 (boot) array running across 7 drives
>>>> in my Ubuntu 20.04 system.  I bought a new motherboard and CPU that I'd
>>>> like to replace my current ones.  In non-raid systems, I get the sense
>>>> that it's not a very risky operation.  However, I suspect RAID makes it
>>>> more tricky.
>>>
>>> Luckily with software RAID using mdadm it does not.
>>>
> Just make sure fstab (and anywhere else you may have manually altered) 
> is using uuids, and not device references (like /dev/sdxn).
> 
> Oh - and EFI / BIOS will always look for device 1. So that's a minor pain.
> 
> And both of those rules apply raid or not :-)
> 
> Cheers,
> Wol

Re: Upgrading motherboard + CPU

[Wol]

On 24/06/2022 21:23, Alexander Shenkin wrote:
> Smart, thanks Wol.  I'm good on the UUIDs.  Not sure what you mean by 
> 'device 1' though?

Sata port 1. /dev/sda.

So your boot device is currently in physical connector 1 on the mobo. If 
you move it across, you need to make sure it stays in physical position 
1, otherwise the mobo will try to boot off whatever disk is in position 
1, and there won't be a boot system to boot off!

Remember, uuids rely on linux being running. But linux can't run until 
AFTER the boot code has run, so the boot code knows nothing about uuids 
and relies on physical locations. Cart before horse, catch-22, all that 
palaver you know :-)

Cheers,
Wol

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

Got it, thanks.  I hopefully, should, have all my disks bootable... but 
better safe than sorry.

On 6/24/2022 3:00 PM, Wol wrote:
> On 24/06/2022 21:23, Alexander Shenkin wrote:
>> Smart, thanks Wol.  I'm good on the UUIDs.  Not sure what you mean by 
>> 'device 1' though?
> 
> Sata port 1. /dev/sda.
> 
> So your boot device is currently in physical connector 1 on the mobo. If 
> you move it across, you need to make sure it stays in physical position 
> 1, otherwise the mobo will try to boot off whatever disk is in position 
> 1, and there won't be a boot system to boot off!
> 
> Remember, uuids rely on linux being running. But linux can't run until 
> AFTER the boot code has run, so the boot code knows nothing about uuids 
> and relies on physical locations. Cart before horse, catch-22, all that 
> palaver you know :-)
> 
> Cheers,
> Wol

Re: Upgrading motherboard + CPU

[Ram Ramesh]

On 6/24/22 17:06, Alexander Shenkin wrote:
> Got it, thanks.  I hopefully, should, have all my disks bootable... 
> but better safe than sorry.
>
> On 6/24/2022 3:00 PM, Wol wrote:
>> On 24/06/2022 21:23, Alexander Shenkin wrote:
>>> Smart, thanks Wol.  I'm good on the UUIDs.  Not sure what you mean 
>>> by 'device 1' though?
>>
>> Sata port 1. /dev/sda.
>>
>> So your boot device is currently in physical connector 1 on the mobo. 
>> If you move it across, you need to make sure it stays in physical 
>> position 1, otherwise the mobo will try to boot off whatever disk is 
>> in position 1, and there won't be a boot system to boot off!
>>
>> Remember, uuids rely on linux being running. But linux can't run 
>> until AFTER the boot code has run, so the boot code knows nothing 
>> about uuids and relies on physical locations. Cart before horse, 
>> catch-22, all that palaver you know :-)
>>
>> Cheers,
>> Wol
Whenever I upgrade my machine (new MB/CPU), I note down the name of the 
disk I currently boot from. Look /dev/disk/by-id and note down the disk.

After building new machine, get into BIOS setup and choose that disk as 
the first boot disk. You will have to enable CSM before choosing the 
disk, if it is legacy boot.

Recent motherboard's BIOS will not enable CSM without video card as 
video bios is removed in those MBs. So, you may have to either switch to 
UEFI boot first (very doable) on the old machine itself or get a spare 
video card (I have never used this approach, so so not sure).

Also, 12th gen intel CPUs need 5.16 or later kernel for video support. 
Otherwise, you will get blank screen. I have no idea why.

Also, make sure you go to manufacturer's website and read the MB spec to 
ensure all devices (network/audio etc) you care about are supported in 
your kernel.

Booting from bleeding edge hardware has always been in my experience.

Regards
Ramesh

Re: Upgrading motherboard + CPU

[Roman Mamedov]

On Fri, 24 Jun 2022 23:00:02 +0100
Wol <antlists@youngman.org.uk> wrote:

> So your boot device is currently in physical connector 1 on the mobo. If 
> you move it across, you need to make sure it stays in physical position 
> 1, otherwise the mobo will try to boot off whatever disk is in position 
> 1, and there won't be a boot system to boot off!

Using RAID1 across all disks with metadata 0.90 for /boot makes sure the BIOS
can boot no matter which disk it tries first.

In fact it could be with recent grub the "0.90" part is not even required
anymore.

Just make sure to "grub-install /dev/sdX" at least once to all of them.

-- 
With respect,
Roman

Re: Upgrading motherboard + CPU

[Wols Lists]

On 24/06/2022 23:08, Roman Mamedov wrote:
> On Fri, 24 Jun 2022 23:00:02 +0100
> Wol <antlists@youngman.org.uk> wrote:
> 
>> So your boot device is currently in physical connector 1 on the mobo. If
>> you move it across, you need to make sure it stays in physical position
>> 1, otherwise the mobo will try to boot off whatever disk is in position
>> 1, and there won't be a boot system to boot off!
> 
> Using RAID1 across all disks with metadata 0.90 for /boot makes sure the BIOS
> can boot no matter which disk it tries first.
> 
> In fact it could be with recent grub the "0.90" part is not even required
> anymore.
> 
> Just make sure to "grub-install /dev/sdX" at least once to all of them.
> 
Don't use 0.9, use 1.0.

Both of these put the superblock at the end, so the start of the array 
on disk is also the start of the data area. Which means you can bypass 
the raid (normally a bad idea, but here you need it).

Thing is, v0.x is deprecated, if it breaks it won't be fixed. v1.x is 
supported, all the x indicates is the location of the superblock, it's 
identical across all 1.x arrays.

1.0 is at the end, not necessarily a good idea. To be avoided where 
possible.

1.1 is at the start. Where any problems with a rogue partitioner will 
trample it. To be avoided.

1.2 leaves a 4K scratch space and puts the superblock after that. So it 
will survive most damage to the start of a partition. Recommended.

Cheers,
Wol

Re: Upgrading motherboard + CPU

[Pascal Hambourg]

Le 25/06/2022 à 00:08, Roman Mamedov a écrit :
> 
> Using RAID1 across all disks with metadata 0.90 for /boot makes sure the BIOS
> can boot no matter which disk it tries first.

Why 0.90 ? It is obsolete. If you need RAID metadata at the end of RAID 
members for whatever ugly reason, you can use metadata 1.0 instead. But 
AFAIK it is only needed as a dirty hack with boot loaders which do not 
really support software RAID and must see RAID partitions as native 
filesystems.

> In fact it could be with recent grub the "0.90" part is not even required
> anymore.

GRUB has supported RAID metadata 1.x since version 1.99 (2010).

Re: Upgrading motherboard + CPU

[Stephan]

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

> Why 0.90 ? It is obsolete. If you need RAID metadata at the end of
> RAID members for whatever ugly reason, you can use metadata 1.0
> instead. 

Does mdraid with metadata 1 work on the root filesystem w/o initramfs?

-- 
Stephan

Re: Upgrading motherboard + CPU

[Wols Lists]

On 25/06/2022 14:35, Stephan wrote:
> 
> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
> 
>> Why 0.90 ? It is obsolete. If you need RAID metadata at the end of
>> RAID members for whatever ugly reason, you can use metadata 1.0
>> instead.
> 
> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?
> 
If you're using v1.0, then you could boot off of one of the mirror 
members no problem.

You would point the kernel boot line at sda1 say (if that's part of your 
mirror). IFF that is mounted read-only for boot, then that's not a problem.

Your fstab would then mount /dev/md0 as root read-write, and you're good 
to go ...

Cheers,
Wol

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

On 6/25/2022 10:10 AM, Wols Lists wrote:
> On 25/06/2022 14:35, Stephan wrote:
>>
>> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
>>
>>> Why 0.90 ? It is obsolete. If you need RAID metadata at the end of
>>> RAID members for whatever ugly reason, you can use metadata 1.0
>>> instead.
>>
>> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?
>>
> If you're using v1.0, then you could boot off of one of the mirror 
> members no problem.
> 
> You would point the kernel boot line at sda1 say (if that's part of your 
> mirror). IFF that is mounted read-only for boot, then that's not a problem.
> 
> Your fstab would then mount /dev/md0 as root read-write, and you're good 
> to go ...
> 
> Cheers,
> Wol

My metadata is 1.2... I presume that won't cause problems...

Re: Upgrading motherboard + CPU

[Wols Lists]

On 25/06/2022 18:38, Alexander Shenkin wrote:
> 
> On 6/25/2022 10:10 AM, Wols Lists wrote:
>> On 25/06/2022 14:35, Stephan wrote:
>>>
>>> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
>>>
>>>> Why 0.90 ? It is obsolete. If you need RAID metadata at the end of
>>>> RAID members for whatever ugly reason, you can use metadata 1.0
>>>> instead.
>>>
>>> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?
>>>
>> If you're using v1.0, then you could boot off of one of the mirror 
>> members no problem.
>>
>> You would point the kernel boot line at sda1 say (if that's part of 
>> your mirror). IFF that is mounted read-only for boot, then that's not 
>> a problem.
>>
>> Your fstab would then mount /dev/md0 as root read-write, and you're 
>> good to go ...
>>
>> Cheers,
>> Wol
> 
> My metadata is 1.2... I presume that won't cause problems...

Do you need an initramfs to assemble raid ... I thought you did ... in 
which case your system will not boot without one if your root is v1.2 ...

Cheers,
Wol

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

On 6/25/2022 10:43 AM, Wols Lists wrote:
> On 25/06/2022 18:38, Alexander Shenkin wrote:
>>
>> On 6/25/2022 10:10 AM, Wols Lists wrote:
>>> On 25/06/2022 14:35, Stephan wrote:
>>>>
>>>> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
>>>>
>>>>> Why 0.90 ? It is obsolete. If you need RAID metadata at the end of
>>>>> RAID members for whatever ugly reason, you can use metadata 1.0
>>>>> instead.
>>>>
>>>> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?
>>>>
>>> If you're using v1.0, then you could boot off of one of the mirror 
>>> members no problem.
>>>
>>> You would point the kernel boot line at sda1 say (if that's part of 
>>> your mirror). IFF that is mounted read-only for boot, then that's not 
>>> a problem.
>>>
>>> Your fstab would then mount /dev/md0 as root read-write, and you're 
>>> good to go ...
>>>
>>> Cheers,
>>> Wol
>>
>> My metadata is 1.2... I presume that won't cause problems...
> 
> Do you need an initramfs to assemble raid ... I thought you did ... in 
> which case your system will not boot without one if your root is v1.2 ...
> 
> Cheers,
> Wol
I have no idea.  My system boots fine now.  Will any of this impact 
booting after the switch to a new CPU + motherboard?

Re: Upgrading motherboard + CPU

[Wols Lists]

On 25/06/2022 18:53, Alexander Shenkin wrote:
> 
> 
> 
> On 6/25/2022 10:43 AM, Wols Lists wrote:
>> On 25/06/2022 18:38, Alexander Shenkin wrote:
>>>
>>> On 6/25/2022 10:10 AM, Wols Lists wrote:
>>>> On 25/06/2022 14:35, Stephan wrote:
>>>>>
>>>>> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
>>>>>
>>>>>> Why 0.90 ? It is obsolete. If you need RAID metadata at the end of
>>>>>> RAID members for whatever ugly reason, you can use metadata 1.0
>>>>>> instead.
>>>>>
>>>>> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?
>>>>>
>>>> If you're using v1.0, then you could boot off of one of the mirror 
>>>> members no problem.
>>>>
>>>> You would point the kernel boot line at sda1 say (if that's part of 
>>>> your mirror). IFF that is mounted read-only for boot, then that's 
>>>> not a problem.
>>>>
>>>> Your fstab would then mount /dev/md0 as root read-write, and you're 
>>>> good to go ...
>>>>
>>>> Cheers,
>>>> Wol
>>>
>>> My metadata is 1.2... I presume that won't cause problems...
>>
>> Do you need an initramfs to assemble raid ... I thought you did ... in 
>> which case your system will not boot without one if your root is v1.2 ...
>>
>> Cheers,
>> Wol
> I have no idea.  My system boots fine now.  Will any of this impact 
> booting after the switch to a new CPU + motherboard?

If it's the same setup, it shouldn't make any difference. Famous last 
words ...

Cheers,
Wol

Re: Upgrading motherboard + CPU

[Reindl Harald]

Am 25.06.22 um 19:53 schrieb Alexander Shenkin:
> I have no idea.  My system boots fine now.  Will any of this impact 
> booting after the switch to a new CPU + motherboard?

Linux couldn't care less about CPU or mother board as long your initrd 
isn't "hostonly"

Re: Upgrading motherboard + CPU

[Roman Mamedov]

On Sun, 26 Jun 2022 00:37:42 +0200
Reindl Harald <h.reindl@thelounge.net> wrote:

> 
> 
> Am 25.06.22 um 19:53 schrieb Alexander Shenkin:
> > I have no idea.  My system boots fine now.  Will any of this impact 
> > booting after the switch to a new CPU + motherboard?
> 
> Linux couldn't care less about CPU or mother board as long your initrd 
> isn't "hostonly"

You're all overcomplicating this too much. Of course the next obvious question,
what is "hostonly", and how do we check if we have that?

For the OP: it will boot just fine. Really.

-- 
With respect,
Roman

Re: Upgrading motherboard + CPU

[Reindl Harald]

Am 26.06.22 um 00:45 schrieb Roman Mamedov:
> On Sun, 26 Jun 2022 00:37:42 +0200
> Reindl Harald <h.reindl@thelounge.net> wrote:
> 
>>
>>
>> Am 25.06.22 um 19:53 schrieb Alexander Shenkin:
>>> I have no idea.  My system boots fine now.  Will any of this impact
>>> booting after the switch to a new CPU + motherboard?
>>
>> Linux couldn't care less about CPU or mother board as long your initrd
>> isn't "hostonly"
> 
> You're all overcomplicating this too much. Of course the next obvious question,
> what is "hostonly", and how do we check if we have that?

https://fedoraproject.org/wiki/Features/DracutHostOnly

> For the OP: it will boot just fine. Really

except your initrd misses modules needed fater chaneg hardware

Re: Upgrading motherboard + CPU

[Roman Mamedov]

On Sun, 26 Jun 2022 01:40:19 +0200
Reindl Harald <h.reindl@thelounge.net> wrote:

> https://fedoraproject.org/wiki/Features/DracutHostOnly

Thanks! It feels like this should be carefully weighted whether it adds more
maintenance issues than any actual savings. At least they had the good
judgment to keep "a boot entry "Rescue System" with a full fledged initramfs",
so even if it is "hostonly", it's not the end of the world.

Do you know if any other distros do the same, how about Ubuntu, which the OP
is using?

> except your initrd misses modules needed fater chaneg hardware

Luckily a major one needed both before and after will be "ahci" nowadays, and
not much else comes to mind as to what might be missing.

-- 
With respect,
Roman

Re: Upgrading motherboard + CPU

[Reindl Harald]

Am 26.06.22 um 01:50 schrieb Roman Mamedov:
> On Sun, 26 Jun 2022 01:40:19 +0200
> Reindl Harald <h.reindl@thelounge.net> wrote:
> 
>> https://fedoraproject.org/wiki/Features/DracutHostOnly
> 
> Thanks! It feels like this should be carefully weighted whether it adds more
> maintenance issues than any actual savings. At least they had the good
> judgment to keep "a boot entry "Rescue System" with a full fledged initramfs"

which don't work in reality and i have no time and energy to explain why

at least you should have goolged it before "what is hostonly" when 
others point out issues existing for neraly 10 years

> so even if it is "hostonly", it's not the end of the world.

nothing is the end of the world but if your system don't boot it's a 
problem when you didn't expect it

> Do you know if any other distros do the same, how about Ubuntu, which the OP
> is using?
> 
>> except your initrd misses modules needed fater chaneg hardware
> 
> Luckily a major one needed both before and after will be "ahci" nowadays, and
> not much else comes to mind as to what might be missing

irrelevant when it comes to your "For the OP: it will boot just fine. 
Really." which is uneducated and naive - period

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

On 6/25/2022 4:28 PM, Roger Heflin wrote:
> Hostonly only builds the drivers that are needed to boot the given 
> host.  If you change the disk card it may no longer work.
> 
> Hostonly disabled adds all kernel drivers that could be used to boot.  
> Disabling hostonly should be done prior to starting the hw upgrades.   I 
> generally check the initramfs size before and after the rebuild as 
> disabled hostonly should be much larger.  I have also seen some dists 
> hostonly not work unless an extra rpm is added, and the size being much 
> larger made realize it failed before doing the hw migration and then 
> Having to rescue boot it to fix it.  The note about the extra rpm was in 
> dracut.conf where the hostonly setting is on the dist that needed the 
> extra rpm.

So, any idea how to disable hostonly?  I'm not finding it via google...

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

On 6/26/2022 8:34 AM, Alexander Shenkin wrote:
> So, any idea how to disable hostonly?  I'm not finding it via google...

I should mention that /etc/dracut.conf doesn't exist on my system, and 
the dracut pacakge (if it is a package) doesn't show up in apt list, so 
I'm assuming it's not installed.  Does that mean I don't have hostonly 
installed?

Re: Upgrading motherboard + CPU

[Andy Smith]

Hello,

On Sun, Jun 26, 2022 at 08:44:12AM -0700, Alexander Shenkin wrote:
> 
> On 6/26/2022 8:34 AM, Alexander Shenkin wrote:
> > So, any idea how to disable hostonly?  I'm not finding it via google...
> 
> I should mention that /etc/dracut.conf doesn't exist on my system, and the
> dracut pacakge (if it is a package) doesn't show up in apt list, so I'm
> assuming it's not installed.  Does that mean I don't have hostonly
> installed?

This is a Fedora (and maybe other Red Hat-like) thing. On Debian how
generic your initramfs is, is set in
/etc/initramfs-tools/initramfs.conf:

    # MODULES: [ most | netboot | dep | list ]
    #
    # most - Add most filesystem and all harddrive drivers.
    #
    # dep - Try and guess which modules to load.
    #
    # netboot - Add the base modules, network modules, but skip block devices.
    #
    # list - Only include modules from the 'additional modules' list
    #
    MODULES=most

I think "dep" might be equivalent to this "hostonly" thing, the
point being to include only modules needed for the current hardware
configuration. Which might hamper an effort to move that install
into different hardware. It's not the default.

update-initramfs after changing.

Cheers,
Andy

Re: Upgrading motherboard + CPU

[Pascal Hambourg]

Le 25/06/2022 à 19:10, Wols Lists wrote :
> On 25/06/2022 14:35, Stephan wrote:
>>
>> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?

No. Why would one not use an initramfs ?

> If you're using v1.0, then you could boot off of one of the mirror 
> members no problem.
>
> You would point the kernel boot line at sda1 say (if that's part of your 
> mirror). IFF that is mounted read-only for boot, then that's not a problem.

Mounting read-only does not guarantee that there won't be any write. See 
man mount(8) :

-r, --read-only
     Mount the filesystem read-only. A synonym is -o ro.

Note that, depending on the filesystem type, state and kernel behavior, 
the system may still write to the device. For example, ext3 and ext4 
will replay the journal if the filesystem is dirty. To prevent this kind 
of write access, you may want to mount an ext3 or ext4 filesystem with 
the ro,noload mount options or set the block device itself to read-only 
mode, see the blockdev(8) command.

> Your fstab would then mount /dev/md0 as root read-write

I don't think so. IME the root device in fstab is ignored, only the 
options are used.

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

Ok all.  I've put in the new mobo + CPU, and the BIOS isn't finding any 
bootable devices.  Suggestions for next steps?  Thanks in advance...

Re: Upgrading motherboard + CPU

[Pascal Hambourg]

Le 27/06/2022 à 03:32, Alexander Shenkin a écrit :
> 
> Ok all.  I've put in the new mobo + CPU, and the BIOS isn't finding any 
> bootable devices.  Suggestions for next steps?  Thanks in advance...

Was the system originally installed for BIOS or EFI boot ?

If BIOS, was the bootloader installed in the MBR of all drives ? Does 
the new motherboard support BIOS/legacy boot ?

If EFI, was a copy of the boot loader installed in the "removable media 
path" (\EFI\Boot\Bootx64.efi) of the EFI partition(s) ?

Re: Upgrading motherboard + CPU

[Roman Mamedov]

On Sun, 26 Jun 2022 18:32:26 -0700
Alexander Shenkin <al@shenkin.org> wrote:

> Ok all.  I've put in the new mobo + CPU, and the BIOS isn't finding any 
> bootable devices.  Suggestions for next steps?  Thanks in advance...

As mentioned before, did you find and enable CSM and "Boot mode: UEFI and
Legacy" in BIOS?

If you have trouble finding any of that, perhaps post the motherboard model,
we could check the exact settings to look for.

-- 
With respect,
Roman

Re: Upgrading motherboard + CPU

[Pascal Hambourg]

On 27/06/2022 15:57, Alexander Shenkin wrote :
> 
> CSM is greyed out.  I think I need a graphics card

Is secure boot disabled? Legacy boot is not compatible with secure boot.

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

On 6/27/2022 7:26 AM, Pascal Hambourg wrote:
> On 27/06/2022 15:57, Alexander Shenkin wrote :
>>
>> CSM is greyed out.  I think I need a graphics card
> 
> Is secure boot disabled? Legacy boot is not compatible with secure boot.

There's no way to completely disable secure boot on this mobo.  It's an 
Asus Prime B560M-A.

Re: Upgrading motherboard + CPU

[Ram Ramesh]

On 6/28/22 16:32, Alexander Shenkin wrote:
>
> On 6/27/2022 7:26 AM, Pascal Hambourg wrote:
>> On 27/06/2022 15:57, Alexander Shenkin wrote :
>>>
>>> CSM is greyed out.  I think I need a graphics card
>>
>> Is secure boot disabled? Legacy boot is not compatible with secure boot.
>
> There's no way to completely disable secure boot on this mobo. It's an 
> Asus Prime B560M-A.

Can you boot legacy install with UEFI boot disk? Have you  tried booting 
with sysrescuecd or some such to boot your installed OS?

Have you considered converting UEFI? CSM/Legacy boot support is dropping 
steadily. Sooner or later it will be extinct.

Regards
Ramesh

Re: Upgrading motherboard + CPU

[Alexander Shenkin]

Thanks all,
Once I installed a graphics card, I was able to enable CSM and I've 
booted successfully.  Thanks everyone for your help.  Converting to UEFI 
would be a good idea, though not sure how easy that will be given that 
/boot is a RAID1 array (how do you resize all the partitions, etc?).

Anyway, now looking for a network driver for this mobo...  ;-)

On 6/28/2022 2:57 PM, Ram Ramesh wrote:
> On 6/28/22 16:32, Alexander Shenkin wrote:
>>
>> On 6/27/2022 7:26 AM, Pascal Hambourg wrote:
>>> On 27/06/2022 15:57, Alexander Shenkin wrote :
>>>>
>>>> CSM is greyed out.  I think I need a graphics card
>>>
>>> Is secure boot disabled? Legacy boot is not compatible with secure boot.
>>
>> There's no way to completely disable secure boot on this mobo. It's an 
>> Asus Prime B560M-A.
> 
> Can you boot legacy install with UEFI boot disk? Have you  tried booting 
> with sysrescuecd or some such to boot your installed OS?
> 
> Have you considered converting UEFI? CSM/Legacy boot support is dropping 
> steadily. Sooner or later it will be extinct.
> 
> Regards
> Ramesh
> 

Re: Upgrading motherboard + CPU

[Ram Ramesh]

When all else fails, I use a usb3 NIC until the correct NIC drivers are 
found :-)

I think you can use another disk to install UEFI setup and boot your 
raid from that install. If you do not have a spare disk, use USB to 
experiment. They are cheap to buy and use as you only need a bare 
install (on USB)  to get started.

I converted several legacy to UEFI. However, none was from a RAID. I 
always leave 32G in every install/boot disk for crunch work like this. I 
recommend this. Even the machine that has RAID1 boot has first 32G on 
each RAID1 disk unused (so that I can convert this install too into 
UEFI, when I decide to)

Note that you need GPT for UEFI boot disk. So, separate disk/USB is the 
best.

Ramesh


On 6/28/22 20:05, Alexander Shenkin wrote:
> Thanks all,
> Once I installed a graphics card, I was able to enable CSM and I've 
> booted successfully.  Thanks everyone for your help. Converting to 
> UEFI would be a good idea, though not sure how easy that will be given 
> that /boot is a RAID1 array (how do you resize all the partitions, etc?).
>
> Anyway, now looking for a network driver for this mobo...  ;-)
>
> On 6/28/2022 2:57 PM, Ram Ramesh wrote:
>> On 6/28/22 16:32, Alexander Shenkin wrote:
>>>
>>> On 6/27/2022 7:26 AM, Pascal Hambourg wrote:
>>>> On 27/06/2022 15:57, Alexander Shenkin wrote :
>>>>>
>>>>> CSM is greyed out.  I think I need a graphics card
>>>>
>>>> Is secure boot disabled? Legacy boot is not compatible with secure 
>>>> boot.
>>>
>>> There's no way to completely disable secure boot on this mobo. It's 
>>> an Asus Prime B560M-A.
>>
>> Can you boot legacy install with UEFI boot disk? Have you  tried 
>> booting with sysrescuecd or some such to boot your installed OS?
>>
>> Have you considered converting UEFI? CSM/Legacy boot support is 
>> dropping steadily. Sooner or later it will be extinct.
>>
>> Regards
>> Ramesh
>>

Re: Upgrading motherboard + CPU

[Pascal Hambourg]

On 29/06/2022 04:10, Ram Ramesh wrote :
> 
> Note that you need GPT for UEFI boot disk.

This is only a requirement for Windows (and possibly broken UEFI 
implementations). The UEFI specification allows to boot from a drive 
with a DOS/MBR partition table. Else, assigning a DOS/MBR partition type 
code for EFI system partition (0xef) would be pointless.

> On 6/28/22 20:05, Alexander Shenkin wrote:
>> Once I installed a graphics card, I was able to enable CSM and I've 
>> booted successfully.  Thanks everyone for your help. Converting to 
>> UEFI would be a good idea, though not sure how easy that will be given 
>> that /boot is a RAID1 array (how do you resize all the partitions, etc?).

Setting up redundant EFI boot with software RAID is a pain and a hack.
Resizing RAID partitions is a pain.
So I advise you keep legacy boot as long as you can (but prepare for EFI 
boot on a test machine or VM).

Re: Upgrading motherboard + CPU

[Stephan]

Pascal Hambourg <pascal@plouf.fr.eu.org> writes:

> Le 25/06/2022 à 19:10, Wols Lists wrote :
>> On 25/06/2022 14:35, Stephan wrote:
>>>
>>> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?
>
> No. Why would one not use an initramfs ?

An initramfs adds unnecessary intransparency to the system.  

>> If you're using v1.0, then you could boot off of one of the mirror
>> members no problem.
>>
>> You would point the kernel boot line at sda1 say (if that's part of
>> your mirror). IFF that is mounted read-only for boot, then that's
>> not a problem.
>
> Mounting read-only does not guarantee that there won't be any
> write. See man mount(8) :
>
> -r, --read-only
>     Mount the filesystem read-only. A synonym is -o ro.
>
> Note that, depending on the filesystem type, state and kernel
> behavior, the system may still write to the device. For example, ext3
> and ext4 will replay the journal if the filesystem is dirty. To
> prevent this kind of write access, you may want to mount an ext3 or
> ext4 filesystem with the ro,noload mount options or set the block
> device itself to read-only mode, see the blockdev(8) command.

Good point.  Thus, there is no alternative to superblock 0.90 for root on
mdraid w/o initramfs.  This is the answer to the question why somebody
(like me) may need to use superblock 0.90.

>> Your fstab would then mount /dev/md0 as root read-write
>
> I don't think so. IME the root device in fstab is ignored, only the
> options are used.

This is some of the intransparency.  Will the / entry in the /etc/fstab
be copied to the initramfs to use it for mounting the real root
filesystem?  You imply that this is the case but the device will be
ignored.  Why?  

Gruß,
-- 
Stephan

Re: Upgrading motherboard + CPU

[Pascal Hambourg]

Le 27/06/2022 à 09:13, Stephan a écrit :
> Pascal Hambourg <pascal@plouf.fr.eu.org> writes:
> 
>> Le 25/06/2022 à 19:10, Wols Lists wrote :
>>> On 25/06/2022 14:35, Stephan wrote:
>>>>
>>>> Does mdraid with metadata 1 work on the root filesystem w/o initramfs?
>>
>> No. Why would one not use an initramfs ?
> 
> An initramfs adds unnecessary intransparency to the system.

An initramfs is already necessary if root|usr|hibernation swap is on LVM 
or LUKS, if UUID or LABEL is used for root specification, with 
merged+separated /usr... Some distributions do not support booting 
without an initramfs any more.

>>> If you're using v1.0, then you could boot off of one of the mirror
>>> members no problem.
>>>
>>> You would point the kernel boot line at sda1 say (if that's part of
>>> your mirror). IFF that is mounted read-only for boot, then that's
>>> not a problem.
>>
>> Mounting read-only does not guarantee that there won't be any
>> write. See man mount(8)
(...)
> Good point.  Thus, there is no alternative to superblock 0.90 for root on
> mdraid w/o initramfs.  This is the answer to the question why somebody
> (like me) may need to use superblock 0.90.
> 
>>> Your fstab would then mount /dev/md0 as root read-write
>>
>> I don't think so. IME the root device in fstab is ignored, only the
>> options are used.
> 
> This is some of the intransparency.  Will the / entry in the /etc/fstab
> be copied to the initramfs to use it for mounting the real root
> filesystem?  You imply that this is the case but the device will be
> ignored.  Why?

There are different kind of initramfs out there, and I don't know them 
all. I can only speak about the initramfs built by initramfs-tools used 
by default in Debian and derivatives.

AFAIK, /etc/fstab is not copied into the initramfs. The initramfs uses 
only the command line parameters (root=, rootfstype=, rootflags=, 
ro|rw...) to mount the real root filesystem, then hands over to the real 
root init.

At some point, init remounts the root filesystem (mount -o remount /) to 
apply the mount options in /etc/fstab (this is usually when ro is 
changed to rw). Remount does not change the root device.

Re: a new install - - - putting the system on raid

[Pascal Hambourg]

Le 24/06/2022 à 20:20, Roman Mamedov wrote :
> 
> I think the key decider in whether or not a RAIDed swap should be a must-have,
> is whether the system has hot-swap bays for drives.

Why ? What has hot-swap to do with RAIDed swap ?

> Also, it seemed like the discussion began in the context of setting up a home
> machine, or something otherwise not as mission-critical. And in those cases,
> almost nobody will have hot-swap.
> 
> As such, if you have to bring down the machine to replace a drive anyway, might
> as well tolerate the risk of it going down with a bang (due to a part of swap
> going away)

I disagree. Even without hot-swap, RAIDed swap allows you to control how 
and when the downtime happens in order to replace a faulty drive. 
Without RAIDed swap, you cannot.