{5} Assigned, Active Tickets by Owner (Full Description) (67 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
bruno (67 matches)
Ticket | Summary | Component | Milestone | Type | Severity | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Description | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#627 | Mondorestore CTL+ALT+DEL Fails to Cancel Repartitioning | mondo | 3.0.5 | defect | critical | Jun 14, 2012 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ticket raised at the request of Bruno following a report in the mailing list. Fortunately this happened on a test rig. When mondorestore enters the countdown phase prior to repartitioning a disk it instructs the user that the process may be cancelled by the combination keystroke CTL-ALT-DEL. This does not work. This process continues and destroys the partition structure, then recreates it and applies a file system. I think it is important that this feature should work as stated on the screen advice. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#338 | restore problem | mondo | defect | blocker | May 12, 2009 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hello, i'm using sles 10 sp2 x62_64 with mondo 2.2.8-1. The archive prozess running fine, but when i start restore on the same Hardware he stops every time at the same position. He can't configure the harddisks/raids. When i look of the partition with fdisk after mondo stops it looks not nice ( see fdisk.jpg ). I see on device /dev/cciss/c0d1p2 start and end cylinder at 1. The orignal system have no second partion on this device( see fdisk_original.jpg ). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#802 | mindi aborts on Debian 8 on UEFI system | mindi | 3.3.1 | defect | blocker | Jul 6, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When trying to build an ISO image with mindi on Debian 8, it aborts. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#833 | Issues when restoring RHEL7 /boot under XFS format. Just getting GRUB RESCUE prompt | mondo | 3.3.0 | defect | blocker | Jan 24, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hello guys, I have several years using mondo and I would like to thank you for such an amazing application! you have help me a lot! I had been trough several situations and have learn a lot from you using mondorescue packages. In our company we develop at least 2 or 3 times a year Disaster Recovery Exercises, and we have just updated one of our environments to RHEL7. On the last DRE we couldn't restore two images. We had all the same versions (latest) than other servers running RHEL6 and RHEL5 but this time we just got a "GRUB RESCUE>" prompt. Testing the images on a local server I got the same error and I tried even the expert mode and partitioning manually everything and restoring the whole data, but it continued showing the same error. Before continuing I will post some useful information for you: ---------------------------------------------------------------------------------------------------------------------------------------------------- OS efi afio Mondo perl-ProjectBuilder perl-Mondo Mindi Mindi BusyBox Mindi debuginfo Size Mondo line Result ---------------------------------------------------------------------------------------------------------------------------------------------------- RHEL 6.8 yes afio-2.5-1.rhel6.x86_64 mondo-3.2.2-1.rhel6.x86_64 perl-ProjectBuilder-0.12.7-1.rhel6.noarch perl-MondoRescue-3.2.2-1.rhel6.noarch mindi-3.0.2-1.rhel6.x86_64 mindi-busybox-1.21.1-1.rhel6.x86_64 mindi-debuginfo-3.0.1-1.rhel6.x86_64 2.3G mondoarchive -Oi -9 -N -I / -E '/app' -K 99 -f /dev/sda -S /tmp/mondo -T /tmp/mondo -d /Linux_Unix_Images/redhat/wlv-dff-mslap1 -s 4480m -p mslap1-rescuecd Worked fine ---------------------------------------------------------------------------------------------------------------------------------------------------- RHEL 6.8 yes afio-2.5-1.rhel6.x86_64 mondo-3.2.2-1.rhel6.x86_64 perl-ProjectBuilder-0.12.7-1.rhel6.noarch perl-MondoRescue-3.2.2-1.rhel6.noarch mindi-3.0.2-1.rhel6.x86_64 mindi-busybox-1.21.1-1.rhel6.x86_64 mindi-debuginfo-3.0.1-1.rhel6.x86_64 2.3G mondoarchive -Oi -9 -N -I / -E '/app' -K 99 -f /dev/sda -S /tmp/mondo -T /tmp/mondo -d /Linux_Unix_Images/redhat/wlv-dff-mslap2 -s 4480m -p mslap2-rescuecd Worked fine after EFI modification ---------------------------------------------------------------------------------------------------------------------------------------------------- RHEL 6.8 yes afio-2.5-1.rhel6.x86_64 mondo-3.2.2-1.rhel6.x86_64 perl-ProjectBuilder-0.12.7-1.rhel6.noarch perl-MondoRescue-3.2.2-1.rhel6.noarch mindi-3.0.2-1.rhel6.x86_64 mindi-busybox-1.21.1-1.rhel6.x86_64 mindi-debuginfo-3.0.1-1.rhel6.x86_64 2.2G mondoarchive -Oi -9 -N -l GRUB -f /dev/sda -I / -S /tmp/mondo -T /tmp/mondo -d /Linux_Unix_Images/redhat/wlv-dff-msldb4 -s 4480m -p msldb4-rescuecd Worked fine ---------------------------------------------------------------------------------------------------------------------------------------------------- RHEL 6.8 no afio-2.5-1.rhel6.x86_64 mondo-3.2.2-1.rhel6.x86_64 perl-ProjectBuilder-0.12.7-1.rhel6.noarch perl-MondoRescue-3.2.2-1.rhel6.noarch mindi-3.0.2-1.rhel6.x86_64 mindi-busybox-1.21.1-1.rhel6.x86_64 mindi-debuginfo-3.0.1-1.rhel6.x86_64 1.8G mondoarchive -Oi -9 -N -I / -S /tmp/mondo -T /tmp/mondo -d /Linux_Unix_Images/redhat/wlv-dff-msldb5 -s 4480m -p msldb5-rescuecd Worked fine but no graphic console ---------------------------------------------------------------------------------------------------------------------------------------------------- RHEL 7.3 no afio-2.5-1.rhel7.x86_64 mondo-3.2.2-1.rhel7.x86_64 perl-ProjectBuilder-0.14.4-1.rhel7.noarch perl-MondoRescue-3.2.2-1.rhel7.noarch mindi-3.0.2-1.rhel7.x86_64 mindi-busybox-1.21.1-1.rhel7.x86_64 mindi-debuginfo-3.0.1-1.rhel7.x86_64 1.9G mondoarchive -Oi -9 -N -I / -E '/app' -K 99 -f /dev/sda -S /tmp/mondo -T /tmp/mondo -d /Linux_Unix_Images/redhat/wlv-siapp1-prd -s 4480m -p siapp1-rescuecd Issues ---------------------------------------------------------------------------------------------------------------------------------------------------- RHEL 7.3 no afio-2.5-1.rhel7.x86_64 mondo-3.2.2-1.rhel7.x86_64 perl-ProjectBuilder-0.14.4-1.rhel7.noarch perl-MondoRescue-3.2.2-1.rhel7.noarch mindi-3.0.2-1.rhel7.x86_64 mindi-busybox-1.21.1-1.rhel7.x86_64 mindi-debuginfo-3.0.1-1.rhel7.x86_64 2.5G mondoarchive -Oi -9 -N -I / -E '/app' -K 99 -f /dev/sda -S /tmp/mondo -T /tmp/mondo -d /Linux_Unix_Images/redhat/wlv-siapp2-prd -s 4480m -p siapp2-rescuecd Issues ---------------------------------------------------------------------------------------------------------------------------------------------------- As I said I was getting the same error on a LAB developed locally, then I tried several things including setting Grub parameters in order to have the right partition booted. None of those worked. Since troubleshooting mondorescue is something I have done a couple times before I tried a work around and after the "successful" restoration I booted again from the DVD and saw that all the file systems had the information on them, even boot. Then I realized that the information was been set on place but by some reason the app is not seeing the boot partition. Tried running the mkinitrd and fdisk the /dev/sda in order to check everything, but always got to the same place. Something that looked extrange for me was that both partitions /dev/sda1 (boot) and /dev/sda2 (LVM) were marked as bootable partitions then I though something was going on when seting the bootable partition, Then I decided to run manually a mkfs.xfs getting to the same place. What make notice that, as far as I know, thats a RHEL7 characteristic(xfs boot partition), then I reformatted the partition as ext3 and booted the image as INTERACTIVE, allowing to only recover /boot data on the already partitioned and formated partition (voiding those steps on the interactive mode) and "voilà" IT WORKED! Then, the major issue here seems to be that mondo is not recognizing or setting the format correctly(xfs) for boot, (I don't know where to fix that) Hope this looooong story helps and you can have it easily fixed. I bet for sure it will be really easy for you guys to do it. Thanks a lot for the opportunity and keep the great work! I really appreciate it. Best regards,
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#836 | grub2 not restored correctly on RHEL 7.3 and upper | mondo | 3.3.0 | defect | blocker | Mar 31, 2018 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When restoring on RHEL 7.3+, at reboot of the VM used to test, grub doesn't find it's boot partition, and thus doesn't boot the restored system. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#714 | Cannot restore iso created with v3.0.4 mondorescue on RHEL5u6 | mondo | 3.0.5 | defect | critical | Sep 4, 2013 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hi, I have been have recently installed v3.0.4 on RHEL5u6. I have upgraded from v2.2.9.5 due to problems occuring when backing up large sparse files and it using v3.0.4. I have a major problem with the restore.
The command I used to create the archive was /usr/sbin/mondoarchive -OVi -R -N -d /opt -S /opt/backups -T /opt/backups -E "/opt|/opt/backups" -s 16384mb -G -p mondo3.0.4-bkup Can anybody help me please. I have included the logs and error |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#36 | mondoarchive should use an FHS-compliant location | mondo | 4.0.1 | enhancement | major | Aug 8, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
for storing scratch and temporary data and both archive and boot images (see also Mondorescue wiki:StandardsCompliance) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#628 | 3.0.2-1 Fail to Restore from External Hard Disk | mondo | 3.0.5 | defect | major | Jun 15, 2012 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This ticket is raised at the request of Bruno as a result of a mailing list discussion. See archive: Date=June 10 2012 Title=3.0.2-1 Fail to Restore from External Hard Disk A single mondorescue-1.iso backup is successfully created directly to an external hard disk and stored in /mondo. Booting from the mondorescue.iso (mindi) CDROM
It seems that mondorestore mounts the external disk OK but does not use the path to the directory holding the backup ISO. At the suggestion of Bruno mondorescue-1.iso was copied to the root of the external drive and the restore attempted again. This time the ISO is found but the restore fails at a later stage. Booting from the mondorescue.iso (mindi) CDROM
At this point the mondorestore.log was saved as it is not possible to proceed further. The log is attached. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#1 | sprintf used without checks | mondo | 3.3.1 | defect | normal | Jul 31, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
reported by Yann Aubert (<technique_at_alixen.fr>): |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#168 | Make ALL kernel modules be visible during restore | mondo | 4.0.2 | enhancement | normal | May 17, 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When restoring to a hardware setup different than the original (i.e. different RAID/SATA adapter) you can be caught in a catch22 situation wherer you can NOT load the needed kernel modules because mondo/mindi did NOT put ALL OF THEM on the bootable portion of the image. the only current solution is to KNOW the drivers needed BEFORE the mondoarchive (backup) is even done so that they can be "modprobed" into memory so that mondo/mindi makes surethey are available. A more appropriate and correct solution would be to have the ENTIRE kernel modules tree be accessible after booting in rescue mode (i.e. on new hardware). in case hardwaredetection fails (which it does if the disk controller driver is different from the original system), one could then have access to the ENTIRE kernel modules tree to be able to load up the proper driver and continue the restore. If it's not possible to stick it in the bootable section of the image (due to space) it SHOULD be possible to take the kernel modules tree and create that as an ISO on the C and make that loop mountable as needed. I got hit by this bug/defect/limitation, when designing a customer solution in a virtual environment and tried to transfer it over to real physical hardware, it had NO DRIVERS avail (no complete kernel modules tree), which resulting in me having to manually load the drivers in the virtual side before mondo-archiving so that they'd be available when booting the physical machine, but this was a hack and wasted numerous hours to get around a deficiency that should never have been present IMHO. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#280 | Unable to backup to multiple tapes | mondo | defect | normal | Oct 17, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I'm running the currently latest release for debian amd64 from ftp.mondorescue.org. I'm running Debian stable. I have tried the version available in Debian stable repository, same/similar error. When backing up to more than 1 tape, the backup runs nicely, but when it verifies, it stops, just after starting the new tape. I get the same error if I try to restore from tape 2. I have an IBM LTO Ultrium 2 drive. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#832 | RHEL 5 repo - some rpms are signed by unsupported GPG key | mondo | 3.3.0 | defect | normal | Oct 20, 2017 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hi, Some rpms in http://www.mondorescue.org/ftp/rhel/5/x86_64 are signed by unsupported GPG key. # rpm -qip perl-Module-Build-0.3607-1.el5.rf.noarch.rpm
# rpm -qip perl-IO-Interface-1.04-1.el5.rf.x86_64.rpm
# rpm -qip perl-ExtUtils?-CBuilder-0.27-1.el5.pp.noarch.rpm
rpm version: 4.4.2.3-36.el5_11 Regards, Luke |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#202 | Backup of partition larger than local tmp and scratch space | mondo | 4.0.0 | enhancement | blocker | Oct 14, 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hi, I am using mondorescue for some time without any problems for backups and replication of local linux machines, thank you very much! However, now that the time has come to backup the laptop of my boss, problem appeared :( I think I know what is causing it: I am trying to backup several partitions with the overall data size of approx. 80 GB to an NFS mount, but locally there is just 9 GB for scratch and tmp, and it seems that mondorescue wrongly checks if the partition on which tmp and scratch space are has enough space to store the whole amount of data that is being backed up. Details: laptop has windows NTFS partition of 75 GB, and SuSE linux is installed on the rest of HDD, with 9 GB of empty space on Linux. Backup is done to an NFS mount. If windows partition is not backed up, no problems (i.e. small linux partition can be backed up successfully). If windows partition is included (-x /dev/sda2), I get "/dev/sda2: no such file" after I see in the log file that the number of slices is correctly calculated for /dev/sda2. This is misleading message and should be fixed (not enough space is more appropriate, although also not correct). However, if I set scratch (-S) and tmp (-T) directory to be on the NFS mount (the same used for storing the backup iso images), then everything works, since on NFS mount there is enough space (200 GB+), wile on the local disk there is just 9 GB of free space. Of course, this is _very_ slow (15+ hours estimated), and in practice not feasible. Now, I have verified that (with the size of iso images not specified, defaulting to CD size) tmp directory on NFS mount never grows over 150-170 MB, and scratch directory on NFS mount never over 650 MB (of course), which means that local scratch and tmp can be used easily, but for some reason mondorescue fails to realize that and gives up (this happens after backup of linux partitions is finished, at the start of the backup of windows partition as biggiefile). Do you have any ideas how to easily fix this? Versions used: mondo-2.2.4-1.suse10.2.i586.rpm mindi-busybox-1.2.2-3.suse10.2.i586.rpm mindi-1.2.4-1.suse10.2.i586.rpm Thanks, Antun Balaz antun@… |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#183 | LVM restore incorrect when cloning | mondo | 4.0.0 | enhancement | major | Jul 23, 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When cloning and using a different HDD, LVM is not restored correctly as there is a need to change i-want-my-lvm on the fly. The only working solution for now is to edit it separately, run all the commands having a '#' at the begining, and relaunch mondorestore, without partitioning the disk. 2 potential ideas: 1/ propose to edit i-want-my-lvm (short term) 2/ automatically change the value for the disk, if it is changed by the user. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#456 | OBDR mode is not compatible with -H option of mondoarchive | mondo | 3.0.5 | defect | major | Jan 21, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As reported on mondo ML: http://sourceforge.net/mailarchive/forum.php?thread_name=1295604747763-2300816.post%40n3.nabble.com&forum_name=mondo-devel |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#790 | mondorestore says a partition is occupied | mondo | 3.3.1 | defect | major | Apr 7, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When restoring, mondorestore can say that a partition is occupied and stop preparing the disk. This can happen when the restore is done on an MBR disk whereas the original was GPT. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#231 | mondorescue: Storage Dir form input limited to 51 characters | mondo | 4.0.0 | defect | minor | Jan 11, 2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In the mondorestore application under the "Storage Dir" form, the text entry for inputting the path to your ISO files seems to be limited to 51 characters. This is arrived via the following: Run mondorestore select OK Select "Hard disk" The form with the information: Storage dir. Please enter the full path name to the directory for your ISO images. Example: /mnt/raid0_0 is presented to the user, in the text input box I try to add a path greater than 51 characters and am not able to do so, The path gets truncated. This is with version 2.2.4. Best Regards, Bill |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#506 | NFS mount could be done automatically | mondo | 3.0.5 | enhancement | minor | Oct 19, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NFS mount could be done automatically instead of asking the user to do it manually. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#69 | mondoarchive NFS does not work with zeroconf installed | mondo | 4.0.2 | defect | normal | Sep 24, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
zeroconf (www.zeroconf.org) apparently adds an IP address from the 169.254.0.0/16 range to an interface. So, with zeroconf installed I get the following outout from 'ip addr': 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:11:d8:50:e0:80 brd ff:ff:ff:ff:ff:ff inet 169.254.134.104/16 brd 169.254.255.255 scope link eth0 inet 192.168.1.213/24 brd 192.168.1.255 scope global eth0 inet6 fe80::211:d8ff:fe50:e080/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ieee1394 00:e0:18:00:00:ce:cf:54 brd ff:ff:ff:ff:ff:ff:ff:ff 4: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 The interesting one here is 2: The 192.168.1.213 address is what is configured as a static address. 169.254.134.104 is what zeroconf adds. Networking in general works fine with this. However, mondoarchive uses ifconfig to obtain the IP address for the NFS config. 'ifconfig' gives: eth0 Link encap:Ethernet HWaddr 00:11:D8:50:E0:80 inet addr:169.254.134.104 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::211:d8ff:fe50:e080/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13785 errors:0 dropped:0 overruns:0 frame:0 TX packets:10514 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:17528791 (16.7 MiB) TX bytes:977510 (954.5 KiB) Interrupt:177 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:358 errors:0 dropped:0 overruns:0 frame:0 TX packets:358 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20284 (19.8 KiB) TX bytes:20284 (19.8 KiB) which means it only gives the IP address configured by zeroconf. And that address is what is using during restore and of course doesn't work. I am not 100% sure what to do here but don't think it is super urgent. I mainly wanted it documented somewhere - maybe we should also put it in the wiki ? One interesting comment I saw is that apparently ifconfig is getting superseded by the ip command. Maybe we need at some stage replace ifconfig with ip. Cheers, Andree |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#83 | Create a package hierarchy to ease installation | mondo | 4.0.2 | defect | normal | Oct 12, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Create new packages to help deploy mondo. Cf DistributionPackaging |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#91 | Error message goes to console, but not to log | mondo | 4.0.2 | defect | normal | Oct 28, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
During diagnosis of a different problem, I was presented with an on-screen (console) message reading, in part...
However, these error messages didn't appear in the log. When I submitted the information to the mondo-devel list, I included both the (compressed) lot, and this snapshot of the screen (above). It might be useful to make sure all error messages are echoed to the log, so sending you that log would be adequate for your further investigation. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#104 | Mondoarchive segfaults when encoutering deep filesystem arborescence | mondo | defect | normal | Nov 18, 2006 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I got a segfault in mondoarchive during the catalog make stage, when trying to archive an EXT3 filesystem with a really really deep arborescence (consecutively to a scp or tar - I don't remember - of a dumb directory with a stupid symbolic link of the '.' file). After removing this arborescence, the process goes fine. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#118 | In compare mode allow mountlist changes before operation | mondo | 4.0.2 | enhancement | normal | Dec 29, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
During the compare operation, mondorescue only uses the mountlist from the source system. If the target system does not have the same mountlist, compare will failed. The proposal is to add an interactive mode to change the mountlist before doing the compare operation. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#149 | mondorestore should use efibootmgr to recreate menu entries on ia64 | mondo | 3.3.1 | enhancement | normal | Mar 21, 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
mondorestore should use efibootmgr to recreate menu entries on ia64. Without that it's actually difficult to know nd find on which device the system should boot. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#152 | Bootable USB that backs up to DVDs | mindi | 4.0.0 | enhancement | normal | Apr 16, 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I am requesting the following enhancements to Mondo/Mindi?: A live CD (or other method of creating this) that would scan the system for necessary drivers and such to create a custom, bootable USB disk with the necessary drivers for the DVD burner, etc. The USB disk would contain a backup-to-DVD solution that created a backup and burned bootable DVDs (DVDs just like Mondo's current DVD backups). Just to be clear: I do not want to back up files to the USB drive -- I want to BOOT from the USB and burn backups to DVDs. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#167 | VxFS support | mondo | defect | normal | May 15, 2007 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
More over, ran on a system with VxFS FS it umounts those FS at the end of the run, which it shouldn't. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#198 | Wrong ext3 block size after restore | mondo | 4.0.0 | defect | normal | Sep 24, 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When I restore a backup to a new hard disk and let Mondo do the partioning and formatting, it uses 1024 as ext3 block size, but the original hard disk had 4096. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#213 | XFS volumes with external log could not be mounted during restore | mondo | 4.0.0 | defect | normal | Nov 11, 2007 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As requested by Bruno in his reply to my posting in the Mondo mailing list with the same subject I fill a new ticket here: On my Debian system I run some lvm volumes with xfs filesystem and external logging. As I tried as a first step to compare the backup using the created CD image, Mondo Restore stoped because it could not mount the volumes which uses the external logging. The log-file shows, that Mondo tries to mount the volumes without the option for the external log. I schould attach the logfiles here but I don't find the option to do so in the moment. Hope I can attach them later... Greats Harald |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#230 | allow exclusion of files | mondo | 4.0.0 | defect | normal | Jan 9, 2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When dealing with very large files useless in a backup (aka a 22GB swap file e.g.) allow for their exclusion with -E or something similar. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#267 | UIDs / GIDs not enough bits | mondo | 4.0.0 | defect | normal | Jun 26, 2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
user with uid 98765 becomes user 33229 after mondo restore. 98765 - 33229 = 65536. Integer Overflow. This is on RedHat? 5 (32 bit) on VMware ESX 3.0.2. with mindi 2.0.1. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#272 | mondo should support other type of NICs | mondo | 4.0.0 | defect | normal | Jul 30, 2008 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
mondo should support other type of NICs such as xenbrxx, vlanxx, ... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#276 | Adds full OCFS2 support | mondo | defect | normal | Sep 19, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Adds full OCFS2 support in order to be able to backup/restore RAC configurations. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#279 | Mondorestore interactive mode restores uselss empty dirs | mondo | defect | normal | Oct 14, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
t also restores a few other empty directories which weren't selected in the file list. They seem to be consistent, in that I've done it twice and it restored the same 3 empty directories (note that they weren't empty on the original system). Since no unwanted files from those directories were restored I suppose that it's not really a big problem, but it is odd. The unwanted directories restored in addition to what I asked for were: /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur /tmp /var/lib/mysql I've noticed that they seem to be coming from the biggiefiles section even though they weren't selected. Done. Reassembling large files [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2397: OK, there are 5 biggiefiles in the archives [Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2, --- pih=NO [Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2, (name isn't in biggielist subset) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 1 (/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2,) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"' [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #0 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #1 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #2 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #3 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #4 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #5 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #1, slice #6 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now [Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140740942.3798_596.rlo.com.au,S=86071333:2, [Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 931bcc31faaebc228109f8f78c95f201 [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored [Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2, --- pih=NO [Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2, (name isn't in biggielist subset) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 2 (/home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2,) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"' [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #0 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #1 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #2 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #3 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #4 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #5 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #2, slice #6 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now [Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/bud.growcott/Maildir/.Pallet control/cur/1140741010.3798_597.rlo.com.au,S=86075819:2, [Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = f9ba3e4c5d6b8daf10d5c47d4fcedc78 [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored [Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz --- pih=NO [Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz (name isn't in biggielist subset) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 3 (/home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"' [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #0 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #1 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #2 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #3 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #4 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #5 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #6 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #3, slice #7 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now [Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /home/vpopmail/domains/ticgroup.com.au/sapsupport.tar.gz [Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 1e4aa002fbebb935d4a185d708782b51 [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored [Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /tmp/selected-files.txt --- pih=NO [Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /tmp/selected-files.txt (name isn't in biggielist subset) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 4 (/tmp/selected-files.txt) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"' [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #0 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #1 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #2 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #3 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #4 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #5 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #4, slice #6 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now [Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /tmp/selected-files.txt [Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 841aec6a37f6d2d2b9991eb31f9f6fd2 [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored [Main] mondorestore.c->restore_a_biggiefile_from_stream#1395: /var/lib/mysql/ibdata1 --- pih=NO [Main] mondorestore.c->restore_a_biggiefile_from_stream#1418: Skipping /var/lib/mysql/ibdata1 (name isn't in biggielist subset) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1481: Reassembling big file 5 (/var/lib/mysql/ibdata1) [Main] mondorestore.c->restore_a_biggiefile_from_stream#1501: Pipe command = 'cat > "/dev/null"' [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #0 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #1 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #2 [...] [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3184 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3185 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3186 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3187 update_progress_form_full( I am now reassembling all the large files. ,Working on file #5, slice #3187, Please wait. This may take some time. ) --- g_current_progress=3216; g_maximum_progress=3215 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3188 update_progress_form_full( I am now reassembling all the large files. ,Working on file #5, slice #3188, Please wait. This may take some time. ) --- g_current_progress=3216; g_maximum_progress=3215 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3189 update_progress_form_full( I am now reassembling all the large files. ,Working on file #5, slice #3189, Please wait. This may take some time. ) --- g_current_progress=3216; g_maximum_progress=3215 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3190 update_progress_form_full( I am now reassembling all the large files. ,Working on file #5, slice #3190, Please wait. This may take some time. ) --- g_current_progress=3216; g_maximum_progress=3215 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3191 update_progress_form_full( I am now reassembling all the large files. ,Working on file #5, slice #3191, Please wait. This may take some time. ) --- g_current_progress=3216; g_maximum_progress=3215 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3192 update_progress_form_full( I am now reassembling all the large files. ,Working on file #5, slice #3192, Please wait. This may take some time. ) --- g_current_progress=3216; g_maximum_progress=3215 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1515: Working on file #5, slice #3193 update_progress_form_full( I am now reassembling all the large files. ,Working on file #5, slice #3193, Please wait. This may take some time. ) --- g_current_progress=3216; g_maximum_progress=3215 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1561: pathname_of_last_file_restored is now [Main] mondorestore.c->restore_a_biggiefile_from_stream#1573: biggiestruct.filename = /var/lib/mysql/ibdata1 [Main] mondorestore.c->restore_a_biggiefile_from_stream#1574: biggiestruct.checksum = 78161e8cd4e70e2c30ae89e5070f4ac0 [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2430: I believe I have restored [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2447: 5 biggiefiles in biggielist.txt; 5 biggiefiles processed today. [Main] mondorestore.c->restore_all_biggiefiles_from_stream#2470: mondorestore.c, restore_all_biggiefiles_from_stream, 2470: No biggiefiles selected. So, no biggie-EXATs to set. Done. [Main] libmondo-stream.c->closein_tape#120: closein_tape() -- entering [Main] libmondo-stream.c->closein_tape#138: closein_tape() -- leaving running: mt -f /dev/st0 offline > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- --------------------------------end of output------------------------------ ...ran just fine. :-) [Main] libmondo-devices.c->eject_device#235: Ejecting /dev/st0 running: eject /dev/st0 > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- --------------------------------end of output------------------------------ ...ran just fine. :-) [Main] libmondo-files.c->length_of_file#611: filename=/etc/raidtab Unable to openin filename (No such file or directory) running: ps | grep " petris " | awk '{print $1;}' | grep -v "grep" > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- --------------------------------end of output------------------------------ ...ran with res=256 running: kill `ps | grep " petris " | awk '{print $1;}' | grep -v "grep"` > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- kill: usage: kill [-s sigspec | -n signum | -sigspec] [pid | job]... or kill -l [sigspec] --------------------------------end of output------------------------------ ...ran with res=256 [Main] mondorestore.c->restore_everything#2716: restore_everything() --- leaving Freeing memory formerly occupied by filelist [Main] libmondo-filelist.c->free_filelist#429: Finished freeing memory [Main] mondorestore.c->restore_to_live_filesystem#974: Tape : I don't need to unmount or eject the CD-ROM. running: umount /mnt/cdrom > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- umount: /mnt/cdrom: not mounted --------------------------------end of output------------------------------ ...ran with res=256 running: mt -f /dev/st0 offline > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- /dev/st0: Input/output error --------------------------------end of output------------------------------ ...ran with res=256 [Main] libmondo-devices.c->eject_device#235: Ejecting /dev/st0 running: eject /dev/st0 > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- --------------------------------end of output------------------------------ ...ran just fine. :-) [Main] mondorestore.c->main#3194: Still here. Yay. running: rm -Rf /storage/mondo.tmp.MXRHQj/* > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- --------------------------------end of output------------------------------ ...ran just fine. :-) [Main] libmondo-tools.c->unmount_boot_if_necessary#1309: starting [Main] libmondo-tools.c->unmount_boot_if_necessary#1316: leaving [Main] libmondo-files.c->register_pid#815: Unregistering PID running: umount /mnt/cdrom > /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.tmp 2> /storage/mondo.tmp.MXRHQj/mondo-run-prog-thing.err --------------------------------start of output----------------------------- umount: /mnt/cdrom: not mounted --------------------------------end of output------------------------------ ...ran with res=256 [Main] newt-specific.c->finish#406: Calling newtSuspend() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#301 | Add EMC Powerpathed boot from SAN support | mondo | defect | normal | Dec 14, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Has anyone tried using Mondo with EMC Powerpathed boot from SAN drives? It works fine with boot from SAN drives, that are not running powerpath or mpxio. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#303 | create a mondoarchive on an automounted nfs share without mounting first | mondo | enhancement | normal | Jan 6, 2009 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I want to use the "-n" option with mondoarchive, to write to an automounted nfs share. For instance, we have have a NAS appliance called pisrh11, which has space carved up for nfs shares. On our servers, we are using the automounter, which automatically maps shares on pishr11, based on entries in the /etc/auto_* files. Here would be the automount file for application installed locally: # more /etc/auto_apps TRPperf -rw localhost:/export/appl/pkgs/& pb -rw localhost:/opt/& # PowerBroker java -rw localhost:/export/appl/pkgs/& AppManager -rw localhost:/export/appl/pkgs/AppManager/v8 Here is the master automount file which points to some NIS maps: # more /etc/auto_master /trprmt/logs yp:auto.trprmt /nfs yp:auto.nfs /apps /etc/auto_apps And here is the NIS entry for the mondoarchive shares: # ypcat auto.nfs|grep Linux -soft,bg,rw pishr:/images_Linux/trp -soft,bg,rw pishr11:/images_Linux/trp Here is the share mounted: # pwd /root (piadm41)# cd /nfs/LinuxImages (piadm41)# pwd /nfs/LinuxImages (piadm41)# df -k . Filesystem 1K-blocks Used Available Use% Mounted on pishr:/images_Linux/trp 103257600 3244608 100012992 4% /nfs/LinuxImages (piadm41)# mount|grep Linux pishr:/images_Linux/trp on /nfs/LinuxImages type nfs (rw,soft,addr=10.22.214.26) Thanks again. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#334 | Ram disk computation based on initrd size | mondo | defect | normal | Apr 28, 2009 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It would be interesting to compute the ramdisk_size parameter based on the real size of the initrd contant, in order to avoid issues when populating it with cryptic messages such as: Installing additional tools... Populating / with tar file content... tar : write error : No space left on device Also adapting the message to suggest to increase ramdisk size in the mean time would be great. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#349 | error message on screen | mondo | defect | normal | Jul 28, 2009 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
while running mondoarchive I noticed this error. ---evalcall---E--- ---evalcall---1--- Making catalog of /home ---evalcall---2--- TASK: [*********...........] 44% done; 0:06 to go ---evalcall---E--- sh: -c: line 0: unexpected EOF while looking for matching `'' sh: -c: line 1: syntax error: unexpected end of file ---evalcall---1--- Making catalog of /home ---evalcall---2--- TASK: [***********.........] 53% done; 0:05 to go ---evalcall---E--- It may be due to this: Under .java/.userprefs there were directories like below: I deleted them and mondo ran OK. ~/.java/.userPrefs/_!'8!cg"n!#4!b@"v!(}=> ls _!'0!}@"4!&8!d@"z!'`!cg"f!'k!bg"0!'`!cg"m!'%!}w"l _!'0!a@"u!&8!d@"z!'`!cg"f!'k!bg"0!'`!cg"m!'%!}w"l _!'0!}@"j!()!bw"z!&8!a@"u!'}!bw== cache display _!(%!d@"v!(@!~@"f!(:!bw"1!()!}w"l equations _!'k!~!"f!(%!d@"v!(@!~@"f!(:!e@"u!':= language license macros _!'@!~@"m!'%!d@"s!(@!|w"j!'g!}@"y!(@!|w"k!'`!~g"h!(`!b!"0!(:= portfolio prefs prefs.xml proxy watchscreens |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#350 | Screenshots in documetation are illegible | mondo-doc | defect | normal | Jul 29, 2009 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Documentation screenshots are illegible, for example Chapter 2. Quickstart shows a 160x96 pixel image. Using mini images is fine for the HTML online version (which hyperlink to full size screenshots), but the PDF and postscript versions should include the full resolution images rather than the mini ones. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#351 | mondoarchive and exclude list problem | mondo | defect | normal | Sep 3, 2009 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hey, I noticed that even if mondoarchive is running with exclude to some directories and exclude the NFS file systems, when the mondo is making the catalog, he is 'lstat'ing ALL the files including those to be excluded later. The problem is that we have servers with NFS mount point that holds millions of millions of files and the lstat is taking too long ( + making the NFS server work very hard). Is it possible somehow to change this behavior ? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#378 | making mondo archives from a live USB | mondo | 4.0.2 | defect | normal | Jan 2, 2010 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I'm having troubles running Mondoarchive and Mindi on Ubuntu 9.10 64-bit using either versions from the repositories or versions from the website. I gather I could recompile a kernel to get it running, as I keep getting a FATAL ERROR: Libata module not found message. I suppose I could also find a version of the mindi-kernel to try to use the failsafe kernel, but it's not readily available without a lot of digging and searching. Right now, I'm figuring that it might just be easier to install a different, earlier version of Ubuntu on a separate partition, for the sole purpose of making mondoarchives. I can't see why this won't work. But it occurred to me that it might be possible to make a live USB Mondo Rescue linux version, which would allow people with insane kernels to make backups readily. I searched around through versions of DSL and others to see if this was something that had been done before, but couldn't find anything. Can anyone see any major problems with this approach? I'm a relative newbie with big gaps in my general knowledge, although not scared of reading howtos or using the command line if that seems the easiest way to do something. Thanks for any input that anyone can provide. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#386 | Automagically toggle the -z flag when SELinux is on | mondo | enhancement | normal | Jan 15, 2010 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
mondoarchive could indeed Automagically toggle the -z flag when SELinux is on. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#394 | post= option not working | mondo | 3.0.5 | defect | normal | Feb 9, 2010 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It seems that the post option is not invoked correctly when used, whereas the pre= option is. To be checked closely. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#403 | mondo ignore non system partitions | mondo | 4.0.0 | defect | normal | Mar 11, 2010 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hello, I have system, which contains non standard filesystem partitions (informix data parts). Mondo can't backup them (ofcourse), he ignores them. When I want to clone system, he don't know about these partitions and I have to make them by hand. When cloning multiple machines, it is annoying. I resolved this by saving (sfdisk -d) for all drives in system, and in modified post-init, if they didn't match current setup, I ask to repartition them. I wish mondo can parttion them in the same fashion. Moreover, it is philosophical that mondo should include two basic modes: restore to original system and clone system. In restore original, the system ramdisk & bootup process could be used to ensure correct module & device initialization, repartition drives to same configuration with NO questions :). In clone mode, there could be that nice features like inserting all modules, mountlist resizing and checking, many questions etc. Thanks running OpenSuse? 11.1 & 11.2 64 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#406 | persistent devices and naming by id | mondo | enhancement | normal | Mar 11, 2010 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
While backup, mondo should remember kernel node to /dev/disk/by-id mapping, and after restore automatically modify settings in /etc/fstab /boot/grub/menu.lst /boot/grub/device.map /etc/grub.conf Also, the /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-cd.rules should be removed to prevent system to create shifted dev names. (eg. eth0 directly mapped to mac) And small one at the end, mondo scratch dirs aren't removed from backup. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#423 | Compare mode in mondoarchive doesn't work with -d option correctly. | mondo | defect | normal | Jun 4, 2010 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When using /usr/sbin/mondoarchive -Vr -d /dev/sr0 -s 4480m -g mondoarchive asked me what device to compare, even though I have it in the command line. (report from Robert E Laughlin) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#507 | Place scratch dir automatically on NFS | mondo | 3.0.5 | enhancement | normal | Oct 19, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
How to put the scratch dir on the NFS mount automatically (mount is done inside mondo - normally - so user has no way as of now to specify the creation of the scratch dir under that mount point, which would be useful in that case. From code it seems that scratchdir is created on the fly so should work. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#509 | pre script limitation | mondo | 3.0.5 | enhancement | normal | Oct 19, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Problem for pre script: it has to be at the root of the NFS share mounted. subdir are not handled, due to copy under /tmp as of now |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#510 | grub install issue with dm multipath | mondo | 3.0.5 | defect | normal | Oct 19, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Restoration is done by default for grub on sda (because multipath and GRUB found on sda, sdb, dm-2 => prefer to get a question at restore time + option in boot cli) Also useful for P2V. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#625 | lvm size appear to zero | mondo | enhancement | normal | Jun 12, 2012 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
During restore, the partitions are correctly sized but the lvm size appear to zero. Mondorestore will size the lvm correctly when it will continue to process. The sizes are correctly computed by the script /tmp/i-want-my-lvm. But It should be good to have the lvm size not displayed to zero. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#642 | mondoarchive -OVN does not exclude automounts | mondo | defect | normal | Aug 30, 2012 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
hello, mondoarchive -OVN does not exclude unmounted automounts from the catalog, so it backs up the complete mountpoint as it gets mounted when the actual backup starts. A scripted ls -l to the automount directories close before the backup does help but is not that nice! The used versions are: mondo-3.0.2-1.sles10 mindi-busybox-1.18.5-1.sles10 mindi-2.1.3-1.sles10 kind regards Daniel Berglar |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#695 | Mondo does not seem to support drbd | mondo | 4.0.0 | enhancement | normal | Jun 4, 2013 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Hi All, I have backed up a server running drbd and restored it to another server with the same hard disk configuration. When I try to look at the restored drbd partition using drbdadm role r0 I get the error message Unconfigured. When I try to check my replica mount, I see that /dev/drbd0 is not mounted and the mount point is now a folder on /dev/mapper/VolGroup00-LogVol00. I am running mondo V3.0.3-r3091. Any ideas on how to fix this most gratefully received. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#710 | Ability to use the HP ProLiant SD card slot for DR | mondo | 3.0.5 | enhancement | normal | Jul 22, 2013 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It would be interesting to validate the usge of MondoRescue with an SD card put in an HP ProLiant server to use it as a DR mecanism. While it should'nt require any specific adaptation, it has never been tested so would at leat require that step to be performed. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#789 | mondoarchive doesn't create a bootable UEFI media on Debian 8 | mondo | 3.3.1 | defect | normal | Apr 5, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
As reported on the ML: If i boot the CD in 'UEFI' mode, i get: error: no such partition. Entering rescue mode... grub rescue> _ in rescue mode: grub rescue> ls (hd0) (hd1) (cd0) grub rescue> set cmdpath=(cd0)/EFI/BOOT prefix=(cd0,gpt2)/boot/grub root=cd0,gpt2 If i boot it in 'legacy' mode, i get ISOLINUX boot banner and then: Failed to load isolinux.c32 Boot failed: press a key to retry... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#797 | ldlinux.c32 not foud while booting | mondo | 3.3.1 | defect | normal | Apr 30, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Debian 8.4 - amd64 arch packages from deb ftp://ftp.mondorescue.org/debian 8 contrib UEFI system trying to boot generated CD, but it failed with error message that ldlinux.c32 can't be found Tried to copy all files form $scratch\EFI to $scratch (while backup is in progress) so I force ldlinux.c32 and configuration files to root dir on CD and evereything started to work again. mindi - 3.0.2-1 mindi-busybox - 1.21.1-1 mondo - 3.2.2-1 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#803 | dependencies issue on Debian 8 | mondo | 3.3.1 | defect | normal | Jul 6, 2016 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Installing mondo withapt-get install on Debian 8 works, but there are dependencies lacking (some are mandatory, some nice to have) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#823 | /dev/loop0 getting left behind | mondo | 3.3.0 | defect | normal | Aug 9, 2017 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
After mondobackup complete, we are seeing this mount get left behind. It's small and tends to be over 90% full, which causes our monitoring software to create a ticket. SLES 12 SP1 # rpm -qa | grep -i mondo mondo-3.2.2-1.sles12.x86_64 perl-MondoRescue-3.2.2-1.sles12.noarch # rpm -qa | grep -i mindi mindi-busybox-1.21.1-1.sles12.x86_64 mindi-3.0.2-1.sles12.x86_64 # df | grep loop /dev/loop0 110766 100996 9770 92% /tmp/syslinux.mnt.10184.0 I've never seen this behavior before. Help? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#824 | floppy error: -5 while reading block 0 | mondo | 3.3.0 | defect | normal | Aug 17, 2017 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I see this in the messages file about 100 times every time mondobackup runs. Why? See attached mondoarchive.log. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#85 | abandoned files | mondo | 4.0.2 | defect | minor | Oct 13, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
On Suse 10.1 kernel 2.6.xxx using switches -S /tmp -T /tmp the following directories get orphaned in /tmp cd.xxxx mondo.scratch.xxxx tmp.mondo.xxxx On RH9 not using those switches the diretories are not left behind. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#86 | graphic tape issue and text progress indicator | mondo | 4.0.2 | defect | minor | Oct 13, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ver 2.09 I noticed that when verifying biggie files in graphic mode the progress tape never goes over 1%. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#95 | Physical extent size for volume group isn't preserved | mondo | 4.0.0 | defect | minor | Nov 1, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The physical extent size for volume group isn't preserved but set to the default of 32MB. Not that it's a problem, just a note. (From "Chua, Alfred" <alfred.chua_at_hp.com>) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#109 | add a timestamp to the logfiles name | mondo | 4.0.2 | enhancement | minor | Nov 22, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It would be nice if you could add a timestamp to the filename of the logfile. So you wouldn't override the previous logfile and bugtracking would be easier. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#125 | Add option for suppress of evalcall and progress-form | mondo | enhancement | minor | Jan 9, 2007 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I'm running mondoarchive from cron. The output from cron is sent as email to the local root account. This size of this output is often larger than 1MB due to a large number of lines starting with "---evalcall---" or "---progress-form---". I suggest the addition of an option that suppresses these messages (i.e. 'non-interactive mode'). # /usr/sbin/mondoarchive --version mondoarchive v2.0.9-780 $ uname -a Linux mylinux 2.6.9-42.0.3.EL # 1 Fri Oct 6 05:59:54 CDT 2006 i686 i686 i386 GNU/Linux Thanks for the great software Bruno. Best regards, Andreas -- |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#482 | -V switching to verify timing issue | mondo | 3.0.5 | defect | minor | Jun 17, 2011 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When I run mondoarchive using -V (verify) mondo asks for device /dev when switching from making the DVD to verifying the DVD. During the start of the verify mondo asks for the /dev. If I answer the /dev prompt immediately mondo then asks to abort the backup. But if I wait till the dvd activity stops then enter /dev/sr0 the verify proceeds and the mondoarchive with verify succeeds. log attached |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#40 | have a live CD including mondo rescue | mondo | 4.0.2 | enhancement | normal | Aug 8, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This will allow backing up systems offline as well as backing up Window based systems. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#232 | Owner of symbolic links is not restored correctly. | mondo | defect | normal | Jan 17, 2008 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I have restored RHEL5.1 with mondo-2.2.4-1.rhel5 and compared "rpm -Va" results taken before and after the restoration. And I found that ower user and group of symbolic links originally different from root.root was changed to root.root. # diff node01.2008011663155/rpm-Va node01.2008011684617/rpm-Va 1218a1219,1225 > .....UG. /usr/bin/rpmdb > .....UG. /usr/bin/rpmquery > .....UG. /usr/bin/rpmsign > .....UG. /usr/bin/rpmverify > .....UG. /usr/lib/rpm/rpme > .....UG. /usr/lib/rpm/rpmu > .....UG. /usr/lib/rpm/rpmv These are all symbolic links to another file, for example; <Original> # ls -l /usr/bin/rpmdb lrwxrwxrwx 1 rpm rpm 15 Jan 16 17:29 /usr/bin/rpmdb -> ../lib/rpm/rpmd <After Restoration> # ls -l /usr/bin/rpmdb lrwxrwxrwx 1 root root 15 Jan 16 17:29 /usr/bin/rpmdb -> ../lib/rpm/rpmd As owners of linked "real" files were not modified, there's probably no practical issue. But I think, if possible, it's better to fix it. (Sorry for that I have no idea how to fix it.) RPMs I used are as below; afio-2.4.7-1.x86_64.rpm buffer-1.19-1.x86_64.rpm mindi-1.2.4-1.rhel5.x86_64.rpm mindi-busybox-1.2.2-3.rhel5.x86_64.rpm mondo-2.2.4-1.rhel5.x86_64.rpm |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#387 | Backup with SELINUX=permissive may result to restore errors due to /proc & /sys extended attributes | mondo | 3.0.5 | defect | normal | Jan 20, 2010 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The following errors are encountered when trying to restore the backup: setfattr: proc: Operation not supported setfattr: sys: Operation not supported Due to that, the GUI restore phase does not seem to finalize properly for a lambda end-user (even if it may have no other impacts).
It has been observed in the filelist-7 that /proc and /sys were backed-up with the following xattr: # file: proc security.selinux=0x73797374656d5f753a6f626a6563745f723a70726f635f743a733000 === # file: sys security.selinux=0x73797374656d5f753a6f626a6563745f723a73797366735f743a733000 Even if /proc and /sys sub-files/sub-dirs are not backed-up, we should also fully remove /proc and /sys from the backup. I guess removing it from the backup would avoid that kind of issue at restore time. Note that the WA to set -E "/proc /sys" to exclude them did not work for me. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
#648 | Additional Control Over Boot in Mindi Configuration | mindi | 3.0.5 | enhancement | trivial | Oct 17, 2012 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I have run into a scenario where it would be useful to have a little more control over how recovery media boots. In particular, the boot loader timeout and default boot option. For my purposes, it would be useful to have restoration media timeout quickly and boot into expert mode as a default. Once booted the user will be able to select backups from library disk to restore from via a script (that eventually call on mondorestore). Using mindi versus mondo would be an option to get expert working as the default but it would require that I handle the generation of CD/DVD media externally, something which mondo does nicely already. The changes required to implement this are minimal. Establish globals prior sourcing mindi.conf: MINDI_ADDITIONAL_BOOT_PARAMS="..." MINDI_DEFAULT_BOOT_OPTION="" MINDI_BOOT_TIMEOUT="" in MakeBootConfFile?, handle the mindi.conf default option and timeout for mondoarchive non-CDRECOVERY only: MakeBootConfFile() { ... # Compute which default option to boot from ... elif [ _"$MONDO_SHARE" != _"" ]; then if [ -e "$MINDI_TMP/NETFS-DEV" ]; then echo -en "default${sep}iso\n" elif [ "$MINDI_DEFAULT_BOOT_OPTION" != "" ]; then LogIt "Overriding default boot option: $MINDI_DEFAULT_BOOT_OPTION" echo -en "default${sep}${MINDI_DEFAULT_BOOT_OPTION}\n" else echo -en "default${sep}interactive\n" fi else .... # Handle timeout if [ "$CDRECOVERY" == "yes" ]; then echo -en "timeout${sep}1000\n" elif [ "$MINDI_BOOT_TIMEOUT" != "" ]; then LogIt "Overriding boot timeout: $MINDI_BOOT_TIMEOUT" echo -en "timeout${sep}${MINDI_BOOT_TIMEOUT}\n" else echo -en "timeout${sep}300\n" fi .... } A small change but one that would be useful. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||