this is on a fresh FC17 install - i've reinstalled and tried it twice. same result.
thanks,
-ed
[root@ferb2 raider]# tail raider.log
Copying data from /dev/vg_ferb2/lv_home to /dev/vg_ferb2__raider/lv_home... [#110:partitioncopy]
Create Logical Volume named: vg_ferb2__raider-lv_root [#34:partitioncopy]
Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_root [#54:partitioncopy]
Formating... [#55:partitioncopy]
Copying data from /dev/vg_ferb2/lv_root to /dev/vg_ferb2__raider/lv_root... [#110:partitioncopy]
Create Logical Volume named: vg_ferb2__raider-lv_swap [#34:partitioncopy]
Building file system (format) mkswap -f /dev/vg_ferb2__raider/lv_swap [#54:partitioncopy]
Formating... [#55:partitioncopy]
/dev/vg_ferb2__raider/lv_swap: No such file or directory
Unable to format /dev/vg_ferb2__raider/lv_swap! [#73:partitioncopy]
[root@ferb2 raider]# tail raider_debug_OUTPUT_R1_.log
:: Create Logical Volume named: vg_ferb2__raider-lv_root
Logical volume "lv_root" created
:: Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_root
:: Formating... ==> Done.
:: Copying data from /dev/vg_ferb2/lv_root to /dev/vg_ferb2__raider/lv_root...
:: [ 100% ][=========================>][ Time: 13s ]
:: Create Logical Volume named: vg_ferb2__raider-lv_swap
:: Building file system (format) mkswap -f /dev/vg_ferb2__raider/lv_swap
:: Formating... => Done.
:: FATAL ERROR: Unable to format /dev/vg_ferb2__raider/lv_swap!
[root@ferb2 ~]# raider -R1
:: raider version 0.13.2 started
:: Option: Single disk to RAID 1 (MIRRORING)
:: Distro name and version: Fedora 17
:: Distro edition: Fedora release 17 (Beefy Miracle)
:: Test Status (in lab): Tested successfully
:: Advice: You may use raider on it!
:: /dev/sda partition table type: MBR/msdos
:: Bootloader found in the boot sector: GRUB
:: GRUB 2 version: 2.00
:: Initramfs generator: dracut
:: Initramfs generator command: "dracut --mdadmconf --force --fstab /boot/initramfs-3.3.4-5.fc17.x86_64.img"
:: You are not running in "single mode"
:: BuildRaid phase will start now!
:: There are 2.01GB of data to be copied to the new raid system
:: BuildRaid phase will take a long time, maybe several minutes to one hour(?).
:: Do you want to continue without changing to "single mode"? (y/[n])y
:: BuildRaid phase started...
:: Working on /dev/sdb ...
:: Copying partitions from disk /dev/sda to /dev/sdb
:: Configure partitions
:: Creating raid 1 array /dev/md0 with devices /dev/sdb1
:: Raid1 array /dev/md0 (metadata=1.2) started...
:: Configure partitions
:: Creating raid 1 array /dev/md1 with devices /dev/sdb2
:: Raid1 array /dev/md1 (metadata=1.2) started...
:: Building file system (format): mkfs.ext4 -q /dev/md0
:: Formating... => Done.
:: Copying data from /boot to /dev/md0...
:: [ 100% ][=========================>][ Time: 01s ]
:: Create new LVM2 Volume Group named: vg_ferb2__raider in /dev/md1
Physical volume "/dev/md1" successfully created
Volume group "vg_ferb2__raider" successfully created
0 logical volume(s) in volume group "vg_ferb2__raider" now active
:: Create Logical Volume named: vg_ferb2__raider-lv_home
Logical volume "lv_home" created
:: Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_home
:: Formating... ==> Done.
:: Copying data from /dev/vg_ferb2/lv_home to /dev/vg_ferb2__raider/lv_home...
:: [ 100% ][=========================>][ Time: 01s ]
:: Create Logical Volume named: vg_ferb2__raider-lv_root
Logical volume "lv_root" created
:: Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_root
:: Formating... ==> Done.
:: Copying data from /dev/vg_ferb2/lv_root to /dev/vg_ferb2__raider/lv_root...
:: [ 100% ][=========================>][ Time: 13s ]
:: Create Logical Volume named: vg_ferb2__raider-lv_swap
:: Building file system (format) mkswap -f /dev/vg_ferb2__raider/lv_swap
:: Formating... => Done.
:: FATAL ERROR: Unable to format /dev/vg_ferb2__raider/lv_swap!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you please run the command "lograider"? This will create a file called "lograider.tgz" that will contain all logfiles needed to troubleshoot the issue. You can upload it to the forum and I will help you later.
Sorry for the late response but I have a serious illness at this time and I have difficulty getting an answer as quickly as I would like.
But I'll do my best. Thank's.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the late response.
I read the logs and tried to reproduce the same environment, installing a Fedora-17 with the same partitions and LVM partitions with the same names you used. Fstab was the same.
When I ran raider everything worked as expected. So, this issue does not seem to be related with raider.
I suspect that the second disk has some hardware problem, because it is not able to format that disk section. So you can try to use a disk utility to test it, or use another disk (if you have one) to test it as the second disk, only to be sure this is a hardware issue (you can use a larger one without problems).
Hope this can help you. I'll wait for your feedback.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
very strange. I just tried it on the same machine with two different drives and got the same result. I'll try it on a different machine and let you know how it goes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
tried it on another computer and it failed in exactly the same spot.
what is the exact command it is trying to execute when it fails here? if I can try running it by hand I can possibly get more info about why it is failing.
This is really very strange! Raider is only a script, so everything can be done "by hand".
The command which is failing is:
mkswap -f /dev/vg_ferb2__raider/lv_swap
(line 55 in /usr/lib/raider/partitioncopy)
But... Wait! There is something in the log /var/log/raider_debug_R1_.log that I didn't detect earlier. Read line 9596 to 9599:
+ echo 'Create Logical Volume named: vg_ferb2__raider-lv_swap [#34:partitioncopy]'
+ lvcreate -L47815065600B -nlv_swap vg_ferb2__raider
Volume group "vg_ferb2__raider" has insufficient free space (11388 extents): 11400 required.
What can I think about this?
I don't know how do you installed Fedora 17. Did you created the LVM partitions by hand?, or did you let Fedora create automatically all the partitions with their names and size?
Anyway, it seems the swap partition Volume Group was not created originally with the size expected, so it can not be created in the new disk because there is no free space (it needs 2 more bytes)
As this never happened before with raider I will see this with more attention.
You can try do this commands by hand and I will try to get a solution for you, tricking the values in the script (if you have the patitence to wait for it).
I think later in the night I will have a particular solution for you.
Thank's
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that the free space detected by LVM2 tools in Bytes are sometimes not very accurate. The trick seems to use Free Physical Extents instead of the size in Bytes when the error is detected. I will try to integrate this in the new version, but as I said to you before, I don't know when I will be able to work again on this.
Sorry about it
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm back home after some weeks in the hospital and I'm feeling better now at home.
I tried to get a solution for your problem but I don't know if it's too late and you already have the possibility to test it now.
If you want to try it, edit this file /usr/lib/raider/partitioncopy.
Then you will see line 35 starting with lvcreate, and line 36 starting with demapp.
Between those lines add 4 code lines:
~~~~~~~~
lvcreate -L${Size} -n${LogicalVolumeName} ${VolumeGroup}${RAID_EXT}
if [ $? -eq 5 ]; then
freePE=$(pvdisplay -c "/dev/md${md}" | awk -F: '{print $10}')
lvcreate -l${freePE} -n${LogicalVolumeName} ${VolumeGroup}${RAID_EXT}
fi
demapp=$(dmsetup info -c --noheadings "/dev/${VolumeGroup}/${LogicalVolumeName}" | awk -F: '{print "/dev/mapper/"$1}')
~~~~~~~~~
I'm almost sure this will solve your problem.
If it is possible for you to test it, I will appreciate it a lot, because this will be added in the next version already tested.
Thank's.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Only with the above patch is installation on Linux Mint 17.3 successful.
After using Raider to convert my single disk Linux Mint 17.3 system to two-disk RAID1 its boot now shows a new boot menu. Unsure which to select for the RAID1 config I selected 'Linux Mint 17.3 Cinnamon 64-bit'. The next screen showed a write error.
Several problems:
which is the right one to select?
what is the write error about?
how to automate so that the boot does not pause
Thanks in advance to anyone that can help me with this.
GNU GRUB version 2.02~beta2-9ubuntu1.3
Linux Mint 17.3 Cinnamon 64-bit <---- was selected
Advanced options for Linux Mint 17.3 Cinnamon 64-bit
Memory test (mmtest86+)
Memory test (mmtest86+, serial console 115200)
Linux Mint 17.3 Rosa (17.3) (on /dev/mapper/mint--vg-root)
Advanced options for Linux Mint 17.3 Rosa (17.3) (on /dev/mapper/mint--vg-root)
[next screen:]
error: diskfilter writes are not supported.
Press any key to continue...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
any ideas why this is failing here?
this is on a fresh FC17 install - i've reinstalled and tried it twice. same result.
thanks,
-ed
[root@ferb2 raider]# tail raider.log
Copying data from /dev/vg_ferb2/lv_home to /dev/vg_ferb2__raider/lv_home... [#110:partitioncopy]
Create Logical Volume named: vg_ferb2__raider-lv_root [#34:partitioncopy]
Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_root [#54:partitioncopy]
Formating... [#55:partitioncopy]
Copying data from /dev/vg_ferb2/lv_root to /dev/vg_ferb2__raider/lv_root... [#110:partitioncopy]
Create Logical Volume named: vg_ferb2__raider-lv_swap [#34:partitioncopy]
Building file system (format) mkswap -f /dev/vg_ferb2__raider/lv_swap [#54:partitioncopy]
Formating... [#55:partitioncopy]
/dev/vg_ferb2__raider/lv_swap: No such file or directory
Unable to format /dev/vg_ferb2__raider/lv_swap! [#73:partitioncopy]
[root@ferb2 raider]# tail raider_debug_OUTPUT_R1_.log
:: Create Logical Volume named: vg_ferb2__raider-lv_root
Logical volume "lv_root" created
:: Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_root
:: Formating... ==> Done.
:: Copying data from /dev/vg_ferb2/lv_root to /dev/vg_ferb2__raider/lv_root...
:: [ 100% ][=========================>][ Time: 13s ]
:: Create Logical Volume named: vg_ferb2__raider-lv_swap
:: Building file system (format) mkswap -f /dev/vg_ferb2__raider/lv_swap
:: Formating... => Done.
:: FATAL ERROR: Unable to format /dev/vg_ferb2__raider/lv_swap!
[root@ferb2 ~]# raider -R1
:: raider version 0.13.2 started
:: Option: Single disk to RAID 1 (MIRRORING)
:: Distro name and version: Fedora 17
:: Distro edition: Fedora release 17 (Beefy Miracle)
:: Test Status (in lab): Tested successfully
:: Advice: You may use raider on it!
:: Disks selected (2):
:: /dev/sda: OCZ-AGILITY3 Model: OCZ-AGILITY3 Serial: OCZ-3U90Q0O205IP5G3W (120G)
:: /dev/sdb: OCZ-AGILITY3 Model: OCZ-AGILITY3 Serial: OCZ-9N4H1GVRE0363V8M (120G)
:: /dev/sda partition table type: MBR/msdos
:: Bootloader found in the boot sector: GRUB
:: GRUB 2 version: 2.00
:: Initramfs generator: dracut
:: Initramfs generator command: "dracut --mdadmconf --force --fstab /boot/initramfs-3.3.4-5.fc17.x86_64.img"
:: You are not running in "single mode"
:: BuildRaid phase will start now!
:: There are 2.01GB of data to be copied to the new raid system
:: BuildRaid phase will take a long time, maybe several minutes to one hour(?).
:: Do you want to continue without changing to "single mode"? (y/[n])y
:: BuildRaid phase started...
:: Working on /dev/sdb ...
:: Copying partitions from disk /dev/sda to /dev/sdb
:: Configure partitions
:: Creating raid 1 array /dev/md0 with devices /dev/sdb1
:: Raid1 array /dev/md0 (metadata=1.2) started...
:: Configure partitions
:: Creating raid 1 array /dev/md1 with devices /dev/sdb2
:: Raid1 array /dev/md1 (metadata=1.2) started...
:: Building file system (format): mkfs.ext4 -q /dev/md0
:: Formating... => Done.
:: Copying data from /boot to /dev/md0...
:: [ 100% ][=========================>][ Time: 01s ]
:: Create new LVM2 Volume Group named: vg_ferb2__raider in /dev/md1
Physical volume "/dev/md1" successfully created
Volume group "vg_ferb2__raider" successfully created
0 logical volume(s) in volume group "vg_ferb2__raider" now active
:: Create Logical Volume named: vg_ferb2__raider-lv_home
Logical volume "lv_home" created
:: Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_home
:: Formating... ==> Done.
:: Copying data from /dev/vg_ferb2/lv_home to /dev/vg_ferb2__raider/lv_home...
:: [ 100% ][=========================>][ Time: 01s ]
:: Create Logical Volume named: vg_ferb2__raider-lv_root
Logical volume "lv_root" created
:: Building file system (format) mkfs.ext4 -q /dev/vg_ferb2__raider/lv_root
:: Formating... ==> Done.
:: Copying data from /dev/vg_ferb2/lv_root to /dev/vg_ferb2__raider/lv_root...
:: [ 100% ][=========================>][ Time: 13s ]
:: Create Logical Volume named: vg_ferb2__raider-lv_swap
:: Building file system (format) mkswap -f /dev/vg_ferb2__raider/lv_swap
:: Formating... => Done.
:: FATAL ERROR: Unable to format /dev/vg_ferb2__raider/lv_swap!
Can you please run the command "lograider"? This will create a file called "lograider.tgz" that will contain all logfiles needed to troubleshoot the issue. You can upload it to the forum and I will help you later.
Sorry for the late response but I have a serious illness at this time and I have difficulty getting an answer as quickly as I would like.
But I'll do my best. Thank's.
here it is. TIA for the help. I can't tell you how much help raider is going to be to me going forward(assuming we can figure out this swap error)
Last edit: devros69 2012-08-23
Sorry for the late response.
I read the logs and tried to reproduce the same environment, installing a Fedora-17 with the same partitions and LVM partitions with the same names you used. Fstab was the same.
When I ran raider everything worked as expected. So, this issue does not seem to be related with raider.
I suspect that the second disk has some hardware problem, because it is not able to format that disk section. So you can try to use a disk utility to test it, or use another disk (if you have one) to test it as the second disk, only to be sure this is a hardware issue (you can use a larger one without problems).
Hope this can help you. I'll wait for your feedback.
very strange. I just tried it on the same machine with two different drives and got the same result. I'll try it on a different machine and let you know how it goes.
tried it on another computer and it failed in exactly the same spot.
what is the exact command it is trying to execute when it fails here? if I can try running it by hand I can possibly get more info about why it is failing.
thanks,
ed
This is really very strange! Raider is only a script, so everything can be done "by hand".
The command which is failing is:
mkswap -f /dev/vg_ferb2__raider/lv_swap
(line 55 in /usr/lib/raider/partitioncopy)
But... Wait! There is something in the log /var/log/raider_debug_R1_.log that I didn't detect earlier. Read line 9596 to 9599:
What can I think about this?
I don't know how do you installed Fedora 17. Did you created the LVM partitions by hand?, or did you let Fedora create automatically all the partitions with their names and size?
Anyway, it seems the swap partition Volume Group was not created originally with the size expected, so it can not be created in the new disk because there is no free space (it needs 2 more bytes)
As this never happened before with raider I will see this with more attention.
You can try do this commands by hand and I will try to get a solution for you, tricking the values in the script (if you have the patitence to wait for it).
I think later in the night I will have a particular solution for you.
Thank's
this was just a normal install with the installer doing all the partitioning. First time on a 120gig SSD and the second time on a 750gig seagate
any updates? I'm trying to get this server in production soon.
thanks,
-ed
Sorry about the delay, but your problem is not forgotten.
The problem is my illness that worsened last week and I probably will be tomorrow in the hospital, so I will not be able to do any update sooner (hope I'm wrong).
Anyway, looking in the net this issue was related several times.
I will only give you some links for you to understand:
http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/nofreeext.html
http://wiki.tldp.org/LVM-HOWTO#LVM_2_FAQ (in 4.1.11)
https://bugzilla.redhat.com/show_bug.cgi?id=682276
It seems that the free space detected by LVM2 tools in Bytes are sometimes not very accurate. The trick seems to use Free Physical Extents instead of the size in Bytes when the error is detected. I will try to integrate this in the new version, but as I said to you before, I don't know when I will be able to work again on this.
Sorry about it
ok, hope you feeling better. thanks again for the help.
I might try to modify the script.
-ed
I'm back home after some weeks in the hospital and I'm feeling better now at home.
I tried to get a solution for your problem but I don't know if it's too late and you already have the possibility to test it now.
If you want to try it, edit this file /usr/lib/raider/partitioncopy.
Then you will see line 35 starting with lvcreate, and line 36 starting with demapp.
Between those lines add 4 code lines:
~~~~~~~~
lvcreate -L${Size} -n${LogicalVolumeName} ${VolumeGroup}${RAID_EXT}
if [ $? -eq 5 ]; then
freePE=$(pvdisplay -c "/dev/md${md}" | awk -F: '{print $10}')
lvcreate -l${freePE} -n${LogicalVolumeName} ${VolumeGroup}${RAID_EXT}
fi
demapp=$(dmsetup info -c --noheadings "/dev/${VolumeGroup}/${LogicalVolumeName}" | awk -F: '{print "/dev/mapper/"$1}')
~~~~~~~~~
I'm almost sure this will solve your problem.
If it is possible for you to test it, I will appreciate it a lot, because this will be added in the next version already tested.
Thank's.
I also confirm that raider works on a fresh Fedora Core 18 installation with the above patch (but not without it).
Thanks, great tool.
Only with the above patch is installation on Linux Mint 17.3 successful.
After using Raider to convert my single disk Linux Mint 17.3 system to two-disk RAID1 its boot now shows a new boot menu. Unsure which to select for the RAID1 config I selected 'Linux Mint 17.3 Cinnamon 64-bit'. The next screen showed a write error.
Several problems:
Thanks in advance to anyone that can help me with this.
GNU GRUB version 2.02~beta2-9ubuntu1.3
Linux Mint 17.3 Cinnamon 64-bit <---- was selected
Advanced options for Linux Mint 17.3 Cinnamon 64-bit
Memory test (mmtest86+)
Memory test (mmtest86+, serial console 115200)
Linux Mint 17.3 Rosa (17.3) (on /dev/mapper/mint--vg-root)
Advanced options for Linux Mint 17.3 Rosa (17.3) (on /dev/mapper/mint--vg-root)
[next screen:]
error: diskfilter writes are not supported.
Press any key to continue...
I only saw this reply just now. I'm about to leave on vacation for a week and a half, but will try this as soon as I can after I get back.
I can confim that it works with that code change. Is there a new release version coming out anytime soon?
Hi there. I can confirm this is also happening with a fresh installation of Scientific Linux 6.4 using LVM.
Your patch does indeed fix it - but only after a fresh install of the OS and a repeat of the raider command using the new script.
If it initially fails and you then attempt to run the patched script the process completes but it doesn't actually create the swap volume.
I haven't looked at the script but presumably it thinks the previous step has been completed so doesn't attempt it again,
I chose to re-install the OS from scratch and then run the patched script to get it to complete correctly.
As per the previous poster could you please confirm if / when this will committed to the main branch ?
This will save others experiencing the same issue I hope.
Thanks again - this really is a great tool.