On 18/11/2020 16.52, Stakanov wrote:

Situation: I have a 2 GB disc mounted as /var/lib/libvirt/images. I have images of installation on it. In order to have higher redundancy in case of HDD failure (had one recently on root but on root there is not so much "unique"). So I took a second one, same size to set up a RAID1

Normally you would need three discs (set up the raid and then transfer from a backup. However I did this one in the past with success (only I forgot how and the opensuse 15.2 killed all my maildata so I cannot find it in the archives (BTW opensuse archives seem to be down too).

So I want to create a RAID called md/1 and use it as RAID setting it up with one "missing". dev/sdd is the one with the data. /dev/sdf is the virgin new.

I began with: dd if=/dev/sdd of=/dev/sdf count=1 fdisk /dev/sdf Command (m for help): t Partition number (1-3): 1 Hex code (type L to list codes): fd Changed system type of partition 1 to fd (Linux raid autodetect)

I'm a bit lost here. /dev/sdd holds the current store in a "normal" disk, non raid, right? What are you doing with that 'dd', cloning the MBR to sdf? I hope the disk is type MBR, not GPT. If it is GPT it will not work. Then you are also cloning the disk identifier, you get two disks with the same ID. I think it would be better not to do the cloning and create the partition from scratch on the second disk. And I typically use YaST for this operation.

so far so good. And it works up to here. And I initialize the RAID:

mdadm -C /dev/md/1 -l 1 -n 2 missing /dev/sdf1

And so far so good, all is smooth.

Now I wish to give it a file system (in my case ext4) and there...the trouble begin. I do not remember obviously how to do this right. I tried: mkfs.ext4 /dev/md/1

Which he does but complains: mke2fs 1.45.6 (20-Mar-2020) /dev/md/1 alignment is offset by 3584 bytes.

This may be an effect of cloning the MBR to a disk with different sector size. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

In data giovedì 19 novembre 2020 12:48:28 CET, David T-G ha scritto:

Stakanov --

...and then Stakanov said... % % Situation: % I have a 2 GB disc mounted as /var/lib/libvirt/images. ... % So I took a second one, same size to set up a RAID1 % ... % % So I want to create a RAID called md/1 and use it as RAID setting it up with % one "missing". dev/sdd is the one with the data. /dev/sdf is the virgin new. % % I began with: % dd if=/dev/sdd of=/dev/sdf count=1

Why are you bothering with this? First, you have no particular reason to duplicate the partition table. Second, you should be using something like sgdisk --backup or sfdisk -d to dump the table if that's what you really wanted to do (which, again, I think it isn't here).

Personally, I like to make a partition of almost the entire disk for my RAIDed content and then leave a tiny slice at the end where I write data about the disk and RAID set. I even go so far as to format each disk's tiny slice with different filesystems, but that's just me :-) Whether you use a partition or the whole device, though, it's simple enough just to set that up manually with fdisk or gpt rather than duplicating something that wasn't meant to hold RAID content in the first place.

... % % Now I wish to give it a file system (in my case ext4) and there...the trouble % begin. I do not remember obviously how to do this right. I tried: % mkfs.ext4 /dev/md/1 [snip]

Most folks prefer to create a valid partition table on the new device and then put a filesystem on that. Try something like

fdisk /dev/md/1

to set up your partitions and then

mkfs.ext4 /dev/md/1p1

to create a filesystem on the new partition. [Actual results may vary, of course; do not just mouse-n-paste :-]

Ok, I did it and it worked. So how to take a single disk and transform it with mdadm into a Raid1 without having to restore it from backed up data (which should be there BTW, in case things go South on you). I followed mainly: https://asergo.com/knowledge-base/bare-metal-servers/raid/ mdadm.html sudo parted --list gives you an overlook over you partitions shouldn't you know. sudo lsblk gives you the overlook over all disc name and mount points. With this info at hand, and in my case not a root file system or a bootable partition: $ sudo sgdisk /dev/sda --replicate /dev/sdb The operation has completed successfully. $ sudo sgdisk --randomize-guids /dev/sdb The operation has completed successfully. The first to clone the partition the second not to have the same UUID. (sdb or sda are here arbitrary, in my example I worked with sdd and sdf so it is really just to be adapted to the usecase) $ sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb2 creates a RAID device (in my case it was md1 because I had already a RAID for /home in place). And this RAID device is purportedly "defective" that is missing of one disc. (disc which is still full of the data we wish to transfer and save - yes, of course you have a valid backup - if you have the money and the space). This will give you the following output: mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. I wanted an EXT4 filesystem as the "original disc" so: $ sudo mkfs.ext4 /dev/md0 mke2fs 1.44.1 (24-Mar-2018) Creating filesystem with 73208576 4k blocks and 18309120 inodes Filesystem UUID: ff25d882-f65b-4e0e-ad49-f8d9756a0f89 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done Not that this time I did not run into the alignment error. Making a mount point and mounting the "newraid" with a temporary name. $ sudo mkdir /mnt/new-raid $ sudo mount /dev/md0 /mnt/new-raid Now the author of the guide uses rsync but for some reasons I did ran into "broken pipe". $ sudo rsync -auHxv --exclude={"/proc/*","/sys/*","/mnt/*"} /* /mnt/new-raid/ I think I did some syntax error, however it was also quite slow so I preferred sudo cp -ax /directory mounted old disc /new-raid waited to be copied, which in my case with OS for KVM took some time nevertheless. Once done, I mounted the new RAID under the original name and tried it out with KVM. Considered all was as expected, then I decided to complete the action and to erase the old data on the disc and then copied the partition table over from the new Raid: $ sudo wipefs --all /dev/sda $ sudo sgdisk /dev/sdb --replicate /dev/sda The operation has completed successfully. Finally I added it and it began to sync: $ sudo mdadm /dev/md127 --add /dev/sda2 mdadm: added /dev/sda2 Final step: proof the status of the RAID you have again with sudo cat /proc/mdadm All Raid should be healthy, UU and all devices should be in use. With a root file system this is more complicated as you can read in the guide but for a normal disc it was quite straightforward (as long as you take note of the partition numbers and names).