After what seems to have been a backend change to the Mariadb database structure, I had two log files (Webtrees and Nextcloud) that grew to max out the space on my / partition. To get around the problem, I truncated both log files and updated the offending fields in the Mariadb. My / partition is currently showing 22GB used with the partition allocated with 25GB. To avert this from happening again, I would like to allocate more space to the / partition.
The drive space is allocated as follows:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 90.4G 0 disk
├─sda1 8:1 0 25G 0 part /
├─sda2 8:2 0 10G 0 part [SWAP]
└─sda3 8:3 0 55.3G 0 part /home
My objective is to shrink /home by 10GB, used the freed up 10GB to allocate a new swap and then after deleting the old swap, add it to the existing / partition.
As the machine is running as a VM, I have cloned the machine to test that my objective will work.
On the cloned machine, I booted with the Gparted Live DVD and proceeded to make the changes. The partitions now register as:
sda 8:0 0 90.4G 0 disk
├─sda1 8:1 0 35G 0 part /
├─sda2 8:2 0 9.8G 0 part [SWAP]
└─sda3 8:3 0 45.6G 0 part /home
As the swap UUID had changed due to the deleting and recreation of the new swap area, I updated the UUID for swap in fstab.
Despite it appearing that the reallocations have worked, when I attempt the boot of the clone, I can see the three dots on the screen and the boot continues until the third dot is highlighted at which point the VM hangs. There is no disk activity indicated by the VM and waiting as long as half an hour the machine is still on this screen.
What have I missed or is there a way to see what is causing the hang?
Thanks Alessio - I had not tried the ESC - it does provide info but if I am reading it correctly it looks like it’s accessing a different UUID than the / partition - see below.
I am guessing that the UUID causing the hang is the old swap partiton.
Did you run mkswap on that new partition?
I am not sure why you shot yourself in the foot here.
You could have used gparted and relocated that partition without changing the original UUID.
It probably has the old UUID in the initramfs image and that may require using a live image to boot, swap to the installed OS with chroot, then run dracut --force --kver <your boot kernel here>
to recreate the initramfs image after ensuring the new device is active as swap with swapon
Yes, I know the os is a VM running under vbox and that does complicate things a bit.
Thanks Jeff V for the suggestions. I was under the impression that the UUID only remained the same if the additional space was added to the end of the file. Will have to look into how to do this when I’m ready to this exercise on the “live” system. “Swapon” did show the new swap partition.
I used the command “chroot /mnt/sysroot” which I thought would be the installed OS in the VM. When I did the “ls” command, it did show me the files in the VM / partition. I then tried the dracut command but got the message that “–kern” was ambigious and that I needed to use one of “–kernel-only”, “–kernel-cmdline” or “–kernel-image”. I changed the command to use “–kernel-image” however it returned the message that the kernel 6.8.5 was not located in /lib/modules. However the kernel I had specified on the dracut command was 6.8.8, i.e.
“dracut --force --kernel-image 6.8.8-200.fc39.x86_64”.
I suspect my error is with the chroot command that I used.
Gparted is a very versatile tool. You can move or shrink partitions that are not mounted and not change the UUID. You can enlarge some partitions even while mounted with some commands but gparted does the fail safe and forces the file system to be not mounted.
gparted also manages the relocation the content if necessary and manages the file system formatting in the new area as well. Very seldom are there problems with the file system after using gparted on a partition.
Note that I had a typo with this command when I posted it above.
This is the proper command and I corrected it above as well. The --force causes it to proceed even if there is already an image there.
From the man page for dracut
A shortcut to generate the image at the default location for a specific kernel version is:
# dracut --kver 2.6.40-1.rc5.f20
The kernel version must be in the format given by the uname -r command and must be for an installed kernel. If you do not use the --kver option it will attempt to create an initramfs for the kernel used to boot and as you found out the initial kernel for f40 on the live image is quite some versions back.
Don’t forget that the swap partition UUID can also be referred to by the kernel command line. When booting, hit the “e” key at the grub menu, and if you see a “resume=” option, delete that option and continue booting by hitting “x”.
If successful, edit /etc/default/grub to fix the UUID and run
Thank you Jeff V and Villy Kruse. I used the updated dracut syntax provided by Jeff V and that has addressed the problem. I will make note of Villy’s suggestion as well and add it to my toolbox should I encounter this situation in the future.
