Description of problem: after respining Fedora 13 on 26 Sep 2010, I discovered that if I output livecd-iso-to-disk to a usb stick larger than 2GB, for example to an 8GB stick or to a 4GB stick, Fedora boots and displays the desktop, but the xserver crashes if I try to load Firefox or another application. On a 2GB stick the 26 Sep respin works just fine. This was not a problem earlier in the summer. I have a respin of F13 I did on 8 Aug 2010 that I put on an 8GB stick and it functions just fine. The kickstart file for both respins is identical. It is possible this problem also is related to a problem I thought was a system-config-printer issue reported on in Bug 616613 but the moderator of that bug thread thinks the issue was one from udev. The printer issue was fixed earlier in September. Any assistance on this issue would be most appreciated. Cheers, Skeeter
so you are blaming an X server crash because of different stick sizes on udev by a wild guess :) why don't we start with X, and analyze the log files.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Oh sorry, the crash happens when you try to run Fedora from LiveCD? If the anaconda crashes during the switching from the text-only mode to the graphic mode, most likely the problem lies in Xorg support for your graphics chip. There are couple of options how we can obtain information necessary for resolving the issue. If the computer is not completely frozen when installation fails, switch to the console (Ctrl+Alt+F2), run command tar cvf /mnt/tmpBackup.tar /tmp and copy /mnt/tmpBackup.tar to some other place -- USB stick, some other computer via network, somewhere on the Internet, and please attach it to the bug report as an attachment using the bugzilla file attachment link above. If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ for more information on that). Then after successful installation you can collect /var/log/anaconda.xlog, /var/log/Xorg.0.log, and the output of the program dmesg instead. Or you can install Fedora in a text mode completely, and then start X after that. If it fails, still /var/log/Xorg.0.log and the output of dmesg program from the failed attempt to start X would be useful. We will review this issue again once you've had a chance to attach this information. Thank you very much in advance.
Matej, Yes, I'm running Fedora as a LiveCD on a USB stick. One correction to the original post: I should have written that not only xserver crashes, but the entire operating system, so checking logs is not possible. I have been successfully respinning Fedora with the same kickstart file on the same old Dell computer starting with Fedora 10 continuing through Fedora 13 and never had any problem with video drivers. For all that time I put my respin on an 8GB stick partitioned 2GB for the OS and 6GB for storage. I never had a problem until after July 2010 when I did a respin and got the results described in my original post. My latest respin is from September 26. **Please note** as mentioned in the original post, the respin works just fine on a 2GB stick. The OS crashes only if I put the respin to a 4GB or larger stick. Sorry if I offended by suggesting udev, but Tim Waugh over on the Bug 616631 thought udev might have been responsible for Fedora failing to recognize usb printers starting July 2010. I thought if udev possibly caused a usb printer problem, perhaps it could cause a usb stick problem. Anyway, the crashing OS problem exists whether or not udev is responsible and it would be helpful if the bug could be eliminated. Thanks for your help. Skeeter
(In reply to comment #0) > Description of problem: after respining Fedora 13 on 26 Sep 2010, I discovered > that if I output livecd-iso-to-disk to a usb stick larger than 2GB, for example > to an 8GB stick or to a 4GB stick, Fedora boots and displays the desktop, but > the xserver crashes if I try to load Firefox or another application. On a > 2GB stick the 26 Sep respin works just fine. > > This was not a problem earlier in the summer. I have a respin of F13 I did on > 8 Aug 2010 that I put on an 8GB stick and it functions just fine. I am getting really sad with this bug. It feels so information-free that I don't know what to do. First of all, where do you take your persuasion that Xorg server is crashing and not (for example, not that I am trying to throw bug over the fence) kernel? Are you able to get *any* information from the computer when it crashes? Ctrl-Alt-F2, ssh from other computer anything? Thanks for patience with us
I hadn't thought about ctrl-alt-f2; thanks for the suggestion. This is what happened last night after booting off the 8GB stick: Desktop comes up normally. I open and close some applications. This time, unlike earlier attempts at using the OS on a 8GB stick, I actually could use the apps. Earlier the OS crashed after opening just one or sometimes two applications. Thinking perhaps I was mistaken about the 8GB usb stick problem, I start the shutdown process. Then OS crashes. Cursor still moves, but shutdown freezes with the desktop still displayed. ctrl-alt-f2 Terminal 2 displays: Fedora release 13 (Goddard) Kernel 2.6.33.3-85.fc13.i686 on an i686 localhost login: Ext4-fs error (device dm-0): ext4_find_entry: reading directory #15539 offset 0 then after a few seconds the following displays right below the msg above: Ext4-fs error (device dm-0): ext4_find_entry: reading directory #82757 offset 0 Then terminal 2 freezes. I manually switch off the computer, reboot with the same spin on a 2GB stick and the OS functions normally (I am using the 2GB stick to prepare this message). I switch to terminal 2 and get the expected liveuser login: prompt. No error messages. Shutdown is normal. I realize it's not much to go on, but perhaps the error messages above will give you a clue as to what is happening.
(In reply to comment #6) > Then OS crashes. Cursor still moves, but shutdown freezes with the desktop > still displayed. OK, so this is most likely not Xorg ... i.e., you loose screen because whole system goes down. > localhost login: Ext4-fs error (device dm-0): ext4_find_entry: reading > directory #15539 offset 0 > > then after a few seconds the following displays right below the msg above: > > Ext4-fs error (device dm-0): ext4_find_entry: reading directory #82757 offset 0 OK, this is definitively not Xorg. Reassigning to kernel.
Well, it's possible the crash on an 8gb usb stick is due to the kernel, but I would point out that the kernel in spin that started this bug report is the kernel that was in the original F13 release (see comment 6 above) AND the original F13 release and kernel was perfectly happy living on an 8gb usb stick. So my guess is the source of the crash is not the kernel but another package. To be complete, last night I did another respin of F13 to draw in the latest updates (again kickstart is the same file I have used since F10) and the results are the same: respin set up as a live cd on a 2gb stick is happy; respin set up as a live cd on an 8gb stick crashes.
Here are some additional details that I hope will help diagnose this bug: This comment is based on boots of a live-usb stick with a f13 respin made October 29, 2010 (as always the kickstart is the same one used since fc10 and which has produced error free spins through August 2010 when problems crept in: first the inability of the spin to recognize my hp1200 usb printer (now fixed), the problem described above putting the respin on a usb stick larger than 2GB, and now a new one, the spin put on a 2GB usb stick that boots and operates fine on a machine with only 1GB of memory, but which will not boot at all on a machine with 8GB of memory.) ######################################################### #Boot log from boot on Dell 4225 with 1GB of RAM # # # # **Note_1:** after boot and despite the udevd messages,# #this spin on this machine operates normally # # # # **Note_2:** I have a fc13 spin made on Aug 8, put on # # a 8GB stick partitioned 2GB (os) 6GB (data) that boots# # error free (no udevd messages either) on the Dell AND # #the machine describe below # ######################################################### Welcome to [0;34mFedora [0;39m Press 'I' to enter interactive startup. Starting udev: udevd[442]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 udevd[442]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:2 udevd[442]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:3 udevd[442]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:4 udevd[442]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:5 udevd[442]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:6 udevd[442]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 %Gudevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:2 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:3 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:4 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:5 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:6 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:2 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:3 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:4 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:5 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:6 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:2 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:3 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:4 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:5 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:6 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:2 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:3 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:4 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:5 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:6 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:2 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:3 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:4 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:5 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:6 udevd[443]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:7 [60G[ [0;32m OK [0;39m] Setting hostname localhost.localdomain: [60G[ [0;32m OK [0;39m] Setting up Logical Volume Management: No volume groups found [60G[ [0;32m OK [0;39m] Checking filesystems [60G[ [0;32m OK [0;39m] Mounting local filesystems: [60G[ [0;32m OK [0;39m] Enabling local filesystem quotas: [60G[ [0;32m OK [0;39m] Enabling /etc/fstab swaps: [60G[ [0;32m OK [0;39m] Entering non-interactive startup Adding live user [60G[ [0;32m OK [0;39m] Starting sandbox [60G[ [0;32m OK [0;39m] ip6tables: Applying firewall rules: [60G[ [0;32m OK [0;39m] iptables: Applying firewall rules: [60G[ [0;32m OK [0;39m] Starting auditd: [60G[ [0;32m OK [0;39m] Starting portreserve: [60G[ [0;32m OK [0;39m] Starting system logger: [60G[ [0;32m OK [0;39m] Enabling p4-clockmod driver (passive cooling only): [60G[ [0;32m OK [0;39m] Starting irqbalance: [60G[ [0;32m OK [0;39m] Starting rpcbind: [60G[ [0;32m OK [0;39m] Starting system message bus: [60G[ [0;32m OK [0;39m] Setting network parameters... [60G[ [0;32m OK [0;39m] Starting NetworkManager daemon: [60G[ [0;32m OK [0;39m] Starting Avahi daemon... [60G[ [0;32m OK [0;39m] Starting NFS statd: [60G[ [0;32m OK [0;39m] Starting RPC idmapd: [60G[ [0;32m OK [0;39m] Starting cups: [60G[ [0;32m OK [0;39m] Mounting other filesystems: [60G[ [0;32m OK [0;39m] Starting acpi daemon: [60G[ [0;32m OK [0;39m] Starting HAL daemon: [60G[ [0;32m OK [0;39m] Retrigger failed udev events [60G[ [0;32m OK [0;39m] Enabling Bluetooth devices: Starting sendmail: [60G[ [0;32m OK [0;39m] Starting sm-client: [60G[ [0;32m OK [0;39m] Starting abrt daemon: [60G[ [0;32m OK [0;39m] ####################################################### #Here is what happens when the same stick is put in an# #Intel i7-860 based machine with 8GB of RAM # # # #**Note:** Since machine does not boot, following is # #transcribed from the screen output and may contain # #some typos... # ####################################################### (several screenfulls of...) Starting udev: udevd[625]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/50-euvccam.rules:1 (then...) rpcbind Bug: unable to handle kernel paging request at fa986630 IP[<c056018d>] list_del+0x9/0x60 *pde=3673707 *pte=000000 oops: 0000#1 smp last sysfs: /sys/devices/system/cpu/cpu7/cache/index2/shared_cpu_map . . . . ip6tables applying firewall rules: modprobe: FATAL ERROR: Error inserting ipv6 (lib/modules/2.6.34.7-61.fc13:686/kernel/net/ipv6/ipv6i.ko cannot allocate memory [Failed] iptables.restore v1.47: iptables-restore: unable to initialize table 'filter' error occured at line 3 . . . . Starting NFS statd [Failed] followed by several screens of call trace, but the output is so detailed I could not possibly transcribe it
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.