EBR signature for logical partition invalid


  • Developer

    I’m using a fresh install of FOG 1.0.1, on ubuntu 14.04 server.

    I’ve been able to capture and download images (linux, single disk, multiple partitions) from one machine and restore on another machine with a completely blank disk. The installation has linux on 2 logical partitions (5,6).

    I’m able to capture a image with windows 7 and linux (linux, single disk, multiple partitions). Windows 7 creates 2 primary partitions (1,2), linux is in 2 logical partitions (5,6). When I try to restore this image to a new machine with a blank disk, I get ‘EBR signature for logical partition invalid’, during the ‘Erasing current MBR/GPT Tables’. Then, then restore continues, saying it will ‘Restore Linux swap partitions’ with a warning message ‘invalid flag 0x0000 of partition table 5 will be corrected by w(rite)’. Finally, the download ends without actually copying any partition data, and reboots the target system.

    Repeated attempts on the same disk to not produce any better results.

    If I restore the image to the original disk, the restoration occurs, and all data is copied.

    I’ve attached a screen shot of the errors.

    [ATTACH=full]798[/ATTACH]

    Is there something I could do differently to make sure that the partition table is restored correctly?
    Thanks.

    [url="/_imported_xf_attachments/0/798_fog-download-error.jpg?:"]fog-download-error.jpg[/url]


  • Senior Developer

    [quote=“Uncle Frank, post: 40923, member: 28116”]I can confirm fractal13’s findings and I am pretty sure it’s still an issue in current SVN (r2908).

    Our setup is kind of similar having Windows 7 AND logical partions.

    sda1: primary NTFS Windows 7 (100 MB boot partition)
    sda2: primary NTFS Windows 7 (C: partition)
    sda3: extended partition
    sda5: logical NTFS (D: data)
    sda6: logical NTFS (E: ubuntu in an image file using WUBI)

    Kind of a weird partition layout I know but it’s what we got right now… As we use WUBI we don’t have GRUB installed right on disk! So I don’t need to worry about that and therefore choose OSID 5 (we run Linux yes but from FOG’s point of view it looks like Windows only).

    I fixed the problem for us with this very simple change in fog.upload:
    [CODE]— src/buildroot/package/fog/scripts/bin/fog.upload (Revision 2908)
    +++ src/buildroot/package/fog/scripts/bin/fog.upload (Arbeitskopie)
    @@ -239,7 +239,7 @@
    fi
    elif [ “$imgType” == “mps” ]; then
    hasgpt=hasGPT $hd;

    •        if [ "$hasgpt" == "0" -a "$osid" == "50" ]; then
      
    •        if [ "$hasgpt" == "0" ]; then
                have_extended_partition=`sfdisk -l $hd 2>/dev/null | egrep "^${hd}.*  (Extended|W95 Ext'd \(LBA\))$" | wc -l`;
            else
                have_extended_partition="0";
      

    [/CODE]

    Although I have to admit that I CANNOT test if this is working for everyone else (other Windows or Mac OS X) I wonder why extended/logical partitions should only work with Linux (OSID 50)??

    Would be great if others could test this “fix” and provide information if this works in their environment.

    Thank you![/quote]

    Thanks for reporting.

    Your patch has been added and hopefully will work for yours and others items.


  • Senior Developer

    That’s not a problem in SVN, but the problem you’re describing should work with the fix you have given here. I’ll add that. 2908 will still remain the svn, all you’ll have to do is re-run the installer.

    Give me about 10 - 20 minutes and we should be good. 2909 will be out to contain the source file update though.


  • Developer

    I can confirm fractal13’s findings and I am pretty sure it’s still an issue in current SVN (r2908).

    Our setup is kind of similar having Windows 7 AND logical partions.

    sda1: primary NTFS Windows 7 (100 MB boot partition)
    sda2: primary NTFS Windows 7 (C: partition)
    sda3: extended partition
    sda5: logical NTFS (D: data)
    sda6: logical NTFS (E: ubuntu in an image file using WUBI)

    Kind of a weird partition layout I know but it’s what we got right now… As we use WUBI we don’t have GRUB installed right on disk! So I don’t need to worry about that and therefore choose OSID 5 (we run Linux yes but from FOG’s point of view it looks like Windows only).

    I fixed the problem for us with this very simple change in fog.upload:
    [CODE]— src/buildroot/package/fog/scripts/bin/fog.upload (Revision 2908)
    +++ src/buildroot/package/fog/scripts/bin/fog.upload (Arbeitskopie)
    @@ -239,7 +239,7 @@
    fi
    elif [ “$imgType” == “mps” ]; then
    hasgpt=hasGPT $hd;

    •        if [ "$hasgpt" == "0" -a "$osid" == "50" ]; then
      
    •        if [ "$hasgpt" == "0" ]; then
                have_extended_partition=`sfdisk -l $hd 2>/dev/null | egrep "^${hd}.*  (Extended|W95 Ext'd \(LBA\))$" | wc -l`;
            else
                have_extended_partition="0";
      

    [/CODE]

    Although I have to admit that I CANNOT test if this is working for everyone else (other Windows or Mac OS X) I wonder why extended/logical partitions should only work with Linux (OSID 50)??

    Would be great if others could test this “fix” and provide information if this works in their environment.

    Thank you!



  • Thank you.


  • Senior Developer

    I believe your findings are absolutely correct.

    I don’t know how to maintain the logical partitions properly.

    I hope that helps even if it’s very short info.

    BTW, Thank you so much for details and trying to narrow down a problem

    The theory of grub2 support should be correct, though I had now real means to test. So if it’s working for you, AWESOME!


  • Developer

    I have completed more tests.

    Host configuration 1:
    Dual boot, Windows 7 and Ubuntu 14.04
    Grub2, MBR
    Primary partition 1: Windows 7 (100 MB)
    Primary partition 2: Windows 7 (C: drive)
    Extended partition 3:
    Logical partition 5: Linux (/ in ext4)
    Logical partition 6: Linux (swap)

    System upload works fine. Results in the following files:
    d1.mbr (32256 bytes)
    d1p1.img
    d1p2.img
    d1p3.img (133 bytes)
    d1p5.img
    d1p6.img

    System download fails as shown in the image above.

    Host configuration 2:
    Dual boot, Windows 7 and Ubuntu 14.04
    Grub2, MBR
    Primary partition 1: Windows 7 (100 MB)
    Primary partition 2: Windows 7 (C: drive)
    Primary partition 3: Linux (/ in ext4)
    Primary partition 4: Linux (swap)
    System upload works fine. Results in the following files:
    d1.mbr (32256 bytes)
    d1p1.img
    d1p2.img
    d1p3.img
    d1p4.img
    System download works fine to a blank disk system.
    System boots fine into Windows 7 and Ubuntu 14.04.
    My conclusions:

    • grub2 now appears to be supported (assuming it all fits into the 32K at the front of the disk)
    • ext4 now appears to be supported (the move to partclone looks good)
    • extended/logical partitions are still not supported.
      [I][B]I would love to hear one of the fine developers confirm that my 3 conclusions are as intended by the development team.[/B][/I]
      [U][B][I]Thanks for all of your work in producing, maintaining, and updating this software. It passes my criteria for great software: it makes my life better.[/I][/B][/U]

  • Developer

    In reading fog.download, I see the ‘EBR …’ message comes from the sgdisk -Z command. Reading the source code for sgdisk suggests that this is not a problem. The empty disk has no partition table to delete, and the error messages don’t stop sgdisk.

    Continuing in fog.download, my d1.mbr file is 32256 bytes, so the dd should send it to the disk. Examining the blank disk indicates that the MBR data was actually written. Booting the system with the almost empty disk from a rescue image shows the 2 primary partitions for windows, and the extended partition exists. But the logical partitions inside of the extended partition don’t exist. sfdisk -l and fdisk -l both complain about the extended partition’s lack of a valid signature or flag.

    Continuing through fog.download, it appears that fogpartinfo --list-parts is not returning the list of partitions as desired. Likely because the logical partitions don’t exist properly? Reading source for fogpartinfo and libparted, I don’t understand why the non-logical partitions aren’t returned at least, but they aren’t processed in the fog.download for loop.

    Finally, in trying to find the swap partition to restore, fog.download calls fdisk -l, which produces the Warning message in the image posted.

    OK, is it true that I am having problems because of using logical partitions? If so, is there a way to use them correctly, or do I need to eliminate them?

    Thanks.


Log in to reply
 

364
Online

38982
Users

10712
Topics

101678
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.