#147 Issue closed: Ensure we have the new partitioning from device¶
Labels: bug, waiting for info
cocampbe opened issue at 2012-08-24 12:28:¶
I have been testing rear and have mixed feelings. Anyway, I got this error and thought I would submit it. I am running OEL6.3.
ERROR: BUG BUG BUG! Unable to find any /boot partitions
Please report this as a bug ...[...]
Total bytes read: 2853734400 (2.7GiB, 121MiB/s)
2012-08-24 07:21:19 Restored 2604 MiB in 23 seconds [avg 115949 KiB/sec]
2012-08-24 07:21:19 Including restore/NETFS/default/50_selinux_autorelabel.sh
2012-08-24 07:21:19 Including restore/default/90_create_missing_directories.sh
2012-08-24 07:21:19 Including restore/NETFS/default/98_umount_NETFS_dir.sh
2012-08-24 07:21:19 Unmounting '/tmp/rear.sTzypWBabDdDb1F/outputfs'
Legacy NFS mount point detected
10.96.102.140:/var/opt/ignite/rear/ umounted
rmdir: removing directory, `/tmp/rear.sTzypWBabDdDb1F/outputfs'
2012-08-24 07:21:19 Finished running 'restore' stage in 24 seconds
2012-08-24 07:21:19 Running 'finalize' stage
2012-08-24 07:21:19 Including finalize/default/01_prepare_checks.sh
2012-08-24 07:21:19 Including finalize/default/10_populate_dev.sh
2012-08-24 07:21:19 Including finalize/GNU/Linux/15_migrate_disk_devices.sh
2012-08-24 07:21:19 Including finalize/Fedora/i386/20_install_grub.sh
2012-08-24 07:21:19 Installing GRUB boot loader
Trace: 134 BugError /usr/share/rear/lib/_input-output-functions.sh
Trace: 141 BugIfError /usr/share/rear/lib/_input-output-functions.sh
Trace: 35 source /usr/share/rear/finalize/Fedora/i386/20_install_grub.sh
Trace: 40 Source /usr/share/rear/lib/framework-functions.sh
Trace: 79 SourceStage /usr/share/rear/lib/framework-functions.sh
Trace: 38 WORKFLOW_recover /usr/share/rear/lib/recover-workflow.sh
Trace: 242 main /bin/rear
2012-08-24 07:21:19 ERROR: BUG BUG BUG! Unable to find any /boot partitions
Please report this as a bug to the authors of Relax and Recover
2012-08-24 07:21:19 Running exit tasks.
2012-08-24 07:21:19 Finished in 44 seconds
2012-08-24 07:21:19 Removing build area /tmp/rear.sTzypWBabDdDb1F
rmdir: removing directory, `/tmp/rear.sTzypWBabDdDb1F'
2012-08-24 07:21:19 End of program reached
gdha commented at 2012-08-24 12:44:¶
which version of rear were you using? And is /boot a mounted
partition?
jhoekx commented at 2012-08-24 12:56:¶
In addition to what Gratien asked, can you post the contents of
/var/lib/rear/layout/disklayout.conf.
cocampbe commented at 2012-08-24 12:57:¶
/boot is set to be at /dev/sda1. I went to the shell and checked that /dev/sda1 had the boot flag using parted. I also mounted /dev/sda1 and checked the fs. I was able to see the kernels, etc. I am rebooting off the rescue cd. I will post the version and other info in a bit.
cocampbe commented at 2012-08-24 12:58:¶
I wish there was better documentation.
cocampbe commented at 2012-08-24 13:13:¶
rear-1.12.0-0-svn704.el6
cocampbe commented at 2012-08-24 13:15:¶
disk /dev/sda 450064605184 msdos
# disk /dev/sdb 107374182400
# disk /dev/sdc 161061273600
# disk /dev/sdd 107374182400
# disk /dev/sde 161061273600
# disk /dev/sdf 107374182400
# disk /dev/sdg 161061273600
# disk /dev/sdh 107374182400
# disk /dev/sdi 161061273600
# disk /dev/sdj 107374182400
# disk /dev/sdk 161061273600
# disk /dev/sdl 107374182400
# disk /dev/sdm 161061273600
# disk /dev/sdn 107374182400
# disk /dev/sdo 161061273600
# disk /dev/sdp 107374182400
# disk /dev/sdq 161061273600
part /dev/sda 534741504 32256 primary boot /dev/sda1
part /dev/sda 449527676928 534773760 primary lvm /dev/sda2
# lvmdev /dev/vgoemccd /dev/mapper/mpd2 Y5WjDe-d7GL-QxZ0-d5hs-PcG8-2sUu-dv2eJx 314572800
# lvmdev /dev/vgora /dev/mapper/mpd1 gfZJMI-bPM9-BBcM-nfAZ-JyYL-KnFh-QspUG3 209715200
lvmdev /dev/vg00 /dev/sda2 AGiUMd-51l7-PyHf-wDec-maTn-IbLZ-4hqQG1 877983744
# lvmgrp /dev/vgoemccd 4096 38396 157270016
# lvmgrp /dev/vgora 4096 25596 104841216
lvmgrp /dev/vg00 4096 107175 438988800
# lvmvol /dev/vgoemccd lvol1 2560 20971520
# lvmvol /dev/vgoemccd lvol2 5120 41943040
# lvmvol /dev/vgoemccd lvol3 25600 209715200
# lvmvol /dev/vgora lvol1 25596 209682432
# lvmvol /dev/vg00 lvol3 512 4194304
lvmvol /dev/vg00 lvol4 1280 10485760
lvmvol /dev/vg00 lvol5 5120 41943040
lvmvol /dev/vg00 lvol6 2560 20971520
lvmvol /dev/vg00 lvol7 5120 41943040
lvmvol /dev/vg00 lvol8 5120 41943040
# lvmvol /dev/vg00 lvol2 8067 66084864
fs /dev/mapper/vg00-lvol3 / ext4 uuid=dcb1e15e-b63a-4050-862e-bb32668ced2a label= blocksize=4096 reserved_blocks=26214 max_mounts=38 check_interval=180d options=rw
fs /dev/sda1 /boot ext4 uuid=be8e5cb7-ca82-4e1c-b033-22e4e06dfc5c label= blocksize=1024 reserved_blocks=26110 max_mounts=31 check_interval=180d options=rw
fs /dev/mapper/vg00-lvol4 /home ext4 uuid=2d5e32d2-5650-4de1-ac87-b69904ddcdd3 label= blocksize=4096 reserved_blocks=65536 max_mounts=30 check_interval=180d options=rw
fs /dev/mapper/vg00-lvol5 /opt ext4 uuid=f005c985-6c2b-4fda-bbfa-2c4c68c65bc3 label= blocksize=4096 reserved_blocks=262144 max_mounts=32 check_interval=180d options=rw
fs /dev/mapper/vg00-lvol6 /tmp ext4 uuid=6fe42d62-29d1-428c-9586-08118853aac7 label= blocksize=4096 reserved_blocks=131072 max_mounts=34 check_interval=180d options=rw
fs /dev/mapper/vg00-lvol7 /usr ext4 uuid=26811c90-87d3-4a8f-befc-a4c1861cc287 label= blocksize=4096 reserved_blocks=262144 max_mounts=32 check_interval=180d options=rw
fs /dev/mapper/vg00-lvol8 /var ext4 uuid=8000f2fa-b621-416e-b0b8-621b6684ebd6 label= blocksize=4096 reserved_blocks=262144 max_mounts=38 check_interval=180d options=rw
# fs /dev/mapper/vgora-lvol1 /oracle/app/oracle ext4 uuid=eb0d8b42-80e6-47cf-911f-5690821947b6 label= blocksize=4096 reserved_blocks=1310515 max_mounts=23 check_interval=180d options=rw
# fs /dev/mapper/vgoemccd-lvol1 /oemccd/oractl ext4 uuid=84e4e122-81ca-4537-aa34-d209986b05f7 label= blocksize=4096 reserved_blocks=131072 max_mounts=26 check_interval=180d options=rw
# fs /dev/mapper/vgoemccd-lvol2 /oemccd/arch ext4 uuid=2f06d7eb-64d1-4744-abf3-831de9edf470 label= blocksize=4096 reserved_blocks=262144 max_mounts=31 check_interval=180d options=rw
# fs /dev/mapper/vgoemccd-lvol3 /oemccd/oradata ext4 uuid=06d09a64-3435-417b-9208-91fae045d4df label= blocksize=4096 reserved_blocks=1310720 max_mounts=38 check_interval=180d options=rw
swap /dev/mapper/vg00-lvol2 uuid= label=
cocampbe commented at 2012-08-24 13:28:¶
I am not sure if this is related. But I have been testing rear rescue from the iso image and I always see this.
Disk configuration is identical, preceding with restore.
No cide has been genereated to restore device fs:/ (fs).
Please add code to /var/..../diskrestore.sh to manually install it or
choose abort.
Upon seeing this I usually continue fro the the fs errors. The first I ran this it looked fine. I then wanted to see if it was truly working, so I deleted /bin on the server and wanted to see if I could restore. After that it when I had this issue. Now the server will not boot. It might be the mbr. I an lokoing for the relax portion of the restore to kick in. ;)
jhoekx commented at 2012-08-24 13:35:¶
All these problems are related to this line:
# lvmvol /dev/vg00 lvol3 512 4194304
Uncomment that line in your rescue image and things should work.
Now on to why it is commented... Can you post your
/etc/rear/local.conf and a log of rear -D savelayout?
One tip: enclose you data with ``` so it will show up as code.
cocampbe commented at 2012-08-24 13:36:¶
Looks like the restore did not restore /bin. I mounted /dev/vg00/lvol3 and checked the fs. bin was not restored. I manually restored it from backup.tar.gz. I then re-ran rear recover, said continue for each
No code has been genereated to restore device fs:
And it came back successful. I guess the 3rd time is a charm?
jhoekx commented at 2012-08-24 13:38:¶
If /dev/vg00/lvol3 was already excluded during rear mkbackup /bin
and /lib etc will indeed not be in the backup.
cocampbe commented at 2012-08-24 13:42:¶
@jhoekx I see that now. Nice catch. here's the local.conf. It's rather simple.
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://10.96.102.140/var/opt/ignite/rear/"
NETFS_KEEP_OLD_BACKUP_COPY=1
ONLY_INCLUDE_VG=( vg00 )
I ran rear -D savelayout. I am not sure if the output should have been to sdout or a file. Sorry. Only just started trying rear yesterday. Lots to learn.
jhoekx commented at 2012-08-24 13:45:¶
Config looks good.
You should try to run it with -D, not -d. Small letter just means
debug which gives extra information and leaves the working directory.
Capital D means super debug with every operation logged.
The output is in /var/log/rear/rear-<hostname>.log.
cocampbe commented at 2012-08-24 13:46:¶
I haven't done any exclusions. /bin is in backup.tar.gz. That is how I was able to manually restore it.
EDIT: My only exclusions are anything that is not in vg00.
cocampbe commented at 2012-08-24 13:49:¶
I updated my comment to have -D, typo on my part. The directory /var/log/rear doesn't exist on the system.
EDIT: created /var/log/rear, and reran rear -D savelayout. Nothing in the directory. I'll do a find and see if I come up with anything.
jhoekx commented at 2012-08-24 13:51:¶
Ah, you're still on an old version. Forgot that. The log is in
/tmp/rear-<hostname>.log.
cocampbe commented at 2012-08-24 13:58:¶
here's the log.
dagwieers commented at 2012-08-24 15:24:¶
I have been testing rear and have mixed feelings.
I am personally interested to learn why exactly the mixed feelings, I can personally think of a few reasons myself, including the fact that it doesn't work on your first try ;-) But we can learn from impressions like yours when the feelings are still fresh.
In some cases certain output (e.g. the message ERROR: BUG BUG BUG!) may not provide confidence to users. This is one of the things I would like to see changed for the better.
I wish there was better documentation.
For this also we need to understand where new users get stuck or trip over. We do have quite some documentation with interesting bits, albeit in a stale state. We recently restructured all documentation into a single document and our aim is to rewrite the documentation to catch up with recent developments. (see #4 and #113) You can find the documentation at: https://github.com/rear/rear/tree/master/doc/user-guide
We welcome contributions and feedback to our current documentation though.
cocampbe commented at 2012-08-24 15:38:¶
@dagwieers Thanks for the doc link. I'll read it over. I was looking at http://relax-and-recover.org/documentation/ and did not see much to work with. The mixed feelings I got were from what I thought was a lack of documentation (again, thanks for the link). And from some of the output I get, i.e.
No code has been genereated to restore device fs:
As a first time user, I was having a lot of "huh?" moments. I have to admit I am more familiar with mondorescue. But stopped using it for reasons I'd rather not mention. I moved to release 1.13. Going to try some more restores.
dagwieers commented at 2012-08-24 16:15:¶
@cocampbe Thanks for the feedback. I agree with you that we could improve that message. But rest assured, our intention is that users would not see that message so we have to find "the why" first ;-)
The mixed feelings I got were from what I thought was a lack of documentation
Right, we are working on that in issue #113, but holidays interfered greatly with our schedule :-D
I have to admit I am more familiar with mondorescue. But stopped using it for reasons I'd rather not mention.
I am also interessed in the reasons you stopped using MondoRescue because we can learn from those experiences too, so feel free to share those (in private if you like). We also have good relations with MondoRescue and MondoRescue is more advanced in some areas compared to Relax-and-Recover. The difference in design and approach (from my point of view) is worthwhile to have both projects and I would hope to collaborate more closely in the future on certain topics.
PS The Relax-and-Recover project has only recently been undergoing a lot of progress, so some of the items are still in a state of flux. We are now focussing on setting up automated testing infrastructure (#38) to ensure that regressions on certain platforms with specific use-cases are a problem of the past. Once this is implemented I expect a surge in development, and from that point we have more reliable releases and we can start to document and promote this project more visibly and with more confidence. We are close to that point, but not yet there.
If you are interested to understand where we are, the issue-tracker (https://github.com/rear/rear/issues) and the release plan (https://github.com/rear/rear/issues/milestones) give a detailed view of what we would like to do. You may notice the large set of features we collected for the future. Anyone is welcome to discuss, implement and provide pull-requests already for any of these, or request new features.
jhoekx commented at 2012-08-27 08:53:¶
I checked your log file and it seems that the issue fixed in fd0be7dc is causing this. Two logical volumes with the same name but in different volume groups would be excluded instead of only one of them.
Can you test this with a recent trunk build or even release 1.13?
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear:/Snapshot/RedHat_RHEL-6/noarch/
dagwieers commented at 2012-08-29 18:58:¶
Implemented commit 1bda18844f053bb32f0adf370fb1747c82a9208f and commit ed5847bd1a6af82b1c06d6999b2f9034911e40f3 to make it easier for users to analyse and report issues, and hence get support.
dagwieers commented at 2012-08-29 19:03:¶
@cocampbe We would like to hear back from you whether this issue was effectively fixed by commit fd0be7dcd5d8796bfa1c73116332d815a0ab1a88. If you would find the time to test the most recent snapshot release (or release v1.13.0), please help us ! Thanks in advance !
cocampbe commented at 2012-08-29 19:41:¶
@dagwieers I plan on doing this tomorrow. I installed 1.13.0-48.
cocampbe commented at 2012-08-30 14:33:¶
All right. I formatted the drives and am in the restore. I am at 6 selection prompt . I got the message that "An error occured during layout recreation. In the log there is warning mesage about the kernel failing to re-read the partition table on /dev/sda. The paritions were created fine. I veryfied it in the shell. When I press 5 to "continue restore script" It brings me back to the prompt. It seems to be occuring because the diskrestore.sh script has not changed.
cocampbe commented at 2012-08-30 14:36:¶
I added partprobe /dev/sda to the script following the parted lines and then continued. The restore is working now.
dagwieers commented at 2012-09-04 16:37:¶
@cocampbe It would help to understand where exactly you added the partprobe, can you send the log indicating the failure through http://gist.github.com/ ? Thanks in advance !
@jhoekx Advice on how to tackle this one ? Do you agree to add a partprobe to every (set of) parted ?
cocampbe commented at 2012-09-04 18:44:¶
@dagwieers
if create_component "/dev/sda" "disk" ; then
_# Create /dev/sda (disk)
Log "Erasing MBR of disk /dev/sda"
dd if=/dev/zero of=/dev/sda bs=512 count=1
sync
LogPrint "Creating partitions for disk /dev/sda (msdos)"
parted -s /dev/sda mklabel msdos >&2
parted -s /dev/sda mkpart primary 32256B 534773759B >&2
parted -s /dev/sda set 1 boot on >&2
parted -s /dev/sda mkpart primary 534773760B 450062450687B >&2
parted -s /dev/sda set 2 lvm on >&2
partprobe /dev/sda <== ADDED
_# Wait some time before advancing
sleep 10
jhoekx commented at 2012-09-05 05:51:¶
So parted does not fail when it displays that warning about the kernel unable to read the partition table?
Let's just add partprobe then.
dagwieers commented at 2012-09-05 06:33:¶
@cocampbe We implemented your fix and would like to know if this fixes your problem (under the same circumstances) when you test your use-case again. Thanks for taking the time to report the issue (and following it through) !
Feel free to comment on or reopen this issue when needed.
[Export of Github issue for rear/rear.]