Re: Mindi error on UEFI system

Hello,
I have finally found some time to look into this again. After your 
response, I was confused. I kept looking into the code, and even after 
many more attempts, I still don't understand how this could work. Unless 
there is some hidden magic, we can't copy image of given size into the 
fs made in this image, it will never fit, regardless of how big it is. 
Even when it is a copy, the size is still the same.
So I made these changes into mindi on my system and backup now succeeds. 
I have no idea which files are needed for EFI boot, so I kept them all. 
I still need to test it actually boots, but at least it does not report 
any errors :-).

Best regards

Tomas

--- mindi    2020-12-29 17:57:44.623191813 +0100
+++ mindi-mine    2020-12-29 17:58:24.626430683 +0100
@@ -1874,6 +1874,13 @@
  if  [ "$target" = "ISO" ]; then
      cp $part $MINDI_CACHE
      if [ "$ARCH" = "ia64" ] || [ "$BOOT_TYPE" = "UEFI" ]; then
+
+        # TK hack
+        # create a new, bigger image instead of the original one
+        size2=$(($size*2))
+        dd if=/dev/zero of=$part bs=1k count=$size2 &> /dev/null || Die 
"Cannot dd blank $part"
+        mkfs.vfat $part 2>&1 >> $LOGFILE
+
          # Mount again !
          LogAll "INFO: Re-Mounting $part on $MINDI_TMP/mpt"
          mount -t vfat $mount_opt $part $MINDI_TMP/mpt 2>> $LOGFILE
@@ -1892,6 +1899,8 @@
          ls -lR $MINDI_TMP/mpt >> $LOGFILE
          LogFile "------------------------------------------"
          MakeISO
+        # TK hack
+        umount $MINDI_TMP/mpt
      fi
  else
      # USB


On 03/12/2020 18:45, Bruno Cornec wrote:
> Hello Tomas,
>
> Tomas Kopal said on Wed, Dec 02, 2020 at 03:52:15PM +0100:
>> Turns out only after upgrade I started doing backups as UEFI. Most 
>> issues were easy to resolve, but the last one.
>
> I'm interested by the issues youfixed, if they are of general insterest.
>
>> During boot disc creation, mindi reports an error:
>> '/tmp/mondo.tmp.xrh8ft/mpt/images/mindi-bootroot.img': No space left 
>> on device*
> [...]
>> But, for ISO image on UEFI system (my case), there is more code 
>> starting on line 1875 
>> (http://trac.mondorescue.org/browser/MondoRescue/branches/3.3/mindi/mindi#L1875), 
>> where the final partition image is copied to $MINDI_CACHE, then the 
>> original image is mounted to $MINDI_TMP/mpt (line 1879). Then the 
>> copy of the image from $MINDI_CACHE is mounted to $MINDI_TMP/mpt2 
>> (line 1882), and then *the whole partition image* (mindi-bootroot.img 
>> file) *is copied to the mounted partition image* folder via command 
>> 'cp -a $MINDI_TMP/mpt2/images/all.tar.gz 
>> $MINDI_CACHE/*mindi-bootroot.img* $MINDI_TMP/mpt/images' (line 1886).
>>
>> How on earth can partition image fit into itself?
>
> svn diff -r3532:3546 gives indeed the addition of that block, nearly 
> as it is now at the first addition.
> The comment associated with rev 3535 (from 2016) is (and corresponding 
> to the introduction of that block of code
> "Fix the creation of the bootable ISO for UEFI mode (needs kernel and 
> initrd at the root with EFI and images for the boot and restore part) 
> which can be created without making a FS for it BTW"
>
> Now as you mentionned I've done tests with RHEL since that time on 
> UEFI base systems with success, similarly for SLES. I have not done 
> these tests on Debian/Ubuntu by lack of time.
>
> If I try to comment the code (with ###):
>     cp $part $MINDI_CACHE
>     ### We first keep a copy of the boot+root disk created before 
> under MINDI_CACHE
>     ### part=$MINDI_TMP/mindi-bootroot.img previously in mindi
>     if [ "$ARCH" = "ia64" ] || [ "$BOOT_TYPE" = "UEFI" ]; then
>         # Mount again !
>         LogAll "INFO: Re-Mounting $part on $MINDI_TMP/mpt"
>         mount -t vfat $mount_opt $part $MINDI_TMP/mpt 2>> $LOGFILE
>         ### We now remount the file $part so under MINDI_TMP on the 
> mpt mount point also under MINDI_TMP
>         # We just need the EFI dir and the boot image for this case
>         mkdir -p $MINDI_TMP/mpt2 $MINDI_TMP/mpt/images 
> $MINDI_TMP/mpt/archives
>         mount -o loop $MINDI_CACHE/mindi-bootroot.img $MINDI_TMP/mpt2 
> 2>> $LOGFILE
>         ### Here the file we loopback mount is the one under 
> MINDI_CACHE under mpt2
>         # We need again the kernel+initrd at the root for UEFI boot at 
> least
>         cp -a $MINDI_TMP/mpt2/EFI $MINDI_TMP/mpt2/vmlinuz 
> $MINDI_TMP/mpt2/initrd.img $MINDI_TMP/mpt
>         ### we copy content from MINDI_CACHE image on MINDI_TMP image
>         # We need the boot image now and what mindi needs at restore 
> time as well
>         cp -a $MINDI_TMP/mpt2/images/all.tar.gz 
> $MINDI_CACHE/mindi-bootroot.img $MINDI_TMP/mpt/images
>         ### We continue to copy ontent from MINDI_CACHE image on 
> MINDI_TMP image.         ### The MINDI_CACHE/mindi-bootroot.img file 
> has not changed since we created the copy before the if block upper
>         # Avoids graphical tool to keep the FS mounted
>         sync
>         umount $MINDI_TMP/mpt2
>         LogFile "----------- target dir content -----------"
>         LogFile "------------------------------------------"
>         ls -lR $MINDI_TMP/mpt >> $LOGFILE
>         LogFile "------------------------------------------"
>         MakeISO
>     fi
>
> So I think this can work as indeed we are copying content of a loop 
> mounted file on itself but in another copy, because we need it.
> Now, Is that a working mechanism for Debian/Ubuntu is somehitng I have 
> never have time to explore, but would be happy to solve with your help !
> And maybe again we need to increase EXTRA_SPACE in your context, or 
> there is something behaving differently that explains that the copy 
> fails for you.
>
> Hope this clarifies,
> Bruno
> PS: It took me some time to realize that it was working indeed ;-) My 
> first mail was saying you were right !!
>
>
> _______________________________________________
> Mondo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mondo-devel

_______________________________________________
Mondo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mondo-devel