Hello Lubuntu community. First off - I love Lubuntu - great work! Lubuntu is my first experience with Linux and I have to say it has been a great experience.
I have a question about the amount of ‘Unused’ space left over after installing Lubuntu 22.04 on my VirtualBox (VirtualBox version 6.1.34 r150636). After a default installation of Lubuntu onto 15GB of VirtualBox disk, I see 6.34GB of used space and 1.86GB of Unused space. GParted won’t let me shrink/eliminate this Unused space. I was curious if this nearly 2GB of unused space was important, so I created a 7GB image file with fallocate and copied data from the larger to this new smaller image with rsync and this smaller image still booted up fine and everything seemed to work as before with less Unused space. So my question is - why does the Lubuntu installer leave 1.86GB of Unused space after a default Lubuntu installation? That’s 23% (1.86/8.2) of the total image size. Both GParted and pishrink (GitHub - Drewsif/PiShrink: Make your pi images smaller!) are unable to eliminate this Unused space and therefore the resultant image file is larger. Both tools use ‘resize2fs -P’ to calculate the minimum image size. Any insight appreciated! Screenshots follow:
It looks like it should let you resize it if you just drag that handle on the right side over into the empty space.
There’s no reason that empty space should be being made - my guess is you probably used Manual Partitioning and may have configured things differently than how you intended. I do usually notice a few megabytes of unused space at the end of the drive that can’t seem to be filled for some reason, but multiple gigabytes? Something’s gone awry.
Lubuntu has always used the expected disk space for me, and thus I’d assume it was something you did during install.
I do note in your provide picture you have sda1 mounted as /mnt, thus to protect it’s data, you won’t be able to increase it’s size whilst mounted. Dismount the drive to expand it.
I repeated the problem again by following these steps:
Run Lubuntu 22.04 Installer within a new 10GB instance of VirtualBox
Choose New York Timezone
Default Keyboard
Choose ‘Erase disk’ to overwrite whatever used to be on the VirtualBox hard drive
Choose username, password and ‘Log in automatically’
Click Install
Wait for install to finish
Uncheck ‘Restart Now’ and click ‘Done’
Install gparted by running ‘sudo apt-get install gparted’
Within gparted, minimize the disk as much as possible by:
right-click on primary partition and choose ‘Resize/Move’
drag slider to left as much as possible to resize the disk to minimum. In the 1st screenshot below, this is 8386 MiB
click Resize
click the checkmark, then Apply
wait for operation to finish.
close gparted
Within terminal, mount the newly installed and shrunk partition /dev/sda1 by running the command
sudo mount -s /dev/sda1 /mnt
Reopen gparted
At this point you should see the 2nd screenshot below that shows 6.34GB Used space, 1.85GB Unused space and 1.81 unallocated space. I’m not sure how to get rid of this unused space. This 1.85GB unused space is only visible when /dev/sda1 is mounted.
After an installation, I’d not try and change the installed partition until after a reboot. I’ve noted issues before; as the calamares installer assumes you’ll reboot post-installation, and whilst the system is fine for continued use, you should avoid using the newly installed system until after boot (there are bug(s) on this occurring, not achieved thru the same situation but I suspect same cause, but a simple reboot post-install resolves the issue).
Rather than installing gparted (a GTK apps that’s inefficient on a Qt5 desktop), I’ll suggest using KDE Partition Manager instead as it’s already installed (and more RAM efficient), but do note, it’ll likely have the same issue unless you reboot after completing the install, or flush all cached disk buffers and re-read disk at a minimum so what is on the disk & what is in RAM match (achieved easiest by reboot as is assumed post-install).
I’m just guessing here, but methinks virtualbox uses the VMDK file format which stores the partition as 2GB files. Thus the 2GB boundary.
I am curious, if you want to shrink the partition so that it has no more space left after it, then how are you supposed to run the OS if it later needs space to create additional files ?
Thanks for the quick responses. I repeated my test using the recommendations of guiverc. The steps I followed and results are below. The steps that are different from my last post are in bold.
Run Lubuntu 22.04 Installer within a new 10GB instance of VirtualBox
Choose New York Timezone
Default Keyboard
Choose ‘Erase disk’ to overwrite whatever used to be on the VirtualBox hard drive
Choose username, password and ‘Log in automatically’
Click Install
Wait for install to finish
**- Click ‘Done’ to shutdown the VirtualBox instance (ie. do not uncheck ‘Restart now’)
After VirtualBox has shutdown, ensure Lubuntu 22.04 installer boots up again. This is required so /dev/sda1 can be resized while unmounted.
Opened KDE Partition Manager to resize /dev/sda1.
Right click on sda1 and choose ‘Resize/Move’
Drag sda1 down to the left as far as possible, which is 6.37GiB. I included a screenshot of this below. This is a good size as it would not include any ‘Unused’ memory.
Click OK, Apply, and Apply Pending Operations (this will shrink /dev/sda1 from 10 GiB to 6.37 GiB)**
Unfortunately the resize operation fails. When I click ‘Details’ I see the e2fsck command succeeded, but the ‘resize2fs /dev/sda1 13363200s’ command failed. There is no description on why the resize2fs command failed, so I copied and pasted this command into a Linux terminal and got the following output:
lubuntu@lubuntu:~$ sudo resize2fs /dev/sda1 13363200s
resize2fs 1.46.5 (30-Dec-2021)
resize2fs: New size smaller than minimum (2146687)
lubuntu@lubuntu:~$ sudo resize2fs -P /dev/sda1
resize2fs 1.46.5 (30-Dec-2021)
Estimated minimum size of the filesystem: 2146687
It appears that KDE Partition Manager tries to use resize2fs to shrink /dev/sda1 beyond what it considers the minimum size of the filesystem, so it fails.
After I did everything above I also verified that GParted behaves similar to before - it can’t shrink /dev/sda1 below 8386 MiB. So this still a problem despite the extra reboot
I am curious, if you want to shrink the partition so that it has no more space left after it, then how are you supposed to run the OS if it later needs space to create additional files?
We’re using pishrink on our final image file to shrink the image file to be as small as possible. pishrink also modifies the image file so that early on first boot the partition is resized to fill the entire capacity of the storage medium.
Thanks for the suggestion @humpty. When I select ‘Manual partitioning’ rather than ‘Erase disk’ the same problem described above still occurs unfortunately.
For reference, the manual partitioning scheme I used is illustrated with the gparted screenshot below. I use a GPT partition table with a 8 MB partition that has the bios_grub flag as suggested by the installer. As you can see, 1.85GB of unused space still exists and cannot be shrunk with a resize operation.
In that case, I can only suggest that you manual partition to 6.34GB or 6.37GB -before- installing.
I read that VB defaults to a BIOS boot so I don’t think you need that extra EFI partition or GPT stuff. VB already starts you off with a partition table (right?).
I don’t think that will work - If I remember (and understand) correctly, Lubuntu requires 8 GB of disk space to be willing to install to a partition. If you’re willing to tweak the installer configuration files, you could probably bypass that, but considering how cramped even 8 GB is, I find it hard to imagine a system even being usable with less.
When I manually partition the image within the installer and only assign 7.07GB to the main partition then I successfully reduce the ‘Unused’ memory from 1.85 GiB to 0.73 GiB as shown in the GParted screenshot below. I verified the image boots & functions normally.
I also tried to make the main partition 6.5 GB but then the Lubuntu installer failed part way through.
So assigning less space to the main partition reduces the amount of ‘unused’ space. It would be nice if this was automatic though - ie. the smallest size of the partition was calculated rather than guessed by me.
You need space on the system as you need to upgrade packages (they need space to download in, be expanded and installed, leaving you briefly with both old + new, then the older packages are removed returning some of the used space), as well as some programs need space just for them to work.
The sizes you mention make no sense to me if the installation is going to be used; they’re too small. Sure the system may boot & work after initial install; but if you’ve not left any space, the system will fail to work soon enough, especially if you let upgrades accrue & then don’t have enough free space in order to download, install etc. I mentioned before.
During installation a squashfs gets written to your drive, this includes a lot of packages, and can include some that get removed late in the installation process. Lubuntu currently doesn’t offer a minimal installation option; but for those that do the process is the same; everything gets installed then if minimal install option was used a list of packages is removed from the installed system, ie. the installer needs more space than what is left with the final product, but users need free disk space into the future just for their upgrades even if they’re not going to install any additional apps.
If you don’t want an actual installation (which needs unused disk space, at least that’s my opinion) why not use live (with/without persistence). Updated ISOs (dailies) are still created for focal so it can be refreshed rather regularly if required.
Sorry, what you’re seeking help for to me at least, just seems counter-productive, and is just creating problems for end-users. Support sites regularly get questions left by users who’ve created too small a partition for their installs & can no longer apply normal upgrades and complain about a broken system, which at least to me, is what you’re trying to create.
guiverc is just expressing my original question as to why you only want the minimum install size.
As you have explained, somehow there is a virtualbox feature that you can use in the future to auto-expand the partition (I assume it has something to do with it being a dynamic vdi). I’m guessing you want to keep this minimum size for storage or distribution.
I do agree with guiverc in that the installer needs some room to do the install-operations, that’s probably why it failed at 6.5GB.
You have to be careful with resizing virtual images. What gparted sees may be different to what VB sees, so as you probably have searched by now, you know that any changes have to be done in tandem. From what I can gather, increasing the size is easier than decreasing it.
I doubt if it’s resize2fs ‘Known Bug’, afaik, the default blk size is 4k.
However, it is curious as to how gparted or any other PM deals with virtual disks. Notice this…?
I have never seen that symbol before in gparted.
It tells me that gparted knows it’s not a regular disk. But it’s a mystery as to how gparted treats it.
Hi Humpty and Guiverc. Thanks for your help and suggestions. Yes you’re right Humpty we try to make our image as small as possible for storage & distribution. Before we store our image, we use pishrink (GitHub - Drewsif/PiShrink: Make your pi images smaller!) on our image file which modifies the image file so that early on first boot the partition is resized to fill the entire capacity of the storage medium. It does this with a /etc/rc.local script that calls fdisk and resize2fs commands.
Yesterday I ran the ‘zerofree’ program on our main partition, and it allowed us to reduce the compressed (gzip) image file size from 1.5GB to 1.3GB. Zero free is documented here - Ubuntu Manpage: zerofree — zero free blocks from ext2, ext3 and ext4 file-systems. As documented on that webpage, zerofree “finds the unallocated, blocks with non-zero value content in an ext2, ext3 or ext4 filesystem (e.g. /dev/hda1) and fills them with zeroes”. This seems to minimize the impact of having extra unused space in our Lubuntu image since it appears that the zerofree program makes this unused space very compressible.
