Partition Size Error w/ Raw Download
-
[quote=“Jaymes Driver, post: 31999, member: 3582”]My recommendation is gParted. In windows it’s as simple as editing the partition and telling it to expand the space. There are ways to do it with commands, but gParted is a GUI and a Live CD.[/quote]
We image hundreds of computers during a year and I’m looking for a way to automate the expansion during imaging. I’ve used gParted before, but I want students – who will be imaging these computers – to have as few steps as possible. Thanks for your reply.
-
[quote=“Bill G., post: 32037, member: 24757”]We image hundreds of computers during a year and I’m looking for a way to automate the expansion during imaging. I’ve used gParted before, but I want students – who will be imaging these computers – to have as few steps as possible. Thanks for your reply.[/quote]
I understand that! There are deffinately commands out there to complete the task, however I have never ventured into this territory, it might be wise to look in some linux imaging forums for a command that would complete the task for you
-
[quote=“Jaymes Driver, post: 32040, member: 3582”]I understand that! There are deffinately commands out there to complete the task, however I have never ventured into this territory, it might be wise to look in some linux imaging forums for a command that would complete the task for you :)[/quote]
Will do… thanks!
-
[quote=“Bill G., post: 32041, member: 24757”]Will do… thanks![/quote]
and of course whatever you learn come back and share with the class!
-
[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?
-
[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.
-
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!
-
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.
-
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.
-
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
-
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.
-
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
-
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.
-
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.
-
I can’t test it today but I’ll give it a go over the weekend. Thanks!
-
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?
-
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.
-
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!
-
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. -
[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.
