My computers have two drive caddies.
Only one is normally enabled because they are bootable drives.

However,

I would have cloned the first drive to the second using a live
CD/DVD/flash drive. But thereafter they get out of sync.

If i could "slightly" disable the second drive so that when mounted it
not be seen as a boot drive, I could update it using rsync.

But, I would like to restore it as a boot drive when I need to 'er boot
from it.

What is the smallest action I can take that would disable/enable the
bootability of the second drive?

TIA, Alan

--
Mint 20.3, kernel 5.4.0-139-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of
DRAM.

Am 08.03.2023 schrieb pinnerite <pinnerite@gmail.com>:

> I would have cloned the first drive to the second using a live
> CD/DVD/flash drive. But thereafter they get out of sync.

Make sure the partitions there get a new UUID - it will confuse
operating systems if 2 partitions have the same UUID.

If you want redundancy, use RAID.

> If i could "slightly" disable the second drive so that when mounted it
> not be seen as a boot drive, I could update it using rsync.

How do you boot?
UEFI or BIOS boot?

On Wed, 8 Mar 2023 11:30:36 +0000
pinnerite <pinnerite@gmail.com> wrote:

> What is the smallest action I can take that would disable/enable the
> bootability of the second drive?
>
> TIA, Alan
>
Gparted, select drive, Partition, manage flags, Remove check mark from boot
Try might help

--
Mint 21.1 Vera, kernel 5.19.0-32-generic, Cinnamon 5.6.7
AMD Ryzen 7 5700G with Radeon Vega Graphics, 16GB of DRAM.

Am 08.03.2023 schrieb yossarian <<nomail@gmail.com>>:

> Gparted, select drive, Partition, manage flags, Remove check mark
> from boot Try might help

My disks don't have that flag and can still boot via BIOS.
It seems that this flag is unrelated to most BIOS implementations.

On Wed, 8 Mar 2023 11:30:36 +0000, pinnerite wrote:
> My computers have two drive caddies.
> Only one is normally enabled because they are bootable drives.
>
> However,
>
> I would have cloned the first drive to the second using a live
> CD/DVD/flash drive. But thereafter they get out of sync.
>
> If i could "slightly" disable the second drive so that when mounted it
> not be seen as a boot drive, I could update it using rsync.

I use rsync all the time to backup my "Production" install and my
Cauldron installs. I just modify /etc/fstab so the the undesired
partitions have ,noauto as one of the mount options.

Examples:
LABEL=cauldron_bkup /cauldron_bkup ext4 users,noauto,relatime,acl 1 2
LABEL=net_ins_bkup /net_ins_bkup ext4 users,noauto,relatime,acl 1 2
/spare/bkup.iso /bkup auto users,noauto,ro 0 0

The backup script just mounts the target partition prior to running
the rsync command and umounts it upon completion.

Homework: man mount

On 3/8/2023 9:17 AM, Marco Moock wrote:
> Am 08.03.2023 schrieb yossarian <<nomail@gmail.com>>:
>
>> Gparted, select drive, Partition, manage flags, Remove check mark
>> from boot Try might help
>
> My disks don't have that flag and can still boot via BIOS.
> It seems that this flag is unrelated to most BIOS implementations.
>

[Picture]

https://i.postimg.cc/ZRvVX031/boot-flag-windows-only.gif

That flag is used by the Windows MBR code, to select a Windows
partition to be the boot partition.

It's only used on legacy partitioned disks (three primary, extended/logical).

On a GPT disk, the boot information is stored in the ESP, so
boot flags are not needed in the usual way.

A GPT disk does have an MBR sector and you *could* set a boot
flag, but the rest of the infrastructure to use the boot flag,
isn't present. The partition table is used, only in the sense
that the first partition (type 0xEE) marks the disk as being
"in use" and so no legacy routines can accidentally use the disk
drive for their own purposes. The 0xEE partition, is sized to
cover a 2.2TB disk area, which is all of the area that the
legacy environment knows how to work with. So the 0xEE
partition "provides cover against accidents". And this is a
technique used on other OSes that have two disk partitioning
formats. They always cover the old format, so it cannot be
used by accident.

Paul

On 3/8/2023 10:07 AM, Paul wrote:
> On 3/8/2023 9:17 AM, Marco Moock wrote:
>> Am 08.03.2023 schrieb yossarian <<nomail@gmail.com>>:
>>
>>> Gparted, select drive, Partition, manage flags, Remove check mark
>>> from boot Try might help
>>
>> My disks don't have that flag and can still boot via BIOS.
>> It seems that this flag is unrelated to most BIOS implementations.
>>
>
>    [Picture]
>
>     https://i.postimg.cc/ZRvVX031/boot-flag-windows-only.gif
>
> That flag is used by the Windows MBR code, to select a Windows
> partition to be the boot partition.
>
> It's only used on legacy partitioned disks (three primary, extended/logical).
>
> On a GPT disk, the boot information is stored in the ESP, so
> boot flags are not needed in the usual way.
>
> A GPT disk does have an MBR sector and you *could* set a boot
> flag, but the rest of the infrastructure to use the boot flag,
> isn't present. The partition table is used, only in the sense
> that the first partition (type 0xEE) marks the disk as being
> "in use" and so no legacy routines can accidentally use the disk
> drive for their own purposes. The 0xEE partition, is sized to
> cover a 2.2TB disk area, which is all of the area that the
> legacy environment knows how to work with. So the 0xEE
> partition "provides cover against accidents". And this is a
> technique used on other OSes that have two disk partitioning
> formats. They always cover the old format, so it cannot be
> used by accident.
>
>    Paul

There is actually a case where a Linux uses the boot flag.

https://www.rodsbooks.com/gdisk/booting.html

"The SYSLINUX boot loader is another Linux boot loader that
includes GPT support. This support resides in the MBR and redirects
the boot process to a partition with the Legacy BIOS Bootable flag set.
AFAIK, no Linux distribution relies on SYSLINUX to boot from a GPT disk,
but you could set yours up to use this boot method if you liked."

As you can see from that article, "booting is a zoo".

Paul

On Wed, 8 Mar 2023 10:07:26 -0500
Paul <nospam@needed.invalid> wrote:

> On 3/8/2023 9:17 AM, Marco Moock wrote:
> > Am 08.03.2023 schrieb yossarian <<nomail@gmail.com>>:
> >
> [...]
> >
> > My disks don't have that flag and can still boot via BIOS.
> > It seems that this flag is unrelated to most BIOS implementations.
> >
>
> [Picture]
>
> https://i.postimg.cc/ZRvVX031/boot-flag-windows-only.gif
>
> That flag is used by the Windows MBR code, to select a Windows
> partition to be the boot partition.
>
On my wife Mint 19 comp, there is a flag for boot
https://i.postimg.cc/8Ck9jF4k/Screenshot-from-2023-03-08-16-43-51.png
I have dual boot so my flag is on windows efi partition.

On Wed, 8 Mar 2023 15:17:56 +0100
Marco Moock <mo01@posteo.de> wrote:

> Am 08.03.2023 schrieb yossarian <<nomail@gmail.com>>:
>
> > Gparted, select drive, Partition, manage flags, Remove check mark
> > from boot Try might help
>
> My disks don't have that flag and can still boot via BIOS.
> It seems that this flag is unrelated to most BIOS implementations.
>
My computers use UEFI so I don't know about BIOS implementations.

--
Mint 21.1 Vera, kernel 5.19.0-32-generic, Cinnamon 5.6.7
AMD Ryzen 7 5700G with Radeon Vega Graphics, 32GB of DRAM.

On 3/8/2023 6:30 AM, pinnerite wrote:
> My computers have two drive caddies.
> Only one is normally enabled because they are bootable drives.
>
> However,
>
> I would have cloned the first drive to the second using a live
> CD/DVD/flash drive. But thereafter they get out of sync.
>
> If i could "slightly" disable the second drive so that when mounted it
> not be seen as a boot drive, I could update it using rsync.
>
> But, I would like to restore it as a boot drive when I need to 'er boot
> from it.
>
> What is the smallest action I can take that would disable/enable the
> bootability of the second drive?
>
> TIA, Alan

Two hot disks, is not redundancy. If the power supply
fails, both hard drives could be destroyed.

The second disk (your emergency disk) should remain
unplugged while the working disk is in usage.

Making a backup of the working disk, then storing
that backup offline, protects the backup image.

Primary drive --------> backup image -------+
|
Secondary drive <---------+

Restoring the backup image to the second disk, gives
you a device to boot from. The reason for this idea, is
simplicity of procedure. You want backup and restore
commands that do all the work for you. Rather than you
working like crazy to manage your disks.

While you could zero out the MBR, or zero out the ESP
(and keep backups of them in a safe place), then there's
not much reason to keep the drive powered and in the chassis.

In the GPT environment, the MBR does not contain too much of
absolute value. But it does have 0xAA55 up near the end of
the sector, which indicate the sector has been initialized.
I don't know what happens to a GPT disk, if the MBR indicates
it is not initialized.

The description of GPT boot, makes it sound like the two GPT
partitions are what the UEFI BIOS is sniffing. GPT partition tables
are relatively small, and might be something like 128 entries
times 1KB each. One table near the origin of the disk, the
second table (the "nuisance table") is up near the end, and
makes it difficult to clone drives to a different size new drive.

https://www.rodsbooks.com/gdisk/booting.html

Removing the ESP (zero it out), then there is no boot menu, and
so the parser for UEFI must stop considering the disk drive.
You could put a FAT32 in place of the ESP, where the folders
have been removed. That would be sufficient to stop it.
While direct editing of the ESP is forbidden, you can

sudo dd if=/dev/sda1 of=myESP.bin # This transfers 512 bytes at a time.
# Until it hits the end of sda1.

and transfer it out. Or restore it as

sudo dd if=myESP.bin of=/dev/sda1

You can put a cooked version of the ESP in place, as

sudo dd if=myCookedESP.bin of=/dev/sda1

You can loopback mount an ESP as a normal FAT32, using
this sort of thing. You could delete everything you find
in here, and then this myESP.bin becomes myCookedESP.bin .

sudo mount -o loop myESP.bin /mnt/temp
cd /mnt/temp
ls

But the notion of managing disk drives this way,
this boggles the mind. Sooner or later you will
have an accident. it's like running at the swimming pool,
or taking up chainsaw juggling as a hobby. The risk is
too great for the reward.

Summary: Your question can be answered via experimentation,
but it will take a while. The Rodsbook article is
certainly thorough, but I don't know if your exact
scenario is considered there. The idea of having
partitions with exactly the same UUIDs and so on, now
that doesn't sound likely to work.

I think a conventional backup, and a bare metal restore,
are sufficient as a solution. The backup could be a tar file
or some other form of container, which a UEFI would have no
interest in such a thing. This means a third drive holds
the backup.

The results of your experiments would be interesting,
but I'm not convinced that the results of the experiment
are suitable as a "workflow". Any more than standing on
my head, is a cheap way to get a haircut.

Paul

Am 08.03.2023 um 10:07:26 Uhr schrieb Paul:

> That flag is used by the Windows MBR code, to select a Windows
> partition to be the boot partition.
>
> It's only used on legacy partitioned disks (three primary,
> extended/logical).
>
> On a GPT disk, the boot information is stored in the ESP, so
> boot flags are not needed in the usual way.

Boot flags aren't needed for classic boot anyway.
I had a GPT partition table and BIOS boot (no UEFI).
No boot flag set.
I also had Linux machines with MBR partition table and no boot flag.

Is it maybe just Windows that sets it?

I read in a German newsgroup that very few BIOS implementations could
only boot when boot flag on partition has been set, but this is a very
rare circumstance.

On Wed, 8 Mar 2023 12:55:57 +0100
Marco Moock <mo01@posteo.de> wrote:

> Am 08.03.2023 schrieb pinnerite <pinnerite@gmail.com>:
>
> > I would have cloned the first drive to the second using a live
> > CD/DVD/flash drive. But thereafter they get out of sync.

I have been cloning booting from a live CD/DVD, either Knoppix or
Parted Magic for about 15 years without a problem using dd.

What I want to do now is intended to update one from the other so as
to ensure they remain in sync until I need to restore the second to a
bootable state.

In all probablity I would not need to do this more than monthly.

>
> Make sure the partitions there get a new UUID - it will confuse
> operating systems if 2 partitions have the same UUID.
>
> If you want redundancy, use RAID.
>
> > If i could "slightly" disable the second drive so that when mounted it
> > not be seen as a boot drive, I could update it using rsync.
>
> How do you boot?
> UEFI or BIOS boot?
>

I should have said BIOS boot.

--
Mint 20.3, kernel 5.4.0-139-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of
DRAM.

On 08/03/2023 20:10, Marco Moock wrote:
> I also had Linux machines with MBR partition table and no boot flag.

Marco,

I'm wondering how the BIOS knows which drive has the bootloader on it.

Cheers,
David in Co Longford

On 3/8/2023 5:52 PM, David Catterall wrote:
> On 08/03/2023 20:10, Marco Moock wrote:
>> I also had Linux machines with MBR partition table and no boot flag.
>
> Marco,
>
> I'm wondering how the BIOS knows which drive has the bootloader on it.
>
> Cheers,
>  David in Co Longford

It scans them all.

And, it gets pissed when it finds two Windows Boot Managers :-)

I would have hoped, that disks would be analyzed independently,
such that two Windows Boot Managers could live in harmony, but
that isn't entire the case. I've also had the odd problem here
(recently), with perfectly legit configs being present, and
I end up getting a "no bootable things are available" message
on a black background. This means the UEFI has done its scan,
and was unable to parse up any path strings.

It's my suspicion, that the UEFI standard was invented for
"systems in a bottle", operated by Secure Boot, and not
intended for a dynamic environment as such. it is not a BIOS
invented for us -- it's a BIOS invented for Microsoft business
interests (Surface).

The legacy BIOS is much more tolerant of complex configurations,
such as your suggestion of a first stage boot being on one physical
device, and the OS partition being on a second device. Or, having
two boot processes sitting on the disks, and the user steers which
path is used, via the selection of which disk to scan first.

As a result of the behaviors, I am actually hesitant to put two
disks with UEFI Windows Boot Managers in the machine at the same time.
I did select one once, then the evidence later was, the UEFI BIOS
actually launched the other disk. Disconcerting.

Paul

Am 08.03.2023 schrieb pinnerite <pinnerite@gmail.com>:

> I have been cloning booting from a live CD/DVD, either Knoppix or
> Parted Magic for about 15 years without a problem using dd.
>
> What I want to do now is intended to update one from the other so as
> to ensure they remain in sync until I need to restore the second to a
> bootable state.
>
> In all probablity I would not need to do this more than monthly

It depends how the partition is being mounted. If it is being mounted
via the name /dev/sdXY, it works. If it is being mounted by the label
or UUID, it will be ambiguous.

Am 08.03.2023 schrieb David Catterall <djcatt@eircom.net>:

> I'm wondering how the BIOS knows which drive has the bootloader on it.

You select one disk (like HDD1 WD2500JS) and it will look in the 1st
sector.
Then it loads the software from there.

Am 09.03.2023 schrieb Paul <nospam@needed.invalid>:

> It's my suspicion, that the UEFI standard was invented for
> "systems in a bottle", operated by Secure Boot, and not
> intended for a dynamic environment as such. it is not a BIOS
> invented for us -- it's a BIOS invented for Microsoft business
> interests (Surface).

I cannot agree with it. SecureBoot is handled by MS - but you can
disable it and you can place your own keys inside.
The only thing is that there exist bad UEFI implementations that don't
allow this.

EFI boot management is much easier when multiple operating systems with
multiple boot loaders exist.

> As a result of the behaviors, I am actually hesitant to put two
> disks with UEFI Windows Boot Managers in the machine at the same time.
> I did select one once, then the evidence later was, the UEFI BIOS
> actually launched the other disk. Disconcerting.

You need to select a boot loader in the EFI partition. This makes sure
that the specific loader is being booted.

Am 08.03.2023 schrieb Paul <nospam@needed.invalid>:

> Removing the ESP (zero it out), then there is no boot menu, and
> so the parser for UEFI must stop considering the disk drive.

This isn't all.
There is an entry in the NVRAM on the motherboard. This needs to be
removed too.

This can be done in the UEFI firmware setup or under Linux via
efibootmgr.

On 09/03/2023 07:40, Marco Moock wrote:

> Am 08.03.2023 schrieb David Catterall <djcatt@eircom.net>:
>
>> I'm wondering how the BIOS knows which drive has the bootloader on it.
>
> You select one disk (like HDD1 WD2500JS) and it will look in the 1st
> sector.
> Then it loads the software from there.
>

Does that mean that you are able to Press a Key (such as F11) during
boot-up and your BIOS will offer you a choice of drives to select?

D.

Am 09.03.2023 schrieb David Catterall <djcatt@eircom.net>:

> On 09/03/2023 07:40, Marco Moock wrote:
>
> > Am 08.03.2023 schrieb David Catterall <djcatt@eircom.net>:
> >
> >> I'm wondering how the BIOS knows which drive has the bootloader on
> >> it.
> >
> > You select one disk (like HDD1 WD2500JS) and it will look in the 1st
> > sector.
> > Then it loads the software from there.
> >
>
> Does that mean that you are able to Press a Key (such as F11) during
> boot-up and your BIOS will offer you a choice of drives to select?

Yes. That is the case on my older BIOS-based Motherboards.

On 3/9/2023 2:44 AM, Marco Moock wrote:

>
> You need to select a boot loader in the EFI partition. This makes sure
> that the specific loader is being booted.

In my example, it failed to do that. And jumped to the second disk drive.
This was while using the F8 Popup Boot menu, where the two
Windows Boot Manager menu items (plus their disk drive identifier) are sitting.

Paul

On 3/9/2023 6:00 AM, David Catterall wrote:
> On 09/03/2023 07:40, Marco Moock wrote:
>
>> Am 08.03.2023 schrieb David Catterall <djcatt@eircom.net>:
>>
>>> I'm wondering how the BIOS knows which drive has the bootloader on it.
>>
>> You select one disk (like HDD1 WD2500JS) and it will look in the 1st
>> sector.
>> Then it loads the software from there.
>>
>
> Does that mean that you are able to Press a Key (such as F11) during boot-up and your BIOS will offer you a choice of drives to select?
>
> D.

That capability started around the year 2005. Popup boot
was first offered with legacy BIOS, but also exists with UEFI machines.

The feature was "standardized enough" among legacy BIOS companies,
that the color of the blue border is a standard of sorts. So even
if Dell can't be bothered to do it right, at least the border
will be the color of blue.

On something like VirtualBox, if you enable UEFI in the Guest settings
panel, then hammer <esc> key, the middle choice there causes a popup
boot menu to appear. The dimensions are not right. But the color
around the whole dialog is "blue", to remind you where you are :-)

The "color" is the most solid part of the popup boot concept.

Paul

On Thu, 9 Mar 2023 08:39:45 +0100
Marco Moock <mo01@posteo.de> wrote:

> Am 08.03.2023 schrieb pinnerite <pinnerite@gmail.com>:
>
> > I have been cloning booting from a live CD/DVD, either Knoppix or
> > Parted Magic for about 15 years without a problem using dd.
> >
> > What I want to do now is intended to update one from the other so as
> > to ensure they remain in sync until I need to restore the second to a
> > bootable state.
> >
> > In all probablity I would not need to do this more than monthly
>
> It depends how the partition is being mounted. If it is being mounted
> via the name /dev/sdXY, it works. If it is being mounted by the label
> or UUID, it will be ambiguous.
>

For cloning they are unmounted.

--
Mint 20.3, kernel 5.4.0-139-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of DRAM.

On 3/9/2023 2:46 AM, Marco Moock wrote:
> Am 08.03.2023 schrieb Paul <nospam@needed.invalid>:
>
>> Removing the ESP (zero it out), then there is no boot menu, and
>> so the parser for UEFI must stop considering the disk drive.
>
> This isn't all.
> There is an entry in the NVRAM on the motherboard. This needs to be
> removed too.
>
> This can be done in the UEFI firmware setup or under Linux via
> efibootmgr.
>

Well, I tried messing with it, and the results were weird.

You're right, that the NVRAM caches it.

But the NVRAM also has triggers for when it is supposed
to re-evaluate the structure on the disk.

And while I was working on the drive, I did not manage to
trigger a re-evaluation of the disk.

I dd-transferreed the FAT32 partition and loopback mounted it.
I deleted the Microsoft and Ubuntu folders (rm -Rf *).

Now, instead of the "normal" behavior, the deleted entries
show in a red color. I don't know what feature of a FAT
would do this. A deleted item, a single byte is flipped
to change the status of an item to deleted. So it is not
really deleted. But normally, it is not visible after
it has been deleted.

After I deleted "Microsoft" and "Ubuntu", then dd-transferred
the partition back into the ESP, the boot menu was relatively
unchanged (even though the corresponding folders were deleted).
If I selected "Windows Boot Manager", I get the black screen
with the "cannot find bootable stuff" message. The same thing
happened when I selected the Ubuntu entry. It could not find
that either (because I had deleted the materials). But
the cosmetics remain unchanged.

When I overwrote the white space on the partition, with
a very large zero-filled file, this made the Microsoft red text
disappear, to be replaced by the "big.bin" of my erasure file.
But it still didn't change anything else.

So something about that FAT32, is different than a regular FAT32.

But I did also achieve the result, that at least it could not
boot from the items on the disk. It refused because the
folder contents really weren't there. On purpose, I did not
reformat the file system and put my own FAT32 on there. That would
have changed all the identifiers on there, if I had tried.

Paul