Announcement

Collapse
No announcement yet.

KDE Partition Manager on Live Session buggy?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    KDE Partition Manager on Live Session buggy?

    One of the reasons I had an abrupt transition from Ubuntu Mate 16.04 to Kubuntu 20.04.1 is because I tried to use the Live Session of 20.04 to do something I couldn't do from within an installed Ubuntu: resize my home partition. I've been running short on space for several months (which blows my mind a bit, since I have more than 1.3 TB total storage on my system, and a 256 GB SSD for my OS and /home -- and I once thought a 20 MB hard disk was more space than I'd ever fill), so my plan was to eliminate a partition and shrink another, and give that space to the large /home that's been reused (with new user folders) since I got the SSD.

    I didn't count on there being a massive bug in KDE Partition Manager.

    Short version: after deleting on partition and resizing and moving another, KDE Partition Manager reported an error in the very last operation, "growing filesystem to fit partition." After which, my 150 GB /home partition, with two partially completed novels on it (among other important data), showed as "unallocated."

    After a short period of near-panic, I got a good suggestion on AskUbuntu (the Ubuntu Stack Exchange site), and was able to use Testdisk (still in the Live Session) to recover the partition (by repairing the device partition table). That done, I resumed the process of resizing the /home -- and got the same error, with the same result. To shorten a bit more, I wound up recovering mangled partition table entries a total of eight times before concluding there was a bug in KDE Partition Manager causing this recurring problem, temp-installing GParted, and finishing the job with no further issues.

    Except that one of the times I recovered the partition table I restored the wrong copy of one partition's entry. The partition that held my Ubuntu Mate 16.04 install, and my GRUB configuration, was completely gone (and this is an SSD, so by the time I was done, it was almost certainly overwritten, rather than still present on a platter surface).

    Since I already had a known-working Live Session of Kubuntu 20.04, and it was one of the two candidates (the other being the nearly identical MX 19.3, which differs mainly in terms of defining version jumps differently from mainstream Debian-based distros), I just installed it and moved forward (including uninstalling KDE Partition Manager as soon as I was sure the installation was complete and successful).

    I don't have the information I'd need to file a proper bug report -- in fact, I don't get how anyone does that, in the middle of also trying to fix whatever havoc a major bug in something like a partition manager causes. I'm not going to make any attempts to reproduce the bug -- eight times was at least seven too many, and because I'm not a Linux hobbyist (my computers are tools, not toys -- I need them to work) I don't have a spare machine I don't mind wiping and reinstalling, and I don't run a vanilla system that can be reinstalled in a half hour (in fact, despite this incident occurring on December 24th, I was still reinstalling some software today, January 2, after only going to work three days in between).

    Before you conclude that this is just an operator error, I'd point out that this is very much not my first rodeo. I first partitioned a hard disk in 1988, under DOS 3.31, using the Microsoft version of fdisk without any helping software (no such thing existed then) (because I'd just gotten a new 40 MB drive, and DOS only supported up to 32 MB in a single volume).

    #2
    Gparted and Kparted are way to slow to resize partitions, your best bet is back up your data, delete partitions, create new ones and put your data back.
    Linux since 2008, Kubuntu 20.10
    *ASUS 970 PRO GAMING/AURA AM3+ AMD 970 + SB 950 SATA 6Gb/s USB 3.1
    *AMD FX-8370 with AMD Wraith cooler Vishera 8-Core 4.0 GHz (4.3 GHz Turbo)
    *G.SKILL Ripjaws X Series 16GB DDR3 SDRAM -- Asus GEFORCE GTX 1050 TI 4 GB

    Comment


      #3
      In general, I'm less concerned about how long it takes, than about whether it works reliably and whether I have storage space for the backup. I don't currently own a storage device with as much as 150 GB free space, and despite the datacenter rule of thumb, mass storage is not free -- though it's much, much cheaper than it was when I got my first > 1 GB hard disk (late '90s or early '00s).

      If I'd had space to put a full backup, yes, it would have been much faster (and given a better result) to create a new partition table, create partitions the number and sizes I now want, and restore the installed OS and data (I'd have had to edit /etc/fstab, of course).

      The point of the original post, however, was as a warning, a red flag, and to confirm whether others have run into this or whether it's a one-time thing affecting only my system.

      Comment


        #4
        I have gone to bed and woke up and it was still resizing, or it just died with an error. Maybe others will chime in on sizing partitions?
        You might be able to backup your partitions using clonezilla, it compresses and does not use a lot of space. If you are going to be sizing partitions and have data that you cannot afford to lose, you should be doing a backup first anyways.

        My 20GB root partition compressed to 3.5GB in backup. Plus there are scenarios in the program, to compress backups even smaller.
        Last edited by rdonnelly; Jan 03, 2021, 10:37 AM.
        Linux since 2008, Kubuntu 20.10
        *ASUS 970 PRO GAMING/AURA AM3+ AMD 970 + SB 950 SATA 6Gb/s USB 3.1
        *AMD FX-8370 with AMD Wraith cooler Vishera 8-Core 4.0 GHz (4.3 GHz Turbo)
        *G.SKILL Ripjaws X Series 16GB DDR3 SDRAM -- Asus GEFORCE GTX 1050 TI 4 GB

        Comment


          #5
          Originally posted by Silent Observer View Post
          One of the reasons I had an abrupt transition from Ubuntu Mate 16.04 to Kubuntu 20.04.1 is because I tried to use the Live Session of 20.04 to do something I couldn't do from within an installed Ubuntu: resize my home partition. I've been running short on space for several months (which blows my mind a bit, since I have more than 1.3 TB total storage on my system, and a 256 GB SSD for my OS and /home -- and I once thought a 20 MB hard disk was more space than I'd ever fill), so my plan was to eliminate a partition and shrink another, and give that space to the large /home that's been reused (with new user folders) since I got the SSD.
          ...
          What are you using the 1.3TB of drive space for? Are you dual booting with Windows? I ask, because it's important to know how your system is set up.

          You have 256GB SSD with / and /home. Are / and /home mounted on separate partitions, or the same one? Again, need to understand your current setup.

          There are ways to configure your system so that /home can be "extended" to a subdirectory that is on another partition and even on another drive.

          Have you tried to download Gparted and set it up, by itself, as a Live session on a USB thumb drive?
          The next brick house on the left
          Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.27.11​| Kubuntu 24.04 | 6.8.0-31-generic



          Comment

          Working...
          X