Summary: | Crash after 2 failed attempts to resize | ||
---|---|---|---|
Product: | [Applications] partitionmanager | Reporter: | Eric S <subscriber> |
Component: | general | Assignee: | Andrius Štikonas <andrius> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | Keywords: | drkonqi |
Priority: | NOR | ||
Version: | 4.1.0 | ||
Target Milestone: | --- | ||
Platform: | Chakra | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Eric S
2020-07-12 22:03:03 UTC
I tried the resize again after restarting partition manager and got the crash again. I unmounted the partition, tried to resize it, and again the resize failed. This time I'm pretty sure the crash is initated me performing an select All and then Alt-C on the messages in the details window. *** This bug has been marked as a duplicate of bug 413418 *** I think now what may have been the trigger: udisksd was remounting the drive in response to seeing the changes (the sfdisk command was succeeding...when the resizefs2 command then failed another sfdisk command was run to revert the change--bravo to partion manager for that, btw!) At first I thought this was the cause of resizefs2 failing but no, I watched it and the remount didn't occur until after the whole sequence. I was actually getting a prompt for the sudo equivalent (which originally I mistook for a partition manager action) for the mount, and if I cancel that prompt to prevent the mount, partition manager doesn't crash. I did not have any USB drive inserted when any of this happened. Does it still make any sense as a duplicate of 413418? The drive containing the partitions I was working with was an internal hard disk (there was also an internal SSD drive). (In reply to Eric S from comment #4) > I did not have any USB drive inserted when any of this happened. Does it > still make any sense as a duplicate of 413418? > > The drive containing the partitions I was working with was an internal hard > disk (there was also an internal SSD drive). Yes, I think it still duplicate. Backtrace points to crash in the same function. In particular we were dividing by partition capacity which probably was causing division by zero when OS for whatever reason was reporting that capacity to be 0 (it's probably just temporarily after block device changes). I never managed to reliably reproduce that crash but I saw it occasionally on my hardware. |