I’m finding conflicting information on the internet, and I can’t find anything related to partitions in the kinoite docs.
I’ve ran into some issues with kinoite that are most easily solved by simply installing another distro alongside it. Ideally this would be done on another disk, but I don’t have that luxury, so on the same drive it goes.
On windows it would have been a simple shrink and done. But does this work the same with btrfs ? I’m reading that only the btrfs filesystem can be shrunk live not the partition ? And that once in the other distro installer, if I shrink the partition too much it will brick the btrfs even if I have plenty of space ? Is this accurate ? This seems a bit confusing.
I believe that what you read is correct even if a bit confusing.
Shrink the btrfs file system, then shrink the partition.
The warning and potential hazard is that if the partition is made smaller than the new file system size then it causes problems
My suggestion – FWIW – is to shrink the file system to smaller than you expect to make the new partition size so it allows room for errors. Then after shrinking the partition it can be expanded to completely fill the new partition size. This avoids bricking the btrfs file system which can happen by cutting off the end when trying to do 2 different operations.
Calculations of FS size and partition size may be off a bit and the need is to avoid the potential errors.
You can shrink the filesystem live but you cannot do this with the partition, instead do it from a Live system.
Make sure you have a solid backup as the operation is risky.
You can resize the file system and partition using Kde Partition Manager. This will make sure that you don’t shrink the partition without also shrinking the btrfs file system. The btrfs file system can be resized while being online.
You can also use a live system for example the xfce spin. This live system comes with gparted which can be used to shrink file systems and corresponding partitions.
Hum, the limitations aren’t clear, but the issue make it sound like it’s for installing an atomic distro alongside something more standard, and not the reverse.
Eitherway I should probably do a dry run in a VM, to make sure that:
-A: It doesn’t blow up in my face.
-B: if it blows up in my face, I know how to fix it.
The VM is probably the best way to go. It results in being able to use both distros simultaneously instead of having to shut one down and booting the other.
Yeah… It looks like it’s unfortunately going to be that way…
Put Kinoite in a vm, shrank it, put Debian next to it. I think I let Debian crush kinoite bootloader. Been unsuccessful in getting back into the Kinoite vm…
So yeah… Looks like i’m not dual booting them on real hardware any time soon… Hopefully I can find good docs on how to do it, because the VM performance on my laptop is appalling.
There’s long been a safety feature/limitation (it depends on your point of view in the moment which it is) in the kernel with an in-use storage device, i.e. a device with the root file system mounted at / makes the underlying block device in-use. In that case it is possible to write a modified partition map, but the kernel will not then re-read that partition map and update the in-memory version of that partition map. You have to reboot.
For shink it means you resize btrfs first, then modify the partition map, then reboot. You can, in practice, indefinitely delay the reboot. But you can’t do anything with the new partition map on disk, the old one in memory prevails, until the reboot.
For grow it means you have to modify the partition map first, reboot, then live resize Btrfs.
At mount time, Btrfs kernel code already knows the block device size (the partition size) and makes sure the Btrfs device size is the same or smaller. If the Btrfs device size is bigger than the underlying block device, mount fails because it means something less than the whole file system is available for Btrfs to read/write - and that’s a fail. Whereas if the Btrfs device size is smaller than the underlying block device, then it’s OK to mount because Btrfs just scribbles within its own device size range which is less than the underlying block device range. I’ve inadvertently run Btrfs that are smaller than the underlying block device for months and it never complains - it’s completely safe.
Where we could run into breakage is with Btrfs on LVM because LVM does permit instant resizing of block devices and that plausibly could “truncate” the Btrfs while it’s mounted and running.
On a semi-regular basis I will shrink a Btrfs, then shrink the underlying partition to match, reboot and get boot failure. 100% of the time (for me) this is because I forgot to add 16 MiB to the partition size to account for the LUKS header and offset. In effect this temporarily makes the underlying block device (the plain text virtual block device, i.e. the dm-crypt device) 16 MiB smaller than the Btrfs device size; Btrfs kernel code sees this and fails to mount, thus breaking boot.
