It's strange but parted output for this disk (/dev/sdf) show me that it's GPT:
(parted) print
Model: ATA HGST HUS726020AL (scsi)
Disk /dev/sdf: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Number Start End Size Type File system Flags
2 1049kB 1075MB 1074MB ceph journal
1 1075MB 2000GB 1999GB xfs ceph data
ср, 20 февр. 2019 г. в 17:11, Alfredo Deza <adeza@xxxxxxxxxx>:
On Wed, Feb 20, 2019 at 8:40 AM Анатолий Фуников
<anatoly.funikov@xxxxxxxxxxx> wrote:
>
> Thanks for the reply.
> blkid -s PARTUUID -o value /dev/sdf1 shows me nothing, but blkid /dev/sdf1 shows me this: /dev/sdf1: UUID="b03810e4-dcc1-46c2-bc31-a1e558904750" TYPE="xfs"
I think this is what happens with a non-gpt partition. GPT labels will
use a PARTUUID to identify the partition, and I just confirmed that
ceph-volume will enforce looking for PARTUUID if the JSON
identified a partition (vs. an LV).
>From what I briefly researched it is not possible to add a GPT label
on a non-gpt partition without losing data.
My suggestion (if you confirm it is not possible to add the GPT label)
is to start the migration towards the new way of creating OSDs
>
> ср, 20 февр. 2019 г. в 16:27, Alfredo Deza <adeza@xxxxxxxxxx>:
>>
>> On Wed, Feb 20, 2019 at 8:16 AM Анатолий Фуников
>> <anatoly.funikov@xxxxxxxxxxx> wrote:
>> >
>> > Hello. I need to raise the OSD on the node after reinstalling the OS, some OSD were made a long time ago, not even a ceph-disk, but a set of scripts.
>> > There was an idea to get their configuration in json via ceph-volume simple scan, and then on a fresh system I can make a ceph-volume simple activate --file /etc/ceph/osd/31-46eacafe-22b6-4433-8e5c-e595612d8579.json
>> > I do ceph-volume simple scan /var/lib/ceph/osd/ceph-31/, and got this json: https://pastebin.com/uJ8WVZyV
>> > It seems everything is not bad, but in the data section I see a direct link to the device /dev/sdf1, and the uuid field is empty. At the same time, in the /dev/disk/by-partuuid directory I can find and substitute this UUID in this json, and delete the direct link to the device in this json.
>> > The question is: how correct is it and can I raise this OSD on a freshly installed OS with this fixed json?
>>
>> It worries me that it is unable to find a uuid for the device. This is
>> important because paths like /dev/sdf1 are ephemeral and can change
>> after a reboot. The uuid is found by running the following:
>>
>> blkid -s PARTUUID -o value /dev/sdf1
>>
>> If that is not returning anything, then ceph-volume will probably not
>> be able to ensure this device is brought up correctly. You can correct
>> or add to anything in the JSON after a scan and rely on that, but then
>> again
>> without a partuuid I don't think this will work nicely
>>
>> > _______________________________________________
>> > ceph-users mailing list
>> > ceph-users@xxxxxxxxxxxxxx
>> > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
