Partition Size Error w/ Raw Download



  • I’m getting an error downloading a Linux Raw image using FOG 1.1.1 on Ubuntu 13.10 with an image of Mint 17. The error says, “Target partition size (40000 MB) is smaller than source (80000 MB). Use option -C to disable size checking (Dangerous).” I have successfully imaged various HD’s using Multiple Partition Image - All Disks, but I would like to be able to use just one image for different HD sizes.

    Is the Raw image type the best choice, and if so, how do I disable size checking?

    [ATTACH=full]1093[/ATTACH]

    [url="/_imported_xf_attachments/1/1093_OptionC.jpg?:"]OptionC.jpg[/url]


  • Senior Developer

    [quote=“Bill G., post: 34965, member: 24757”]WOW! Kudos to everyone who participated in making FOG version 1.2 so quickly. My Linux image has worked flawlessly with various size hard drives. I’m new to the open source community and I’m totally impressed… thank you![/quote]

    Glad we could be of help.



  • WOW! Kudos to everyone who participated in making FOG version 1.2 so quickly. My Linux image has worked flawlessly with various size hard drives. I’m new to the open source community and I’m totally impressed… thank you!


  • Senior Developer

    [quote=“axel12, post: 32603, member: 24592”]Tom, you would be happy to know that while I’m no Linux pro - but I did try everything imaginable under windows. Shrinking, resizing, single disk, raw, multiple disks, VM … etc … I have never been able to deploy a 7 gig image onto a 80Gb hard disk … EVER … (and if anyone can tell me a way to do it - i will send a litecoin your way) … only because my “master build machine” happens to have 150 Gig drive.

    the problem is in the MBR I believe … because no matter how big your image size, your hard disk geometry will not let a computer clone if the source driver is physically bigger than the destination drive. So if you have a 7 gig image on a 500gb drive -> its super hard to image a 80Gb hard disk. The only way I managed to do it - is to deploy the image onto the 80Gig is to take acronis backup - and use “universal restore” … super slow … but acronis backup and restore will mess with the image/disk geometry and figure out a way to put that 7Gig image onto 80gig drive.

    Then I re-capture with fog - and BOOM … there is an image for the lowest common denominator.

    PS For anyone interested, the dell Vostro 1200 series laptops are lairs -> they claim 80Gig hard disks, but in reality, 5 Gigs simply disappears somewhere and you really have 75Gig drive … its not software, its hardware. There is something un-kosher with that whole line of laptops.[/quote]

    axel,

    If you’d be so willing, test using the current svn. It, I assure you, resizes the partition for you for all types of images now, meaning Linux, Windows, and even Multi-boot Win/Linux images. Please try and I think you’ll be pleasantly surprised.


  • Testers

    Ok, I’m testing on revision 2039 at the moment.

    My single partition ext4 system is shrinking and growing perfectly - it now grows to fill the underlying disk geometry.

    I’ve also just tried a system with a few partitions (/boot, / and swap all primary partitions), initially I thought it wasn’t working but it was me being dumb. It worked perfectly.

    It looks like the fill_disk function in /usr/share/fog/lib/partition-funcs.sh allocates any free space according to the ratio of the original partition allocation.
    [CODE]
    (/usr/share/fog/lib/partition-funcs.sh:358)
    partitions[part_device, “newsize”] = (new_variable*p_size/original_variable)
    [/CODE]
    So if in your original image the disk was 20Gb and you allocated a /boot partition with 1Gb and a / as 19Gb then downloading on to a 40Gb disk gives a 2Gb /boot and a 38Gb /.

    I guess this means someone needs to pick a new name for the “Single partition ([B]NTFS Only[/B], Resizeable)” image type. :) I’ll keep testing the various partitioning schemes I use but this is looking really good to me.


  • Testers

    I promised to test the linux resizing then dropped off for a bit :) but I’m testing now and it looks good!

    I have an single root partition on 10G ext4fs. Uploading that to a “Single partition resizeable image”, resize picked it up and shrunk it down. After the system rebooted the root was down to 970Mb (285Mb when compressed in /images).

    On deploy it popped back up to 10G as expected (the underlying disk is actually a 22Gb qcow2 image). I’m going to dig around in the subversion diffs to see if I can follow along and I’ll try out some alternative configs, but this really great work!



  • Tom, you would be happy to know that while I’m no Linux pro - but I did try everything imaginable under windows. Shrinking, resizing, single disk, raw, multiple disks, VM … etc … I have never been able to deploy a 7 gig image onto a 80Gb hard disk … EVER … (and if anyone can tell me a way to do it - i will send a litecoin your way) … only because my “master build machine” happens to have 150 Gig drive.

    the problem is in the MBR I believe … because no matter how big your image size, your hard disk geometry will not let a computer clone if the source driver is physically bigger than the destination drive. So if you have a 7 gig image on a 500gb drive -> its super hard to image a 80Gb hard disk. The only way I managed to do it - is to deploy the image onto the 80Gig is to take acronis backup - and use “universal restore” … super slow … but acronis backup and restore will mess with the image/disk geometry and figure out a way to put that 7Gig image onto 80gig drive.

    Then I re-capture with fog - and BOOM … there is an image for the lowest common denominator.

    PS For anyone interested, the dell Vostro 1200 series laptops are lairs -> they claim 80Gig hard disks, but in reality, 5 Gigs simply disappears somewhere and you really have 75Gig drive … its not software, its hardware. There is something un-kosher with that whole line of laptops.


  • Senior Developer

    I found out that, while my testing “worked” it didn’t truly work. We’re on the right path, but it’s still a work in progress okay?


  • Testers

    I can’t test it today but I’ll give it a go over the weekend. Thanks!


  • Senior Developer

    Starting with SVN 2002, I have added resize2fs and tested both download and upload. It isn’t a very thorough test. It’s a default Ubuntu 12.04 layout for 50GB disk. It shrunk the main ext partition (the only one) from 50gb to 3.4gb. I downloaded and had it expand only ext partitions and it all works if you’re willing to test it out.


  • Senior Developer

    I’m currently testing an upload of my storage node, so it’s not perfectly accurate, but even with all the images on it, it’s gone from 50.5GB to 37.3GB. Have to wait to see if it re-expands.

    Then I’ll test deployment to the same system and see if it at least re-expands properly. I’m lucky in that I have a default Ubuntu install which puts all space, that I’m aware of, on /, but I don’t know how it will work for setup’s where /, /home, /usr are on different partitions.


  • Testers

    I’ve never actually played with the windows resizing - I’ve always just done it manually. I’ll take a look at it before I wander off down the wrong path :)


  • Senior Developer

    Also,

    I think this would be done in a two part rather than per need basis.

    I mean, following a similar process to Windows resizable imaging, the only issue I forsee is backing up the MBR for this, but I imagine the simplest method would be, resize, grab mbr of resized disk, upload image resize back to full size (or original).

    After that, for download, all you’d theoretically need is push MBR back to disk. Download image, resize to full size of disk.


  • Senior Developer

    It’d be very simple if i new the syntax of the resize2fs command. I could man/info/google for it but I’m being lazy for today :D


  • Testers

    I’m interested in seeing this, and Tom’s right, the best place for this would probably be in the init before root filesystem is mounted.

    Something like a checkbox “Expand to fill disk” associated with the Host (or Image) might work, then if the partition table and filesystem support it run, the resize {ext?,xfs,ntfs} tools after the initial deploy. I’ll try to make a patch if I get time.


  • Senior Developer

    resize2fs is a native part of the init as well. I just haven’t had any time to add resizing components for linux installs. If anybody has a patch system that may work for this, please let me know. I’d love to include, but do not have enough time to implement and test all by myself.


  • Testers

    Out of interest I gave this a shot, this worked for me
    [CODE]
    $ parted /dev/sda
    (parted) resizepart
    Partition number? 1
    Warning: Partition /dev/sda1 is being used. Are you sure you want to continue?
    Yes/No? yes
    End? [51.2GB]? 100%
    (parted) quit

    $ resize2fs /dev/sda1
    [/CODE]
    I wouldn’t suggest this as a good idea on a working system, but since you already have your deploy image in fog, don’t worry about messing up the partition table/filesystem. If you make a mistake, you can just redeploy!

    A google search for “ubutnu first boot script” or something similar should give instructions on how to do this on the first reboot.

    EDIT I chose to do this with “resizepart” rather than “resize” because “resize” will cause parted to try to resize the filesystem itself, I think this is better left to native tools like resize2fs!


  • Testers

    [quote=“Bill G., post: 31996, member: 24757”]Thanks for the info… I created a new Raw image on a 40GB HD and deployed the image to a 80GB HD. It created a 40GB partition for the OS and an additional 40GB of “Free Space.” How do I automatically take advantage of all of the HD space, i.e., one 80GB partition?[/quote]

    It will depend on the filesystems that you have chosen, but with ext4 as an example, you could write a script to update the partition table with parted and then resize the filesystem with e2fsprogs. You could set this script to run at the next reboot in your image (most distributions have a facility for this already). The complexity of the script would grow quickly depending on your partition layout but if you just have a single root partition it shouldn’t be too difficult.

    I would start by booting one of your images and trying to do it manually on the command line. Once you have a sequence that works, make a script and start testing/debugging.

    I’ve wondered about doing this as a special type of deploy in fog, but there are so many variations (different filesystems etc.) that it would probably be hard.


  • Senior Developer

    [quote=“Bill G., post: 31860, member: 24757”]I’m getting an error downloading a Linux Raw image using FOG 1.1.1 on Ubuntu 13.10 with an image of Mint 17. The error says, “Target partition size (40000 MB) is smaller than source (80000 MB). Use option -C to disable size checking (Dangerous).” I have successfully imaged various HD’s using Multiple Partition Image - All Disks, but I would like to be able to use just one image for different HD sizes.

    Is the Raw image type the best choice, and if so, how do I disable size checking?

    [ATTACH=full]1093[/ATTACH][/quote]

    If this is a Windows 7 image, then why not use the Single Disk (Resizable)? It shrinks the volume to the smallest possible +5% that the disk can be shrunk. This option is suitable for exactly what you’re trying to accomplish. Is there a reason you’re using RAW for the image type?


  • Developer

    [quote=“Bill G., post: 32041, member: 24757”]Will do… thanks![/quote]

    and of course whatever you learn come back and share with the class!


Log in to reply
 

742
Online

38975
Users

10712
Topics

101675
Posts

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