Hi,
I have a small SSD that I use for /boot and /boot/efi partitions - /dev/sda
I boot from /dev/sda
I have another small SSD that I use as a dd backup of /dev/sda - /dev/sdg
After update to a new kernel, I dd the /dev/sda to /dev/sdg so that in case of a failure I could boot from /dev/sdg.
This scenario worked perfectly till several weeks ago.
What is happening now is that the machine boots from /dev/sda, but then mounts /dev/sdg for its /boot and /boot/efi. So in df I see /dev/sdg instead of /dev/sda that the machine booted from.
I solved the problem by editing /etc/fstab and pointing /boot and /boot/efi to the relevant /dev/sda[1-2] instead of the original UUID.
Question: is this solution OK or have I done something wrong? Is there a better way of solving this?
Thanks Frank
Once upon a time, Frank Bures buresf@gmail.com said:
Question: is this solution OK or have I done something wrong? Is there a better way of solving this?
It'd probably be better to do backups by copying files rather than blocks. There are a variety of things that look at filesystems by UUID, and the plus of using them in /etc/fstab is that there are cases where drive order is not deterministic or can change if there's a hardware change (e.g. what is /dev/sda this boot could be /dev/sdc next boot). The UEFI boot manager and GRUB also use UUIDs to find things, so having duplicates is unpredictable.
It doesn't apply in this case (just noting it), but you should definitely never do block backups of LVM like this, because LVM will stop when it finds multiple devices with the same UUID.
Also, you are putting more wear on the SSD backup drive this way, because you are writing all blocks (whether they're in use or not and whether they've changed or not). If you make new filesystems on your backup drive, mount them somewhere, and then use something like rsync to make your copies, you'll greatly reduce the writes to your SSD and extend its life.
On Tue, 18 Jun 2024 11:23:57 -0400 Frank Bures wrote:
Question: is this solution OK or have I done something wrong? Is there a better way of solving this?
Using dd to back up a disk leaves the copy with the exact same UUID as the source. So it is just down to random timing and order of operations as to which disk it will choose, so using /dev/sda instead of UUID is one possible solution, but there are UUID values in lots more places than /etc/fstab. (grub.cfg for one, but other files as well like the /boot/loader/entries files).
Personally, I'd just use rsync to back up the contents of sda rather than doing a dd of the whole disk. That way everyone could have their own UUIDs.
On 2024-06-18 11:40, Tom Horsley wrote:
On Tue, 18 Jun 2024 11:23:57 -0400 Frank Bures wrote:
Question: is this solution OK or have I done something wrong? Is there a better way of solving this?
Using dd to back up a disk leaves the copy with the exact same UUID as the source. So it is just down to random timing and order of operations as to which disk it will choose, so using /dev/sda instead of UUID is one possible solution, but there are UUID values in lots more places than /etc/fstab. (grub.cfg for one, but other files as well like the /boot/loader/entries files).
Personally, I'd just use rsync to back up the contents of sda rather than doing a dd of the whole disk. That way everyone could have their own UUIDs.
Just to explain:
I do not dd the whole /dev/sda. There are only /boot and /boot/efi partitions on the disk, the rest is unformatted. I only dd the formatted sectors.
The whole idea of having the same UUID on both sda and sdg is the ability of just booting from the other disk in case of sda failure without having to reconfigure anything. Now I understand the problem this arrangement creates.
If I understand correctly, doing rsync backup would not guarantee this direct boot functionality.
Any other thoughts?
Thanks Frank
On 2024-06-18 13:52, Frank Bures wrote:
Just to explain:
I do not dd the whole /dev/sda. There are only /boot and /boot/efi partitions on the disk, the rest is unformatted. I only dd the formatted sectors.
The whole idea of having the same UUID on both sda and sdg is the ability of just booting from the other disk in case of sda failure without having to reconfigure anything. Now I understand the problem this arrangement creates.
If I understand correctly, doing rsync backup would not guarantee this direct boot functionality.
Any other thoughts?
Or I could just live with it. Let the machine decide, which disk it wants to mount and then copy the boot disk to that disk. I could even automatize the backup script to make the decision by itself. In fact, there is no difference between mounting sda or sdg as /boot if they are the same with the same UUID..
Cheers Frank
On mine I have md raid1 configured for /boot. Old install no /boot/efi but it should also work for /boot/efi because even with mdraid the bios/efi will still be able to find what it needs to find to boot but when the OS comes up it mounts the md-raid raid1 devices.
This would allow you to survive a disk failure, but not survive a bad deletion at the fs level.
On Tue, Jun 18, 2024 at 12:59 PM Frank Bures buresf@gmail.com wrote:
On 2024-06-18 13:52, Frank Bures wrote:
Just to explain:
I do not dd the whole /dev/sda. There are only /boot and /boot/efi partitions on the disk, the rest is unformatted. I only dd the formatted sectors.
The whole idea of having the same UUID on both sda and sdg is the ability of just booting from the other disk in case of sda failure without having to reconfigure anything. Now I understand the problem this arrangement creates.
If I understand correctly, doing rsync backup would not guarantee this direct boot functionality.
Any other thoughts?
Or I could just live with it. Let the machine decide, which disk it wants to mount and then copy the boot disk to that disk. I could even automatize the backup script to make the decision by itself. In fact, there is no difference between mounting sda or sdg as /boot if they are the same with the same UUID..
Cheers Frank
--
listfrank1@gmail.com
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Once upon a time, Roger Heflin rogerheflin@gmail.com said:
On mine I have md raid1 configured for /boot. Old install no /boot/efi but it should also work for /boot/efi because even with mdraid the bios/efi will still be able to find what it needs to find to boot but when the OS comes up it mounts the md-raid raid1 devices.
This would allow you to survive a disk failure, but not survive a bad deletion at the fs level.
Yeah, I use MD RAID1 for both /boot and /boot/efi (you need to use the "old style" version 1.0 metadata for /boot/efi so that it looks the same as a plain partition to the firmware). GRUB understands MD RAID1 and can handle it, and the UEFI boot manager can have multiple "Fedora" entries (one with each partition's UUID).
On 2024-06-18 14:33, Roger Heflin wrote:
On mine I have md raid1 configured for /boot. Old install no /boot/efi but it should also work for /boot/efi because even with mdraid the bios/efi will still be able to find what it needs to find to boot but when the OS comes up it mounts the md-raid raid1 devices.
If I decide to change my setup to /boot and /boot/efi on RAID1 I can do it. However, how do I change the grub2 stuff so that the machine knows that the boot device has changed? I use UEFI boot.
Thanks Frank
On 6/18/24 19:58, Frank Bures wrote:
Or I could just live with it. Let the machine decide, which disk it wants to mount and then copy the boot disk to that disk. I could even automatize the backup script to make the decision by itself. In fact, there is no difference between mounting sda or sdg as /boot if they are the same with the same UUID..
You have to be careful to always have the two in sync. Otherwise you install a new kernel in boot(sda), then reboot and it start from boot(sdg) where the new kernel is missing.
If you want to keep them aligned with dd, consider that the uuid can be changed for the copy by using tune2fs for ext2/3/4, and something else (mlabel?) for FAT32. As for the "copying all the blocks and stress the SSD", you can fstrim the filesystem after the copy to release the unused blocks (fstrim works for FAT32 too).
Regards.
On 6/18/24 12:52, Frank Bures wrote:
On 2024-06-18 11:40, Tom Horsley wrote:
On Tue, 18 Jun 2024 11:23:57 -0400 Frank Bures wrote:
Question: is this solution OK or have I done something wrong? Is there a better way of solving this?
--SNIP--
Personally, I'd just use rsync to back up the contents of sda rather than doing a dd of the whole disk. That way everyone could have their own UUIDs.
--SNIP--
If I understand correctly, doing rsync backup would not guarantee this direct boot functionality.
Actually, with UEFI you _can_ use rsync and preserve the boot function. The old days of boot code depending on absolute disk block addresses are gone. All stages of the boot loader now parse the file system structures to locate the blocks to read, so there is no problem with files not located at the same physical addresses on your two disks. The EFI partition is required to be an FAT filesystem because that's what the UEFI firmware is able to parse.
On Tue, 2024-06-18 at 11:40 -0400, Tom Horsley wrote:
Using dd to back up a disk leaves the copy with the exact same UUID as the source. So it is just down to random timing and order of operations as to which disk it will choose, so using /dev/sda instead of UUID is one possible solution, but there are UUID values in lots more places than /etc/fstab. (grub.cfg for one, but other files as well like the /boot/loader/entries files).
If one was cloning a drive so you can quickly recover from a failure by using the other drive, I would think that for the least surprises, you have to be unplugging the copy when cloned. Then actually swap drives over if you needed to use it, instead.
On 19 Jun 2024 at 14:52, Tim via users wrote:
Subject: Re: Interesting mount problem - F40 To: Community support for Fedora users users@lists.fedoraproject.org Date sent: Wed, 19 Jun 2024 14:52:36 +0930 Send reply to: Community support for Fedora users users@lists.fedoraproject.org From: Tim via users users@lists.fedoraproject.org Copies to: listfrank1@gmail.com, Tim ignored_mailbox@yahoo.com.au
On Tue, 2024-06-18 at 11:40 -0400, Tom Horsley wrote:
Using dd to back up a disk leaves the copy with the exact same UUID as the source. So it is just down to random timing and order of operations as to which disk it will choose, so using /dev/sda instead of UUID is one possible solution, but there are UUID values in lots more places than /etc/fstab. (grub.cfg for one, but other files as well like the /boot/loader/entries files).
If one was cloning a drive so you can quickly recover from a failure by using the other drive, I would think that for the least surprises, you have to be unplugging the copy when cloned. Then actually swap drives over if you needed to use it, instead.
I've been the maintainer of the G4L disk imaging project going back to 2004. If the mounting is using the blkid of the partitions that is definitely true. If it was using /dev/sdx then would also have to modify that or switch the connections.
If you clone drives at the bit level that is true. G4L also allowed maked img files, that are compressed, and could then be restored to a new disk to replace a failed disk, and then having the same blkid as original was not a problem.
--
uname -rsvp Linux 3.10.0-1160.118.1.el7.x86_64 #1 SMP Wed Apr 24 16:01:50 UTC 2024 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.
-- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com mailto:msetzerii@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
Frank Bures writes:
What is happening now is that the machine boots from /dev/sda, but then mounts /dev/sdg for its /boot and /boot/efi. So in df I see /dev/sdg instead of /dev/sda that the machine booted from.
I solved the problem by editing /etc/fstab and pointing /boot and /boot/efi to the relevant /dev/sda[1-2] instead of the original UUID.
Question: is this solution OK or have I done something wrong? Is there a better way of solving this?
Yes, that's what I do too, in a very similar situation.
-
Chris Adams -
Frank Bures -
Michael D. Setzer II -
Robert Nichols -
Roberto Ragusa -
Roger Heflin -
Sam Varshavchik -
Tim -
Tom Horsley