3:28 a.m.
Bonjour,
I am following advices given in answering my previous post "issue...."
and I get f38 installer.
The installer complains that there is a duplicate UUID on some disks :
parts sde1 and sdf1
That's true! Running blkid gives:
/dev/sde1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
UUID_SUB="88a5f939-72d4-b330-95e6-52fa0b826203" LABEL="dipankar:4"
TYPE="linux_raid_member" PARTUUID="c257bd85-01"
^^^^^^^^^^^
/dev/sdf1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
UUID_SUB="99b46805-aa31-1711-21dc-89cb7177d025" LABEL="dipankar:4"
TYPE="linux_raid_member" PARTUUID="c257bd85-01"
^^^^^^^^^^^^
But it is not the only case and it does not complain for the other one:
/dev/sde2: UUID="5240f249-7feb-6832-6682-805f97c4abea"
UUID_SUB="0e21ab45-27a2-f588-48a9-cd46d0dc6237" LABEL="dipankar:5"
TYPE="linux_raid_member" PARTUUID="c257bd85-02"
^^^^^^^^^^^
/dev/sdf2: UUID="5240f249-7feb-6832-6682-805f97c4abea"
UUID_SUB="5838df23-817e-f3cb-19f3-31da8d3e99d0" LABEL="dipankar:5"
TYPE="linux_raid_member" PARTUUID="c257bd85-02"
^^^^^^^^^^^^
What does this mean? And what shall I do?
The installer suggests to unplug these disks (or at list one of these
disks) but, as you can see these disks are members of a raid array with
the swap, /var and a crypted partition (sde1 and sdf1) and /home (sde2
and sdf2)....
Is it possible to unplug one of the disks (say sdf) and make an install
with a raid1 in degraded mode (+lvm) then, when the install is finished,
to plug again the disk sdf and synchronise the partitions with mdadm?
Moreover, I don't understand why the problem occurs only with sde1 and
sdf1 and not with the other disks (sde2, sdf2 as already pointed) : I
have 6 disks, and more partitions, paired in pairs as raid members.
Thank you for lights.
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
FSF
https://www.fsf.org/blogs/community/presenting-shoetool-happy-holidays-fr...
2:48 a.m.
Le 2023-06-06 10:28, François Patte a écrit :
Bonjour,
I am following advices given in answering my previous post "issue...."
and I get f38 installer.
The installer complains that there is a duplicate UUID on some disks :
parts sde1 and sdf1
That's true! Running blkid gives:
/dev/sde1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
UUID_SUB="88a5f939-72d4-b330-95e6-52fa0b826203" LABEL="dipankar:4"
TYPE="linux_raid_member" PARTUUID="c257bd85-01"
^^^^^^^^^^^
/dev/sdf1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
UUID_SUB="99b46805-aa31-1711-21dc-89cb7177d025" LABEL="dipankar:4"
TYPE="linux_raid_member" PARTUUID="c257bd85-01"
^^^^^^^^^^^^
But it is not the only case and it does not complain for the other one:
/dev/sde2: UUID="5240f249-7feb-6832-6682-805f97c4abea"
UUID_SUB="0e21ab45-27a2-f588-48a9-cd46d0dc6237" LABEL="dipankar:5"
TYPE="linux_raid_member" PARTUUID="c257bd85-02"
^^^^^^^^^^^
/dev/sdf2: UUID="5240f249-7feb-6832-6682-805f97c4abea"
UUID_SUB="5838df23-817e-f3cb-19f3-31da8d3e99d0" LABEL="dipankar:5"
TYPE="linux_raid_member" PARTUUID="c257bd85-02"
^^^^^^^^^^^^
What does this mean? And what shall I do?
The installer suggests to unplug these disks (or at list one of these
disks) but, as you can see these disks are members of a raid array
with the swap, /var and a crypted partition (sde1 and sdf1) and /home
(sde2 and sdf2)....
Is it possible to unplug one of the disks (say sdf) and make an
install with a raid1 in degraded mode (+lvm) then, when the install is
finished, to plug again the disk sdf and synchronise the partitions
with mdadm?
Moreover, I don't understand why the problem occurs only with sde1 and
sdf1 and not with the other disks (sde2, sdf2 as already pointed) : I
have 6 disks, and more partitions, paired in pairs as raid members.
Thank you for lights.
No answer... Is this problem so uncommon? Or so obvious?
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
FSF
https://www.fsf.org/blogs/community/presenting-shoetool-happy-holidays-fr...
7:01 a.m.
Am 09.06.2023 um 09:48 schrieb François Patte
<francois.patte(a)mi.parisdescartes.fr>:
> ...
> Is it possible to unplug one of the disks (say sdf) and make an
> install with a raid1 in degraded mode (+lvm) then, when the install is
> finished, to plug again the disk sdf and synchronise the partitions
> with mdadm?
> Moreover, I don't understand why the problem occurs only with sde1 and
> sdf1 and not with the other disks (sde2, sdf2 as already pointed) : I
> have 6 disks, and more partitions, paired in pairs as raid members.
> Thank you for lights.
No answer... Is this problem so uncommon? Or so obvious?
I suppose, the issue is a bit complex and a bit confusing.
The first question is which Fedora edition you want to install. The installation routines
differ a lot and so do the possible solutions.
Additionally, in the previous thread, I recall that the affected disks are to be
reinstalled any way and can be reformatted beforehand. Is that not a solution?
Peter
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
11:19 a.m.
Le 2023-06-09 14:01, Peter Boy a écrit :
> Am 09.06.2023 um 09:48 schrieb François Patte
> <francois.patte(a)mi.parisdescartes.fr>:
>
>> ...
>> Is it possible to unplug one of the disks (say sdf) and make an
>> install with a raid1 in degraded mode (+lvm) then, when the install
>> is
>> finished, to plug again the disk sdf and synchronise the partitions
>> with mdadm?
>> Moreover, I don't understand why the problem occurs only with sde1
>> and
>> sdf1 and not with the other disks (sde2, sdf2 as already pointed) : I
>> have 6 disks, and more partitions, paired in pairs as raid members.
>> Thank you for lights.
>
> No answer... Is this problem so uncommon? Or so obvious?
I suppose, the issue is a bit complex and a bit confusing.
The first question is which Fedora edition you want to install. The
installation routines differ a lot and so do the possible solutions.
I tried f38 netinstall.
Additionally, in the previous thread, I recall that the affected disks
are to be reinstalled any way and can be reformatted beforehand. Is
that not a solution?
Reformat the disks where the system is installed (2 on 6) OK, but why
should I reformat the other disks?
And I don't understand why there are duplicates UUID and why the f38
installer complains about these duplicates UUID on disk /dev/ssde1 and
/dev/sdf1 and not for the duplicates UUID on /dev/sde2 and /dev/sdf2?
--
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)6 7892 5822
http://www.math-info.univ-paris5.fr/~patte
FSF
https://www.fsf.org/blogs/community/presenting-shoetool-happy-holidays-fr...
3:49 p.m.
Am 09.06.2023 um 18:19 schrieb François Patte
<francois.patte(a)mi.parisdescartes.fr>:
Sorry for the delay.
Le 2023-06-09 14:01, Peter Boy a écrit :
>> Am 09.06.2023 um 09:48 schrieb François Patte
<francois.patte(a)mi.parisdescartes.fr>:
>>> ...
>>> Is it possible to unplug one of the disks (say sdf) and make an
>>> install with a raid1 in degraded mode (+lvm) then, when the install is
>>> finished, to plug again the disk sdf and synchronise the partitions
>>> with mdadm?
>>> Moreover, I don't understand why the problem occurs only with sde1 and
>>> sdf1 and not with the other disks (sde2, sdf2 as already pointed) : I
>>> have 6 disks, and more partitions, paired in pairs as raid members.
>>> Thank you for lights.
>> No answer... Is this problem so uncommon? Or so obvious?
> I suppose, the issue is a bit complex and a bit confusing.
> The first question is which Fedora edition you want to install. The
> installation routines differ a lot and so do the possible solutions.
I tried f38 netinstall.
Fedora Server Edition is the only Edition with a net install media, as far as I know.
Nevertheless, do you want to install (and operate) a Fedora Server or just use the medium
to install another variant (by selecting a different target in the installation source
menu). These alternatives require different followup steps.
> Additionally, in the previous thread, I recall that the affected
disks
> are to be reinstalled any way and can be reformatted beforehand. Is
> that not a solution?
Reformat the disks where the system is installed (2 on 6) OK, but why should I reformat
the other disks?
No, just reformat the disk(s) which cause issues. And probably only reformat the
partition(s) that are affected.
And I don't understand why there are duplicates UUID and why the
f38 installer complains about these duplicates UUID on disk /dev/ssde1 and /dev/sdf1 and
not for the duplicates UUID on /dev/sde2 and /dev/sdf2?
It’s hard to identify the cause of the problem. But the problem is not necessarily the
identical UUIDs in that specific field, but probably a value anywhere else that determine
the purpose of the disk resp. the partition, in your case usage of the partition as a raid
member and not as an independent partition (which would require unique UUIDs).
You can try to disconnect one of the drives of the failing raid and then reboot. If it
works, fine. Otherwise try the other disks. If the system boots and works without issues
(besides a degraded raid) with a one-disk-raid, then you may delete all partitions of the
disconnected disk, probably even delete the partition table (e.g. by using dd if:/dev/zero
of=/dev/<disconneted disk>). Then integrate the empty disk into the raid again and
initiate a resynchronization. It may be a bit tricky.
If you can’t manage to resync the raid, you have at least still a bootable system and a
working base for next steps.
The alternative is to reformat either the disk or just one or two partitions (that depends
on the details of your disk layout) and then start a complete new installation of the
system (and preserving user data if your existing partitioning scheme allows for that).
The details here depend on what Edition you really want to install.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
11:38 a.m.
On Fri, 09 Jun 2023 09:48:25 +0200
François Patte <francois.patte(a)mi.parisdescartes.fr> wrote:
No answer... Is this problem so uncommon? Or so obvious?
I haven't seen it even mentioned before and not obvious at all to me.
Perhaps there is an expert who would immediately understand what
happened, and how to either fix or workaround it. But like you, I don't
understand how the system could assign the same UUID to two disks. Is
it possible that the way you set up raid was different? It is as if
they were assigned the same UUID *because* they were in a raid. Are
they using hardware raid, or an unusual software raid? What happens if
you try to change the UUID on one of the disks? Don't actually do it
because you might lose data, but does it give an error or warning?
Anyway, no answers, or even insight, here.
12:02 p.m.
On Fri, Jun 9, 2023, at 9:38 AM, stan via users wrote:
On Fri, 09 Jun 2023 09:48:25 +0200
François Patte <francois.patte(a)mi.parisdescartes.fr> wrote:
> No answer... Is this problem so uncommon? Or so obvious?
[snip]
It is as if
they were assigned the same UUID *because* they were in a raid. [snip]
That is normal for linux raid. Here is a sample of an MD raid1:
blkid | grep -E "sda1|sdb1|md1"
/dev/sdb1: UUID="deb9b913-0a73-90d8-6b37-12e5156fce03"
UUID_SUB="50b1ecf9-a7bd-6ba5-131e-4bbde91735c8"
LABEL="wombat.wombatz.com:boot" TYPE="linux_raid_member"
PARTUUID="28f4447c-01"
/dev/sda1: UUID="deb9b913-0a73-90d8-6b37-12e5156fce03"
UUID_SUB="8efb2a67-f08a-4ba9-186f-11f7afec25c7"
LABEL="wombat.wombatz.com:boot" TYPE="linux_raid_member"
PARTUUID="87e58b90-01"
/dev/md1: UUID="72f36fca-b84e-45f4-8621-d85b14a32ff3"
BLOCK_SIZE="4096" TYPE="ext4"
Note that the "UUID" is the same, but they can be differentiated by the
"UUID_SUB".
8:36 a.m.
On Fri, 09 Jun 2023 10:02:19 -0700
"Doug Herr" <fedoraproject.org(a)wombatz.com> wrote:
On Fri, Jun 9, 2023, at 9:38 AM, stan via users wrote:
> On Fri, 09 Jun 2023 09:48:25 +0200
> François Patte <francois.patte(a)mi.parisdescartes.fr> wrote:
>
>> No answer... Is this problem so uncommon? Or so obvious?
> [snip]
> It is as if
> they were assigned the same UUID *because* they were in a raid.
> [snip]
That is normal for linux raid. Here is a sample of an MD raid1:
blkid | grep -E "sda1|sdb1|md1"
/dev/sdb1: UUID="deb9b913-0a73-90d8-6b37-12e5156fce03"
UUID_SUB="50b1ecf9-a7bd-6ba5-131e-4bbde91735c8"
LABEL="wombat.wombatz.com:boot" TYPE="linux_raid_member"
PARTUUID="28f4447c-01"
/dev/sda1: UUID="deb9b913-0a73-90d8-6b37-12e5156fce03"
UUID_SUB="8efb2a67-f08a-4ba9-186f-11f7afec25c7"
LABEL="wombat.wombatz.com:boot" TYPE="linux_raid_member"
PARTUUID="87e58b90-01"
/dev/md1: UUID="72f36fca-b84e-45f4-8621-d85b14a32ff3"
BLOCK_SIZE="4096" TYPE="ext4"
Note that the "UUID" is the same, but they can be differentiated by
the "UUID_SUB".
Thanks, I learned something.
2:56 p.m.
Am 09.06.2023 um 18:38 schrieb stan via users
<users(a)lists.fedoraproject.org>:
On Fri, 09 Jun 2023 09:48:25 +0200
François Patte <francois.patte(a)mi.parisdescartes.fr> wrote:
> No answer... Is this problem so uncommon? Or so obvious?
I haven't seen it even mentioned before and not obvious at all to me.
Perhaps there is an expert who would immediately understand what
happened, and how to either fix or workaround it. But like you, I don't
understand how the system could assign the same UUID to two disks.
I probably don’t count as an expert. But software raid introduces a property „raid-member“
(not literally but something like that). Each raid gets a UUID and all members of a
specific raid get the same UUID that identifies them as belonging together. I guess, the
problem is not that the disks have the same UUID but a missing value of a property
elsewhere indicating how to interpret that property.
I guess it is quite pointless to find the mistake. Even if you would identify it, there
might be no tool to fix it. And binary-editing a disk sector may be quite a challenge.
Is
it possible that the way you set up raid was different? It is as if
they were assigned the same UUID *because* they were in a raid. Are
they using hardware raid, or an unusual software raid? What happens if
you try to change the UUID on one of the disks? Don't actually do it
because you might lose data, but does it give an error or warning?
If I remember the previous thread correctly, there was some disk cloning involved. Maybe
that part of the issue.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST /UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
8:38 a.m.
On Fri, 9 Jun 2023 21:56:03 +0200
Peter Boy <pboy(a)uni-bremen.de> wrote:
I probably don’t count as an expert. But software raid introduces a
property „raid-member“ (not literally but something like that). Each
raid gets a UUID and all members of a specific raid get the same UUID
that identifies them as belonging together. I guess, the problem is
not that the disks have the same UUID but a missing value of a
property elsewhere indicating how to interpret that property.
I guess it is quite pointless to find the mistake. Even if you would
identify it, there might be no tool to fix it. And binary-editing a
disk sector may be quite a challenge.
Thanks to you also for correcting my understanding.
6:35 p.m.
On 6/6/23 01:28, François Patte wrote:
Bonjour,
I am following advices given in answering my previous post "issue...."
and I get f38 installer.
The installer complains that there is a duplicate UUID on some disks :
parts sde1 and sdf1
That's true! Running blkid gives:
/dev/sde1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
UUID_SUB="88a5f939-72d4-b330-95e6-52fa0b826203" LABEL="dipankar:4"
TYPE="linux_raid_member" PARTUUID="c257bd85-01"
^^^^^^^^^^^
/dev/sdf1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
UUID_SUB="99b46805-aa31-1711-21dc-89cb7177d025" LABEL="dipankar:4"
TYPE="linux_raid_member" PARTUUID="c257bd85-01"
^^^^^^^^^^^^
It's probably the PARTUUID that it's complaining about. That should not
be the same. How did you even get it in that condition?
But it is not the only case and it does not complain for the other
one:
/dev/sde2: UUID="5240f249-7feb-6832-6682-805f97c4abea"
UUID_SUB="0e21ab45-27a2-f588-48a9-cd46d0dc6237" LABEL="dipankar:5"
TYPE="linux_raid_member" PARTUUID="c257bd85-02"
^^^^^^^^^^^
/dev/sdf2: UUID="5240f249-7feb-6832-6682-805f97c4abea"
UUID_SUB="5838df23-817e-f3cb-19f3-31da8d3e99d0" LABEL="dipankar:5"
TYPE="linux_raid_member" PARTUUID="c257bd85-02"
^^^^^^^^^^^^
Moreover, I don't understand why the problem occurs only with sde1 and
sdf1 and not with the other disks (sde2, sdf2 as already pointed) : I
have 6 disks, and more partitions, paired in pairs as raid members.
My guess is that it's stopping at the first error and if you fixed the
first one, it would complain about the next one.
But I figured out how you can fix it. Those disks must be using DOS
partition format. Use fdisk on one of the disks, go to the eXpert menu
and change the disk identifier to a different value. (It's currently
0xc257bd85.)
6:37 p.m.
On 6/10/23 16:35, Samuel Sieb wrote:
On 6/6/23 01:28, François Patte wrote:
> Bonjour,
>
> I am following advices given in answering my previous post "issue...."
> and I get f38 installer.
>
> The installer complains that there is a duplicate UUID on some disks :
> parts sde1 and sdf1
>
> That's true! Running blkid gives:
>
> /dev/sde1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
> UUID_SUB="88a5f939-72d4-b330-95e6-52fa0b826203"
LABEL="dipankar:4"
> TYPE="linux_raid_member" PARTUUID="c257bd85-01"
> ^^^^^^^^^^^
> /dev/sdf1: UUID="4a28174a-f38b-4938-233f-85f76ce585a8"
> UUID_SUB="99b46805-aa31-1711-21dc-89cb7177d025"
LABEL="dipankar:4"
> TYPE="linux_raid_member" PARTUUID="c257bd85-01"
> ^^^^^^^^^^^^
It's probably the PARTUUID that it's complaining about. That should not
be the same. How did you even get it in that condition?
Someone mentioned disk cloning. That would cause this problem if you
copied the entire disk from one to another without changing the disk
identifier.
328
days inactive
332
days old
11 comments
5 participants
participants (5)
-
Doug Herr -
François Patte -
Peter Boy -
Samuel Sieb -
stan