Partition Size Error w/ Raw Download
-
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.
-
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=“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.
