Announcement

**oshunluvr** · Aug 15, 2023, 02:23 PM

- boot to USB
- fsarchiver save the root partition
- use gparted to delete sda2
- use gparted to extend sda1 into the space
- fsarchiver restore into sda1
- reboot

Anything dumb about this plan? Better ways to do it?

I'm not familiar with "fsarchiver" but assuming it's capable of restoring to a larger partition than the source then seems like an OK plan. Buy why not clone the data from sda2 into sda1, swap the UUIDs and have sda2 as "unused". No re-partitioning required and sda2 becomes an instant backup of your install. Once you're satisfied that sda1 boots, you could then merge sda2 and sda3 and have a larger /home. IMO 40G is plenty large enough for a full Kubuntu install. I have a TON of stuff installed on my 6 year old Kubuntu (KDEneon actually) and I'm at 27G.

I'm assuming you have a backup for /home and will restore that after expanding? Is it going onto /the new larger sda1 rather than staying separate or going somewhere else? Remember to set the UUIDs and/or edit fstab to find your new home location before booting.

Depending on how big your /home is, it might just fit into sda5.

This would result in sda1 and sda3, 4, 5, but no sda2... is that a problem for any reason?

Not with regards to disk access, but you might consider converting to GPT partitioning during this process. or doing away with the Extended partition and remaking sda4 into the "general storage" partition. With this small of a drive, you likely won't want more than 4 partitions anyway. Not that it's needed, but you can renumber partitions.

AFAIK fsarchiver will keep the same uuid for the / partition, which also means grub won't get confused about how to boot... sound correct?

Yes, this should be true, but be prepared to recover grub if necessary. This just means having a bootable Kubuntu USB thumb drive.

Other questions and ideas:

If you used a BTRFS instead of EXT4 one could combine ALL the partitions and use subvolumes to segregate the space. sda1 with @, @home, and @storage. If you're not familiar with BTRFS, there's lots of post on this forum about it (mostly by me, lol).

An old school way to expand would be to move /var to another partition instead of mucking about with partitions. You could make sda1 general storage or home, move /var to sda5, adjust your fstab, and be good to go.

**chconnor** · Aug 15, 2023, 04:52 PM

Originally posted by oshunluvr View Post

Buy why not clone the data from sda2 into sda1, swap the UUIDs and have sda2 as "unused". No re-partitioning required and sda2 becomes an instant backup of your install. Once you're satisfied that sda1 boots, you could then merge sda2 and sda3 and have a larger /home.

Ah, that's a much better idea, thanks! I have lots of directories symlinked of /home and / to other drives in an effort to keep things under the small partition sizes, and the result of that is 7GB free on /home but always running up against the limit on / (ran out recently during an update, provoking these changes), so my attitude was "heck I'm just going to grow / so I don't run in to this anymore", but yeah, 40GB for root and 45GB /home sounds like a better setup, and then I don't have to faff about symlinking stuff off of /home either.

I'm assuming you have a backup for /home and will restore that after expanding?

Under the plan in my original post the idea was to keep it where it was -- no changes. It would live on sda3, same UUID, etc. sda1 and sda2 would be merged into sda1 with the uuid from sda2. Does that track?

But yeah under the new/better plan I would clone to sda1, change UUIDs, confirm booting, then clone /home to sda2, change UUIDs, confirm everything OK, then delete sda3 and expand sda2 into sda3 space.

Thanks for the GPT and btrfs mentions -- I know they are better but I don't have the time to properly learn them yet... thus far, every time I have waded into those waters I end up confused and things go wrong. :-)

Appreciate the response!

**jlittle** · Aug 16, 2023, 03:51 PM

Originally posted by chconnor View Post

... I have lots of directories symlinked of /home and / to other drives in an effort to keep things under the small partition sizes ... but always running up against the limit on / ...
Thanks for the GPT and btrfs mentions --

I left most of that juggling behind by using btrfs, it's a distant memory now. A huge time saver. The btrfs learning curve is not long to get started.

**chconnor** · Aug 23, 2023, 02:28 PM

Update!

I booted into the USB, used fsarchiver to make an image of root (/dev/sda2) and restored it to /dev/sda1. (There are probably better ways but I'm familiar with fsarchiver and it has worked in the past for this.)

Everything seemed in order. I changed the UUIDs so that /dev/sda1 had the old root partition UUID (and changed /dev/sda2 to a different UUID).

Here's the weird stuff: I reboot to the grub screen and use "e" to edit the grub entry for the main boot entry. I change the "hd0,msdos2" instances to "hd0,msdos1" just in case it doesn't find the UUID (I'm not totally clear on how grub finds the partitions...)

It boots, but only maybe 1/3 times. Other times it crashes into emergency mode with various kernel warnings. It also always boots slowly: after hanging for about a minute a line about snd_hda_intel "requires binding with gfx driver" appears. It's clearly not a clean normal boot even when it works.

Once booted, everything seems fine... I confirm that I'm booted off of sda1 -- I am. It boots to /dev/sda1 whether or not I make those "msdos1" changes in the grub entry on boot -- perhaps just because it's finding the UUID... Once booted, I run update-grub, which seems to work fine -- os-prober finds the old /dev/sda2 install as well. I see that /boot/grub/grub.cfg looks appropriate. The main Ubuntu entry in /boot/grub/grub.cfg has hd0,msdos1 as expected (and expected UUID). However on reboot, the old grub screen is always present -- it never seems to actually get updated.

So I have changed the UUIDs back and I'm booting to /dev/sda2 again, and it boots fast, no errors, no problems.

Any thoughts? Better ways to do this? I'm confused why grub isn't actually getting updated...

**oshunluvr** · Aug 23, 2023, 03:34 PM

Probably need to re-install grub. So boot into sda1, then run "sudo grub-install /dev/sda" then "sudo update-grub" and try again.

Here's what I suspect is happening: Grub (without UEFI) has 3 stages. the drive - sda - holds the first stage. Stage 2 is in the partition header and stage 3 is in /boot/grub. So when you boot, sda moves to sda2, then back to sda1. (BTW this is a very loose description of how this works). This is likely why grub is not being updated as you would hope.

As far as the sound card driver not loading - that seems odd and not related to grub. Obviously grub has no sound. Maybe the file copy mucked something. Possibly an apt update-upgrade will fix it. If not, there might be some trouble shooting coming up.

**chconnor** · Aug 23, 2023, 06:29 PM

Thanks! That fixed grub (although it now uses a much lower res graphics mode for some reason).

Given the sound card oddities, is there a better way to clone to sda1 that you would recommend? Maybe I can try that to see if it helps...

Edit: oh, looks like you can "copy"/"paste" in gparted... ?

Edit2: or just:

Code:

# dd if=/dev/sda2 of=/dev/sda1
# resize2fs /dev/sda1

?

**chconnor** · Aug 23, 2023, 09:08 PM

Cloned with dd (and following resize2fs) and that worked! No problem on booting now. (A little sobering considering that fsarchiver is my main backup solution.)

Now on to moving/resizing /home... it's encrypted but I don't expect that will be an issue, yeah?

**oshunluvr** · Aug 24, 2023, 07:04 AM

dd and resizefs are old tools but still around - which mean they're very useful, as you discovered, lol. The simplest method is the best - "Occam's Razor" and all that.

I would think that encryption would be a very large issue.Preventing things like this is why encryption was invented I think.

If it were me, I would:

Make an un-encrypted backup of all the files in home (don't forget the hidden files and folders).
Delete sda2 and sda3
Make the new sda2 with all the space
Restore the home files on the new sda2
Re-encrypt sda2

This way you have an accessible backup in case something goes wrong. Once you have verified all is well, then encrypt the backup or securely delete it.

If you make the backup first, there's no reason not to attempt something else just to see whats works. Learning is always a good thing. Just make sure your backup is 100% good before anything else.

**chconnor** · Aug 24, 2023, 12:01 PM

Thanks! What if I were to boot to USB, dd clone sda3 into sda2, change UUIDs, resize2fs, and see if it "just works"? Worst case I could just change the UUIDs back, right?

...and once it's verified working then I boot to USB again and delete sda3 and expand sda2 into that space?

Maybe I'm just drunk on power since the dd/resize2fs method worked so well for /... :-) Is there some reason the encryption would know that it wasn't on the same drive? Or some state in / is going to get botched and then I'm stuck?

**oshunluvr** · Aug 25, 2023, 06:19 AM

LOL, sounds like a plan

**chconnor** · Aug 25, 2023, 08:28 PM

Oh no, now I'm concerned that I made you LOL... :-) I was trying to be conservative and safe with it -- is there something risky with my plan?

**oshunluvr** · Aug 26, 2023, 07:40 AM

No, it was the "drunk with power" comment.

Feel the force, young padawan!

**chconnor** · Aug 26, 2023, 10:39 AM

Phew. I'll give it a shot. (And I will do, not try, because there is no try. :-) )

**chconnor** · Aug 27, 2023, 11:50 AM

Worked like a charm! Nice to have all the space back. Thanks for the guidance!

Announcement

Merging root partition into another...

Merging root partition into another...

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment