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:
Same here with F21-Alpha-TC6/networkinstall. Install from Xfce/Live-DVD runs.
Logs, please
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.
You can't switch to tty2? Are there any other messages printed to tty1? Does the installer start in text mode?
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
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)
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
(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"
also in Virtualbox with Enable EFI checked get "Pane is Dead"
Make sure the checksum matches. I can't obviously reproduce this using the TC6 Server netinst iso with checksum 2dd02f18f12e74cbe6faa45c7258203880566f9b72850b9dfdbd50341e7c0343
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).
Not using netinst.iso, but pxeboot/* and squashfs.img.
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).
Created attachment 935509 [details] strace anaconda Seems to be loading python _volume_key, opens libgpgme.so.11 and then segfaults.
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.
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!
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."
Checked this with the i386 Workstation image and the installation finishes fine. This error seems to only be on the x86_64 image.
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
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.
(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.
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."
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
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.
Per the QA meeting, I tested with TC7. I haven't seen this with TC7 (i386 netinst, x86_64 netinst and live).
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.
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.
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.
(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.
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.
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.
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.
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.
Created attachment 940053 [details] picture of the log
fpaste --sysinfo: http://paste.fedoraproject.org/135468/11398053/
Created attachment 940059 [details] syslog
Created attachment 940060 [details] storage
Created attachment 940062 [details] program
Created attachment 940063 [details] anaconda
Created attachment 940064 [details] anacondayum
Created attachment 940066 [details] x
Created attachment 940067 [details] boot
Created attachment 940069 [details] fpaste output from comment 35 Please don't attach fpaste output since it expires, bugzilla attachments are permanent.
Created attachment 940070 [details] fpaste sysinfo
Created attachment 940071 [details] picture of next crash
last picture matches the logs
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.
is there a new image build with this version of squashfs-tools? if not, can i build one ? (how?)
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
what is the connection between this error and squashfs-tools? squashfs-tools is not installed on netins/boot.iso .
so anaconda also crashes on live cd, and i've reported it using abrt, but i have no idea where :) definitely not here.
squashfs-tools is used to build the image. There was a problem with squashing files over 2GiB that potentially could have caused a problem.
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.
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.
Adam, which of the original bug reporters confirmed this is fixed?
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.
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.
cornel: you're hitting a crash in libparted. most likely it somehow is choking on your disk layout.