Bug 1139015 - F21 Workstation Alpha TC6 network install fails with crash, hang, reboot or "pane is dead" - caused by anaconda segfault
Summary: F21 Workstation Alpha TC6 network install fails with crash, hang, reboot or "...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 21
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Václav Pavlín
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F21AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2014-09-07 13:26 UTC by Leslie Satenstein
Modified: 2014-10-18 01:58 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-18 17:54:07 UTC
Type: Bug


Attachments (Terms of Use)
journalctl output (80.21 KB, text/plain)
2014-09-08 21:11 UTC, Orion Poplawski
no flags Details
coredump from crashing anaconda (2.72 MB, application/octet-stream)
2014-09-08 22:48 UTC, Adam Williamson
no flags Details
manually-generated backtrace (128.74 KB, text/plain)
2014-09-08 23:00 UTC, Adam Williamson
no flags Details
strace anaconda (601.56 KB, text/plain)
2014-09-08 23:01 UTC, Orion Poplawski
no flags Details
picture of the log (902.59 KB, image/jpeg)
2014-09-22 14:55 UTC, cornel panceac
no flags Details
syslog (130.52 KB, text/plain)
2014-09-22 15:13 UTC, cornel panceac
no flags Details
storage (11.85 KB, text/plain)
2014-09-22 15:13 UTC, cornel panceac
no flags Details
program (1.52 KB, text/plain)
2014-09-22 15:13 UTC, cornel panceac
no flags Details
anaconda (4.87 KB, text/plain)
2014-09-22 15:15 UTC, cornel panceac
no flags Details
anacondayum (351 bytes, text/plain)
2014-09-22 15:16 UTC, cornel panceac
no flags Details
x (20.00 KB, text/plain)
2014-09-22 15:16 UTC, cornel panceac
no flags Details
boot (8.73 KB, application/octet-stream)
2014-09-22 15:16 UTC, cornel panceac
no flags Details
fpaste output from comment 35 (10.40 KB, text/plain)
2014-09-22 15:17 UTC, Andre Robatino
no flags Details
fpaste sysinfo (10.40 KB, text/plain)
2014-09-22 15:20 UTC, cornel panceac
no flags Details
picture of next crash (901.92 KB, image/jpeg)
2014-09-22 15:21 UTC, cornel panceac
no flags Details

Description Leslie Satenstein 2014-09-07 13:26:48 UTC
Description of problem:

Cant perform network installation in either hdmi or vga mode

Version-Release number of selected component (if applicable):

alpha-TC6


How reproducible:

Tried several ways
media check then install          error message   pane is dead
trouble shoot install             error message   pane is dead

Steps to Reproduce:
1.
2.
3.

Actual results:

Unable to proceed. 

other information
Regular Workstation install works with radean card and hdmi
Regular workstation install works in vga mode 

Tested on two systems one, Intel adapter, one with ati adapter.


Expected results:

Network installation functions

Additional info:

Comment 1 Joachim Backes 2014-09-08 12:38:35 UTC
Same here with F21-Alpha-TC6/networkinstall.

Install from Xfce/Live-DVD runs.

Comment 2 David Shea 2014-09-08 13:20:42 UTC
Logs, please

Comment 3 Leslie Satenstein 2014-09-08 15:51:34 UTC
I cannot produce Logs.  System is in ram and lockup is severe, eg (no virtual term available at this start-up point of time in the boot sequence.

Comment 4 David Shea 2014-09-08 16:00:51 UTC
You can't switch to tty2? Are there any other messages printed to tty1? Does the installer start in text mode?

Comment 5 Leslie Satenstein 2014-09-08 19:27:14 UTC
Hi Dave

I tried the direct boot (test media and install), when that failed, because the monitor is  hi resolution mode, I tried the troubleshooting vga mode. This too locked up with the message  "No Panel" or equivalent.

No panel says, it can't talk to the screen, ergo, we cannot tell if tty1, tty2... are accessible. And since this is the net install to anaconda, all data is in RAM.

I am quite prepared to try a patched version of alpha-tc6.  

As a reminder, my two different systems experience the same problem with the version net installation ALPHA-TC6.  

These same systems are just fine with F20

Comment 6 Orion Poplawski 2014-09-08 21:11:50 UTC
Created attachment 935477 [details]
journalctl output

This is a KVM install.  anaconda is segfaulting badly:

Sep 08 21:10:05 vmf21.cora.nwra.com systemd-coredump[1211]: Process 1158 (anaconda) of user 0 dumped core.

                                                            Stack trace of thread 1158:
                                                            #0  0x00007f93ae708aad n/a (n/a)

Comment 7 satellitgo 2014-09-08 21:14:41 UTC
also seen in bare metal install from CD to external USB HD
MSI Wind Book 20" HDMI (bios boot)

Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso

Comment 8 satellitgo 2014-09-08 21:31:53 UTC
(In reply to satellit from comment #7)
> also seen in bare metal install from CD to external USB HD
> MSI Wind Book 20" HDMI (bios boot)
> 
> Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso
Also in VirtualBox get "Pane is Dead"

Comment 9 satellitgo 2014-09-08 21:37:35 UTC
also in Virtualbox with Enable EFI checked get "Pane is Dead"

Comment 10 Brian Lane 2014-09-08 22:34:26 UTC
Make sure the checksum matches. I can't obviously reproduce this using the TC6 Server netinst iso with checksum 2dd02f18f12e74cbe6faa45c7258203880566f9b72850b9dfdbd50341e7c0343

Comment 11 Adam Williamson 2014-09-08 22:48:43 UTC
Created attachment 935505 [details]
coredump from crashing anaconda

Here's the core dump, it can be found in /var/lib/systemd/coredump/ after the bug hits (for me, anyway).

Comment 12 Orion Poplawski 2014-09-08 22:49:19 UTC
Not using netinst.iso, but pxeboot/* and squashfs.img.

Comment 13 Adam Williamson 2014-09-08 23:00:11 UTC
Created attachment 935508 [details]
manually-generated backtrace

it looks a bit odd (might be a mismatch somewhere?) but this is what I get if I run a backtrace on the coredump from the host system (should be about the same F21 as TC6).

Comment 14 Orion Poplawski 2014-09-08 23:01:40 UTC
Created attachment 935509 [details]
strace anaconda

Seems to be loading python _volume_key, opens libgpgme.so.11 and then segfaults.

Comment 15 Brian Lane 2014-09-08 23:33:26 UTC
libgpgme.so.11.11.0 has different checksums on Server (which works for me) and Workstation (which does not). So this is some kind of problem with the compose or packages used for it. I can take a look at the lorax logs if someone points me to them.

Comment 16 poma 2014-09-09 07:30:28 UTC
http://dl.fedoraproject.org/pub/fedora/linux/development/21/x86_64/os/Packages/g/gpgme-1.4.3-4.fc21.x86_64.rpm
$ sha256sum gpgme-1.4.3-4.fc21.x86_64.rpm 
b217490c0b9834751ce7b455e8ca73e480a1a5ee9bc18a9f0489af9cd6578396  gpgme-1.4.3-4.fc21.x86_64.rpm

$ deco gpgme-1.4.3-4.fc21.x86_64.rpm 
1191 blocks
gpgme-1.4.3-4.fc21.x86_64/

$ sha256sum gpgme-1.4.3-4.fc21.x86_64/usr/lib64/libgpgme.so.11.11.0 
d849a3f7acb4b1adc269f58e568c75dd73a4715fcbb07a060c1a153f673133c1  gpgme-1.4.3-4.fc21.x86_64/usr/lib64/libgpgme.so.11.11.0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$ rpm -qf /usr/lib64/libgpgme.so.11.11.0 
gpgme-1.4.3-4.fc21.x86_64

$ sha256sum /usr/lib64/libgpgme.so.11.11.0 
cb24d9bfed224c582ccb67015646c744ac7a2abcaca8a4ec6e61d550594f1b92  /usr/lib64/libgpgme.so.11.11.0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

http://alt.fedoraproject.org/pub/alt/stage/21_Alpha_TC6/Server/x86_64/iso/Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso
$ sha256sum -c Fedora-Server-21_Alpha_TC6-x86_64-CHECKSUM.txt
Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso: OK
$ sha256sum Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso
2dd02f18f12e74cbe6faa45c7258203880566f9b72850b9dfdbd50341e7c0343  Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso
$ checkisomd5 Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso
Press [Esc] to abort check.

The media check is complete, the result is: PASS.

It is OK to use this media.

~~~~~~~~~~~~~~~~~~~~~~~~~~~

http://alt.fedoraproject.org/pub/alt/stage/21_Alpha_TC6/Workstation/x86_64/iso/Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso
$ sha256sum -c Fedora-Workstation-21_Alpha_TC6-x86_64-CHECKSUM.txt 
Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso: OK
$ sha256sum Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso
be545b47dfb39c4d07e0a3efa6725229f8807ef0c19d265f8a4f16dca173b33e  Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso
$ checkisomd5 Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso
Press [Esc] to abort check.

The media check is complete, the result is: PASS.

It is OK to use this media.

~~~~~~~~~~~~~~~~~~~~~~~~~~~

# mount Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso /mnt/netinstFS
mount: /dev/loop0 is write-protected, mounting read-only

# mount /mnt/netinstFS/LiveOS/squashfs.img /mnt/squashfsFS

# mount /mnt/squashfsFS/LiveOS/rootfs.img /mnt/rootfsFS

# sha256sum /mnt/rootfsFS/usr/lib64/libgpgme.so.11.11.0 
d849a3f7acb4b1adc269f58e568c75dd73a4715fcbb07a060c1a153f673133c1  /mnt/rootfsFS/usr/lib64/libgpgme.so.11.11.0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

# mount Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso /mnt/netinstFW
mount: /dev/loop1 is write-protected, mounting read-only

# mount /mnt/netinstFW/LiveOS/squashfs.img /mnt/squashfsFW

# mount /mnt/squashfsFW/LiveOS/rootfs.img /mnt/rootfsFW

# sha256sum /mnt/rootfsFW/usr/lib64/libgpgme.so.11.11.0 
cb45a251d7247c7448343e0ed1b461ba51af1950a3fd6f364d093f6b1bb7a89a  /mnt/rootfsFW/usr/lib64/libgpgme.so.11.11.0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

sha256Summa summarum - libgpgme.so.11.11.0:

- cb24d9bfed224c582ccb67015646c744ac7a2abcaca8a4ec6e61d550594f1b92
  a) Installed system

- cb45a251d7247c7448343e0ed1b461ba51af1950a3fd6f364d093f6b1bb7a89a
  a) Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso
  
- d849a3f7acb4b1adc269f58e568c75dd73a4715fcbb07a060c1a153f673133c1
  a) Fedora-Server-netinst-x86_64-21_Alpha_TC6.iso
  b) dl.fedoraproject.org

~~~~~~~~~~~~~~~~~~~~~~~~~

http://goo.gl/pjc3VO
All Hands Battlestations!
Initiate a Force Field!

Comment 17 Adam Williamson 2014-09-09 07:34:34 UTC
checksumming a library file isn't going to tell you much in any circumstance where prelink might get run.

"prelink  is  a  program  that modifies ELF shared libraries and ELF dynamically linked binaries in such a way that the time needed for the dynamic linker to perform relocations at startup significantly decreases."

Comment 18 Mike Ruckman 2014-09-09 18:05:10 UTC
Checked this with the i386 Workstation image and the installation finishes fine. This error seems to only be on the x86_64 image.

Comment 19 Mike FABIAN 2014-09-09 19:02:40 UTC
I see the same problem also with Fedora-Live-Workstation-x86_64-21_Alpha-TC6.iso
when trying to install it in qemu.

ionice -c 3 qemu-kvm -enable-kvm -global qxl.ram_size=1x1024 -m 2048M -smp 4 -drive file=./Fedora-Live-Workstation-x86_64-21_Alpha-TC6.iso.qcow2,index=0,media=disk,cache=unsafe -localtime -serial file:/tmp/qemu-Fedora-Live-Workstation-x86_64-21_Alpha-TC6.iso.qcow2-output.log -name Fedora-Live-Workstation-x86_64-21_Alpha-TC6.iso.qcow2 -cdrom /local/mfabian/iso/f21-Alpha-TC6/Fedora-Workstation-netinst-x86_64-21_Alpha_TC6.iso -boot c -spice port=6000,disable-ticketing,streaming-video=off -vga qxl -display vnc=:4 -net nic -net user,hostname=Fedora-Live-Workstation-x86_64-21_Alpha-TC6.iso.qcow2,hostfwd=tcp::5555-:22 -monitor stdio -usb

Comment 20 Adam Williamson 2014-09-09 19:22:47 UTC
bcl, dgilmore and I believe the issue here is that the Workstation x86_64 netinst image was for some reason truncated:

<bcl> Some additional info. The libgpgme file appears to be the last one in the rootfs.img. It has about 100k of zeros at the end of in the Workstation image.
<bcl> So it looks like something went and truncated it.

in our testing, Server image worked fine, and its libgpgme.so.11.11.0 file is correct. satellit says he's having trouble with server, but this may be a different bug.

The compose log for the x86_64 workstation image is here: https://ausil.fedorapeople.org/Workstation.x86_64.log

so far I don't think anyone's spotted what's going wrong.

I'll note that if you run the embedded checksum verification from the boot menu it succeeds. I believe this means that the image wasn't corrupted by any step *after* pungi, or else that check would fail. It means the truncation occurred during image generation, at some point before the end of the compose log file where the md5 checksum is generated and inserted into the image.

Comment 21 Stephen Gallagher 2014-09-10 15:33:41 UTC
(In reply to Adam Williamson (Red Hat) from comment #20)
> in our testing, Server image worked fine, and its libgpgme.so.11.11.0 file
> is correct. satellit says he's having trouble with server, but this may be a
> different bug.
> 

FYI, his issue appeared to be a transitory one related to hardware (it failed during partitioning and has not happened except that one time).

I'm updating the summary.

Comment 22 Adam Williamson 2014-09-10 16:26:32 UTC
Discussed at 2014-09-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-09-10/f21-blocker-review.2014-09-10-16.07.log.txt . Accepted as a blocker per https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Expected_image_boot_behavior , "Release-blocking dedicated installer images must boot to the expected boot menu, and then after a reasonable timeout to the installer."

Comment 23 Fedora Update System 2014-09-15 15:27:11 UTC
squashfs-tools-4.3-8.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/squashfs-tools-4.3-8.fc21

Comment 24 Adam Williamson 2014-09-15 16:13:31 UTC
For the record: brunowolff notified me and dgilmore about the bug fixed by the squashfs-tools update, and we all think there's a high probability that it was the bug causing this problem. It occurs intermittently and its results aren't always fatal, but it could definitely break future composes again if it is indeed the culprit, so we decided to pull it in as the fix for this issue for the next compose.

Comment 25 Mike Ruckman 2014-09-15 17:00:24 UTC
Per the QA meeting, I tested with TC7. I haven't seen this with TC7 (i386 netinst, x86_64 netinst and live).

Comment 26 Bruno Wolff III 2014-09-16 15:13:24 UTC
There are still lots of zeros at the end of the RC1 workstation x86_64 ext3.img file. I'm going to see if I can tell which version of squashfs-tools was used to build the image. Note that some zeros are possibly OK at the end of ext3.img. It depends on how resizefs works. Still there does seem to be an excessive amount.

Comment 27 Bruno Wolff III 2014-09-16 15:27:58 UTC
It may be that the way resizefs is used for building images that the disk image doesn't get shrunk and that stuff just gets moved to the begining of the that image, leaving lots of zeros at the end of the file. That would make it hard to tell if there are more zeros than there should be. Presumably there is some way to tell where the ext file system ends from header information and we could look there to see if there are lots of zeros at the end of the used space. So it may be that things are good and for now we'll need to test functionallity. Adding a truncate to the live image creator might be nice.

Comment 28 Bruno Wolff III 2014-09-16 15:45:45 UTC
It looks like the resizing of the ext partition isn't being done for workstation. The part size requested in the kickstart seems to match the size of the extf2.img and the mounted view of that file system. A bit under 4G is used in that filesystem. I'm not sure if this is something the live media creator has changed from livecd-creator or if it got dropped in live-cd-creator for some reason. However, this does seem to make it less likely that the mksquashfs bug would affect this. I would have expected that having the end of the file set to zeros when they are already zeros, wouldn't be a problem. But maybe the zero case is special and extra zeros get set even though the last third of the file was zero to start.

Comment 29 Dennis Gilmore 2014-09-16 16:39:05 UTC
(In reply to Bruno Wolff III from comment #28)
> It looks like the resizing of the ext partition isn't being done for
> workstation. The part size requested in the kickstart seems to match the
> size of the extf2.img and the mounted view of that file system. A bit under
> 4G is used in that filesystem. I'm not sure if this is something the live
> media creator has changed from livecd-creator or if it got dropped in
> live-cd-creator for some reason. However, this does seem to make it less
> likely that the mksquashfs bug would affect this. I would have expected that
> having the end of the file set to zeros when they are already zeros,
> wouldn't be a problem. But maybe the zero case is special and extra zeros
> get set even though the last third of the file was zero to start.

none of the tools you mention are used in creating the install media. we use pungi which uses lorax. this is not live media where we are still using livecd-creator.  there is no size specified in the fedora-install-workstation.ks kickstart. at this point I am really not sure what you are talking about specifically it seems you have different things messed together.  this bug is solely about the boot.iso and not about livecds at all.

Comment 30 Bruno Wolff III 2014-09-16 18:33:18 UTC
I didn't have the full history of this issue and though it was referring to the Live workstation image.(The live images were the ones I was initially worried about.) I'll take a look at the boot iso.

Comment 31 Bruno Wolff III 2014-09-16 18:40:59 UTC
rootfs.img is exactly 2GiB and could possibly be affected by this bug. Howver it is also the case that there is a large chunk of the image that is zero at the end and I don't know if the bug will cause a problem in that case.

Comment 32 Adam Williamson 2014-09-18 17:54:07 UTC
We have not observed this bug in RC1 testing, so we're going to call it resolved for the present. If we observe it in future builds we can re-open and re-investigate.

Comment 33 cornel panceac 2014-09-22 14:55:09 UTC
ok, in RC1 netinst, i have this every time. machine is core i7, 16 gb of ram, gigabyte motherboard.

attaching a picture, because there's no log file in /var/log or /tmp containing this.

Comment 34 cornel panceac 2014-09-22 14:55:53 UTC
Created attachment 940053 [details]
picture of the log

Comment 35 cornel panceac 2014-09-22 15:05:02 UTC
fpaste --sysinfo:

http://paste.fedoraproject.org/135468/11398053/

Comment 36 cornel panceac 2014-09-22 15:13:12 UTC
Created attachment 940059 [details]
syslog

Comment 37 cornel panceac 2014-09-22 15:13:31 UTC
Created attachment 940060 [details]
storage

Comment 38 cornel panceac 2014-09-22 15:13:56 UTC
Created attachment 940062 [details]
program

Comment 39 cornel panceac 2014-09-22 15:15:10 UTC
Created attachment 940063 [details]
anaconda

Comment 40 cornel panceac 2014-09-22 15:16:12 UTC
Created attachment 940064 [details]
anacondayum

Comment 41 cornel panceac 2014-09-22 15:16:29 UTC
Created attachment 940066 [details]
x

Comment 42 cornel panceac 2014-09-22 15:16:58 UTC
Created attachment 940067 [details]
boot

Comment 43 Andre Robatino 2014-09-22 15:17:16 UTC
Created attachment 940069 [details]
fpaste output from comment 35

Please don't attach fpaste output since it expires, bugzilla attachments are permanent.

Comment 44 cornel panceac 2014-09-22 15:20:06 UTC
Created attachment 940070 [details]
fpaste sysinfo

Comment 45 cornel panceac 2014-09-22 15:21:10 UTC
Created attachment 940071 [details]
picture of next crash

Comment 46 cornel panceac 2014-09-22 15:21:36 UTC
last picture matches the logs

Comment 47 Fedora Update System 2014-09-23 02:41:45 UTC
squashfs-tools-4.3-8.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 48 cornel panceac 2014-09-23 08:36:49 UTC
is there a new image build with this version of squashfs-tools? if not, can i build one ? (how?)

Comment 49 cornel panceac 2014-09-24 09:06:16 UTC
so the boot.iso from 23rd of november does not fix this.
http://dl.fedoraproject.org/pub/fedora/linux/development/21/x86_64/os/images/boot.iso

Comment 50 cornel panceac 2014-09-24 10:02:59 UTC
what is the connection between this error and squashfs-tools? squashfs-tools is not installed on netins/boot.iso
.

Comment 51 cornel panceac 2014-09-24 10:31:43 UTC
so anaconda also crashes on live cd, and i've reported it using abrt, but i have no idea where :)
definitely not here.

Comment 52 Bruno Wolff III 2014-09-24 16:11:45 UTC
squashfs-tools is used to build the image. There was a problem with squashing files over 2GiB that potentially could have caused a problem.

Comment 53 cornel panceac 2014-09-25 07:17:32 UTC
ok, thank you. but, if the two images i've last used mentioned above (23 nov boot.iso and 23 nov live workstation, both x64) were created with the new version of squashfs-tools, then this was not thhe fix. the problem is still there. so please reopen this bug report.

Comment 54 Adam Williamson 2014-09-27 05:11:05 UTC
cornel: I don't think your bug is anything to do with the bug we were initially tracking here. the initial bug was an image being completely broken. it didn't boot for *anyone*. you say you see this with an RC1 netinst; those images have been tested good by multiple people. So I think you're running into some kind of crash related to your system. Can you please file a new bug? It's not useful to have your report combined with the initial Alpha TC6 compose error.

Comment 55 cornel panceac 2014-10-16 18:29:39 UTC
Adam, which of the original bug reporters confirmed this is fixed?

Comment 56 Orion Poplawski 2014-10-16 19:46:46 UTC
Hmm, it had been fixed for me, but today a PXE boot of F21 Server Beta TC3 resulted in an anaconda crash/pane is dead message.  No indication of why it crashed though.  It may well be a very different issue.

Comment 57 Orion Poplawski 2014-10-16 20:05:48 UTC
Sorry, yes, mine is a very different issue (bug #1153804):

No size given for logical volume.  Use one of --useexisting, --noformat, --size, or --percent.

All "pane is dead" means is that anaconda crashed hard.

Comment 58 Adam Williamson 2014-10-18 01:58:55 UTC
cornel: you're hitting a crash in libparted. most likely it somehow is choking on your disk layout.


Note You need to log in before you can comment on or make changes to this bug.