5
When I add a large file to /home, I see the used space increasing in both.
This is how btrfs works. You have one partition formatted to btrfs and the filesystem itself is divided into multiple (in case of Fedora two) subvolumes. All the subvolumes share the same space, that's why you see both / and /home having same 814G free space and that's why creating a ...
3
This is normal when you mount different subvolumes of the same Btrfs filesystem. In the output of mount you will see subvol=… different for each. Your /etc/fstab is probably where these are specified.
I created separate partitions for / and /home.
Maybe you did create partitions, but somehow these mountpoints use a single filesystem now. Or maybe you ...
2
You won’t be able to resize the partition that you are current running in - it appears here that you’re booted into the Linux install that’s running on /dev/sda5? If that’s the case, you can boot a liveCD or a USB installer, so that all of the partitions on /dev/sda are unmounted. Once unmounted and booted from a liveCD you should be able to extend/resize ...
2
Just turn off formatting of the mentioned partitions and add a Root one?
That's pretty much it, yeah. Though there are some caveats:
Be sure neither distro leaves the swap partition in a mess for the other to find. Not sure of defaults, but the swap partition can be configured as the storage location for hibernation data. Though worst case is probably just ...
2
First step, do a full and adequate backup. Accidents happen, and for all you know your XFS system might be slightly corrupt and might crash completely when resized. Or I could be a royal a*hole and being giving you bad advice just to imagine your face when the file system throws the bucket. Or, quite possibly, I could be convinced in good faith that these ...
2
Turns out, the kde auto-mounting system, udisks2 can cause quite a bit of trouble. Especially when trying to modify and update disk partitions.
Temporarily disabling udisk2 using sudo systemctl stop udisks2.service did it for me.
Refer to this thread for more
2
ISO hybrid images are crazy combinations of iso9660 format and multiple partition tables to make sure it boots everywhere. This is how the superblock looks:
DEVICE OFFSET TYPE UUID LABEL
sdb 0x8001 iso9660 2020-09-26-10-19-19-00 Debian 10.6.0 amd64 n
sdb 0x1fe dos
sdb 0x200 gpt ...
1
You've got a dead disk. You might have been able to scrape some remains off it if you had avoided trying to write to it, but updating the partition table has all but put that idea aside.
I'm sorry to be the bearer of bad news, but it's dead and you will need to replace it.
1
So your sdb and sdd drives seems to be unused. You are using LVM, so you first need to add these drives to your existing volume group and then resize the root (or home or var logical volumes).
Create partitions on sdb and sdd using fdisk (it's an interactive tool, just run fdisk /dev/sdb, use n to add new partition, accept all defaults for start, size etc. ...
1
You should choose the partition type according to the role the filesystem on the partition has. In your case, if you have only one Linux partition then that is your root partition, and the appropriate type is Linux root (x86-64).
The partition type is mostly not that critical, since other mechanisms are typically used to determine both the filesystem type (...
1
If you mean the white bit to the right of the yellow bit, in the picture? That is not a realistic picture of what is happening, It is just a bar chart of how much space is use in the file-system, not where it is used. It is file-system free space. It will get used as you add files to the file-system, and get bigger when you remove them.
If you mean not used ...
1
I would hope that udev (which creates these symlinks as far as I know) would see that the /dev/disk/by-partlabel/ROOT symlink already exists (and refers to the root partition on /dev/sdb) and skips creating the symlink for /dev/sda, but is that actually what happens?
Unfortunately with udev the last device processed using the udev rule wins so usually udev ...
1
The problem with partitions like EFI or /boot and RAID is that UEFI and GRUB don't understand RAID metadata -- they need the partition superblock to be certain type (FAT in case of EFI) and if there are RAID metadata it will simply think the partition isn't EFI and won't use it.
This is usually solved by using MD RAID metadata version 0.90 -- in this version ...
1
7.8 GiB sounds ok to me. Software got bigger in past few years and full fat desktop environments like GNOME or KDE with all the default applications are big.
I'm not using MX Linux, but default installation of Fedora Workstation with GNOME is 6.7 GiB. The 5 GiB recommendation for root partition is very small, it should be at least 25 GiB and I'd recommend 50 ...
1
This may be almost a duplicate of this other question. Please read my answer there to learn what could happen. Almost, because I would not suspect similar problems for a disk reporting 512 as its physical sector size.
So maybe the RAID controller distorts the value(s) now; maybe the USB enclosure interfered like in the other question; maybe ESXI did some ...
Only top voted, non community-wiki answers of a minimum length are eligible
