Re: Unable to start X
On Mon, Jan 25, 2010 at 08:59, Petrus de Calguarium wrote: > Paul F. Johnson wrote: > > > TTFN > > TTFN? Thanks to F'ing Nobody? > > > Any ideas on how to get my desktop to boot > > I am using Intel driver and I am also unable to get X to boot in rawhide. I > have > tried startx, putting 5 on the kernel boot line in grub, etc., to no avail. > I get a > mouse pointer superimposed on the konsole login screen. I can switch to a > different > virtual console and log in on the command line, but no X session. > > There was some breakage recently with the graphic boot. Try hitting the escape key on boot to get the text startup instead. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unable to start X
On Mon, Jan 25, 2010 at 14:29, Mike Chambers wrote: > On Mon, 2010-01-25 at 13:04 -0800, darrell pfeifer wrote: > > > > > There was some breakage recently with the graphic boot. Try hitting > > the escape key on boot to get the text startup instead. > > This an xorg-server issue or something else? Cause I just posted bout > this issue (see f12 to rawhide upgrade), and ran into same sort of > problem, although mixed results. > > > Prior to Christmas I had two separate problems a) Plymouth graphic boot needed to be escaped to text mode at boot b) The intel driver didn't work (even if plymouth did) Both problems exhibit somewhat the same outcome - you get to gdm login and just get a cursor. The intel driver problem lasted for all of the 2.6.32 kernels from F12 to rawhide With the newer 2.6.33 kernels I've seen the both problems come and go. For instance, there were a few 2.6.33 kernels where the intel driver worked as long as you hit escape to get past the plymouth problem. With the current rawhide kernel (kernel-2.6.33-0.20.rc5.git0.fc13) both problems are resolved. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
update means only runlevel 1
i did an update this morning that took my machine from current rawhide to a few koji updates. included were dracut, udev and i memory serves me right, a minor initscript cleanup. now i can't get any farther than runlevell 1. going to even runlevel 3 hangs. any suggestions of what might be broken? (sorry for the brevity, typing on an inconvenient box) darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update means only runlevel 1
On Fri, Jan 29, 2010 at 15:15, Tom London wrote: > On Fri, Jan 29, 2010 at 3:11 PM, darrell pfeifer > wrote: > > i did an update this morning that took my machine from current rawhide > > to a few koji updates. included were dracut, udev and i memory serves > > me right, a minor initscript cleanup. > > > > now i can't get any farther than runlevell 1. going to even runlevel 3 > hangs. > > > > any suggestions of what might be broken? > > > > (sorry for the brevity, typing on an inconvenient box) > > > > darrell > > > > Could this be it: https://bugzilla.redhat.com/show_bug.cgi?id=560031 ? > > That was it. I thought at my age I'd have more patience. thanks for the quick response. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide rocks! [was Re: fedora mission (was Re: systemd and changes)]
On Mon, Aug 30, 2010 at 15:56, Matthew Miller wrote: > On Mon, Aug 30, 2010 at 11:11:06PM +0200, Miloslav Trmač wrote: > > A typical developer wants the dependencies of the software they are > > working on to be _very_ up to date - probably not the upstream > > development version, but the upstream maintenance version with _all_ > > current bug fixes. Waiting 6 months for a bug fix does not make sense - > > at that point the developer would be tempted to build the new version > > locally. > [...] > > Saying "use rawhide" is not helpful, because rawhide is very often > > broken. > > I've been running rawhide as my primary desktop OS at work for a couple of > years now. During that time, it's only broken so as to cause me as much as > a > couple of hours work twice. That seems like a small price to pay for being > on the extreme leading edge as you describe. > > And now with the "no frozen rawhide" feature, I expect it to be even more > stable. > > I've moved from being a rawhide junkie to a koji junkie. I've been in that mode for the last five or six years. My experience has been that rawhide is most unstable just around alpha time. There are typically lots of regressions in rawhide. I can expect that (suspend/resume, printing, usb key mounting, X, compix, control panels, et al) are broken on a regular basis. Maybe we should start a self-help group for those of us with this affliction. I'm more surprised that the package owners haven't found a better way to make use of us yet. I choose to live with the regressions. Most users of Fedora are probably interested in a far more stable system. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus misbehaving
On Sun, Aug 29, 2010 at 10:03, Tom London wrote: > On Sun, Aug 29, 2010 at 9:49 AM, Paul F. Johnson > wrote: > > Hi, > > > > After the recent rawhide to nautilus 2.90.1-1.fc15.i686, it's stopped > > working claiming that I don't have Settings schema > > 'org.gnome.desktop.lockdown' installed. > > > > What is this and how do I fix the problem? > > > > TTFN > > > > Paul > > Not sure about your problem, but here is where that schema comes from: > > [...@tlondon ~]$ rpm -qif > /usr/share/glib-2.0/schemas/org.gnome.desktop.lockdown.gschema.xml > Name: gsettings-desktop-schemasRelocations: (not relocatable) > Version : 0.0.1 Vendor: Fedora Project > Release : 2.fc15Build Date: Tue 24 Aug > 2010 01:59:22 PM PDT > Install Date: Wed 25 Aug 2010 06:20:01 AM PDT Build Host: > x86-03.phx2.fedoraproject.org > Group : System Environment/Libraries Source RPM: > gsettings-desktop-schemas-0.0.1-2.fc15.src.rpm > Size: 49344License: LGPLv2+ > Signature : (none) > Packager: Fedora Project > URL : > http://bugzilla.gnome.org/enter_bug.cgi?product=gsettings-desktop-schemas > Summary : A collection of GSettings schemas > Description : > gsettings-desktop-schemas contains a collection of GSettings schemas for > settings shared by various components of a desktop. > [...@tlondon ~]$ > > Nautilus appears not to be starting on login for me; I need to start > it manually via 'nautilus --no-default-window&'. BZ'ed here: > https://bugzilla.redhat.com/show_bug.cgi?id=627639 > > > I installed gsettings, then the new nautilus. Now when I log in nautilus doesn't start. It will start from the command line and stay running, but the next time I log in I have to start it again. The (closed) bug reports mention cleaning the nautilus cache, but googling doesn't give me anything to do that. (I deleted the thumbnails file, but the problem persists) Any suggestions? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CUPS problem
> > Paul, > > The following is in BZ : 632042 > > I'm seeing this with my Samsung ML2250 (my box is using Rawhide, updated > today 09/09/10) so it looks like the problem is not with hplip but with > CUPS or CUPS/Gutenprint > > However, looking at koji, the last update to Cups was 20th Aug but I've > seen no reports of problems. Downgrading to a previous version of both > cups and gutenprint doesn't fix the problem either. Rewinding hplip to > the previous version (and rebuilding as it won't just install due to it > needing python 2.6) doesn't fix it either. > > I'm starting to think this could be lower down - possibly either glib or > even the kernel (googling supports the kernel argument). There is > nothing untoward in the cup error log either which lends further support > to either the kernel or glib. > > I'm still waiting on my password reset to come through so would > appreciate advice under what to log it as. > > Ran into this yesterday and it took a bit to figure out. Cups is fine, but ghostscript is broken in the latest update. Back it out and printing will work again. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide x86_64: WiFi completely hosed, ditto GDM
On Thu, Sep 23, 2010 at 17:04, Horst H. von Brand wrote: > As of yesterday there simply is no way to get WiFi (iwlagn here) to > work. Restarting NetworkManager, avahi-daemon, udevd, dbus has no > effect. Restrarting nm-applet does nothing, no response to iwconfig ow iw. > > The configuration for the wired network (set up statically for work) > doesn't work either, but connecting at home with DHCP does work. > > GDM crashed on boot yesterday, luckily I've got XDM (and XFCE) installed > here. > > iwlagn is working for me. Gnome is currently broken in a bunch of ways (nautilus segfaults, background/settings don't work). I used kdm for a while, but gdm works with the latest rawhide/koji. There was a message to the list that gnome was going to be a bit broken due to a new gobject-instrospection, so anything that hasn't been rebuilt yet for it is having problems. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 11:55, Owen Taylor wrote: > On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: > > > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion > > > `G_IS_OBJECT (object)' failed > > > Segmentation fault (core dumped) > > > > There also seem to be problems with nautilus from GTK+ ABI changes - I > > see various warnings along the lines of: > > > > (nautilus:27082): GLib-GObject-WARNING **: specified class size for type > > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class > > size > > > > These indicate a definite need for rebuild, so I'll kick one off now, > > and maybe things will be better after that finishes. It's certainly not > > worth worrying about anything related to Nautilus until it's rebuild. > > The newer version still dies. It seemed to work for a while but segfaults again. Also, sftp doesn't work any more. Interestingly enough, it doesn't segfault under KDE. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sun, Sep 26, 2010 at 09:30, Tom London wrote: > On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer > wrote: > > > > > > On Sat, Sep 25, 2010 at 11:55, Owen Taylor wrote: > >> > >> On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: > >> > >> > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion > >> > > `G_IS_OBJECT (object)' failed > >> > > Segmentation fault (core dumped) > >> > > >> > There also seem to be problems with nautilus from GTK+ ABI changes - I > >> > see various warnings along the lines of: > >> > > >> > (nautilus:27082): GLib-GObject-WARNING **: specified class size for > type > >> > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class > >> > size > >> > > >> > These indicate a definite need for rebuild, so I'll kick one off now, > >> > and maybe things will be better after that finishes. It's certainly > not > >> > worth worrying about anything related to Nautilus until it's rebuild. > >> > > > > The newer version still dies. It seemed to work for a while but segfaults > > again. Also, sftp doesn't work any more. > > Interestingly enough, it doesn't segfault under KDE. > > darrell > > -- > > Does this sound like your segfaults: > https://bugzilla.redhat.com/show_bug.cgi?id=636543 > > I'm guessing that is some change in the gtk3 interface... > > I haven't run a stack trace on mine, so I can't be sure. Your guess might be accurate though. I also notice that chrome has been segfaulting with annoying frequency which is strange because it has been very stable for me. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ssh-to-rawhide hangs (uninterruptible) for 2 minutes, then fails
Jim, Fails for me too, with the same error. darrell On Sat, Sep 10, 2011 at 12:28, Jim Meyering wrote: > I cannot ssh to my rawhide VM today: > >$ date; ssh r; date >Sat 2011-09-10 19:55:35 +0200 >Write failed: Broken pipe >Sat 2011-09-10 19:57:35 +0200 > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What do rawhide testers want and expect?
On Mon, Sep 12, 2011 at 08:57, Stephen John Smoogen wrote: > In reading the long trash each other fest that accompanies pre-release > jitters, could we start on a cleaner plate? What do the people who are > using rawhide day-in/day-out expect out of the channel? What level of > pain does someone like Jonathan Corbet expect and how can we better > serve them? [And no this isnt me trying for another distro quote of > the week, he is just my reference point of someone I know who runs > rawhide day in and out.] > > In some cases, expectations may be off which means we need to market > our deliverables better. In other cases, they may be looking for a > better way to get attention to rawhide issues when everyone else is > focused on F-XX-beta. In that case we can look at a mechanism that > allows for less "zero-sum" game antics of elementary school yard "you > suck, no you suck more" that the threads head towards. > > Background I've been doing daily updates from rawhide for the past 5+ years. Over the last couple of years I've become a koji junkie, sometimes doing updates a few times a day. I never run an actual release version of fedora. Expectations I recognize that fedora (and even more so rawhide) represent the latest in software. I expect that when I run rawhide there will be many components that are broken. As as "rawhide tester" I generally try to report packaging and functionality problems as quickly as possible. There are occasional issues that can cost me a great deal of time to work around, diagnose and report. I expect that package maintainers will do their best to keep a minimum of breakage. I also expect that when a critical problem is discovered that they will update their packages in a timely manner. I recognize that some of the problems that I report might be interesting to me, but they may have a limited impact and so may not be fixed quickly. I generally have a backup plan that ensures that when breakage occurs I will have a workaround or backout, or just live with the problem. Commentary I've never been much of a joiner or wanting to be part of an official process. I have no interest in being a proven tester. I'm surprised that the maintainers of the critical systems don't use the pool of rawhide testers more to help them monitor the problem with packages. It is common to see maintainers letting other maintainers know about dependency updates, but it is rare to see a maintainer give a "heads-up" for feedback about a package they are updating. Summary Rawhide isn't really all that broken and the state of the current processes is actually quite good. People who use rawhide regularly learn to cope with a certain amount of broken issues. The current state of testing for many packages doesn't allow for updates to be error-free, so people who want more stable systems should stick with one of the release versions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 feels slow
On Wed, Sep 14, 2011 at 13:28, Bruno Wolff III wrote: > On Wed, Sep 14, 2011 at 13:46:40 -0700, > Adam Williamson wrote: > > > > They weren't; see my numbers in the related bug > > (https://bugzilla.redhat.com/show_bug.cgi?id=735268 ). The debug > > overhead appears to have gotten much heavier in 3.1. > > I added myself to that bug, though I wasn't really seeing that much of > a slow down in graphics. (I have an rv280 which might not have the issue > that later radeon cards were having.) My issue seems to be related to > disk I/O. I am not sure if it is heavier cpu use in journalling, raid or > encryption or if the actual I/O is slower. But it seems that I/O heavy > activities such as yum updates and kernel builds are taking several times > longer than they were a few weeks ago (in rawhide). > > I'm using the latest rawhide kernel. During times of heavy I/O the system becomes very unresponsive. The cursor will stop moving long enough to count to between 5 and 10. I know it happens with heavy network I/O so it might be the particular driver in my case. Not sure if the slow-down is true for other types of I/O. This has been true for all of the recent rawhide kernels. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
upgrading from grub to grub2
The wiki at http://fedoraproject.org/wiki/Features/Grub2 has instructions for upgrading from grub to grub2. Do these instructions still apply, or will 'yum install grub2' do the work in the post install script? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
grub-efi replaces grub and grub2 along the way?
I did an update which I thought was going to do everything but grub but this happened: # yum update --exclude=grub Loaded plugins: langpacks, presto, refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package grub.x86_64 1:0.97-79.fc16 will be obsoleted ---> Package grub-efi.x86_64 1:0.97-83.fc17 will be obsoleting ---> Package grub2.x86_64 1:1.99-9.fc17 will be obsoleting the final result was Dependencies Resolved Package ArchVersion Repository Size Installing: grub-efi x86_64 1:0.97-83.fc17 koji120 k replacing grub.x86_64 1:0.97-79.fc16 grub2x86_64 1:1.99-9.fc17 koji1.2 M replacing grub.x86_64 1:0.97-79.fc16 which wasn't why I wanted at all since I was trying to avoid grub2 for the moment. I also thought from the list that grub-efi was going to be a subpackage of grub but maybe I read too quickly. I didn't look too closely and did a kernel update later. This resulted in another problem with grubby Running Transaction Updating : libkworkspace-4.7.2-5.fc17.x86_64 1/20 Updating : ksysguard-libs-4.7.2-5.fc17.x86_64 2/20 Updating : kdebase-workspace-4.7.2-5.fc17.x86_64 3/20 Updating : kdebase-workspace-libs-4.7.2-5.fc17.x86_64 4/20 Updating : kdm-4.7.2-5.fc17.x86_64 5/20 Installing : kernel-devel-3.1.0-0.rc9.git0.3.fc17.x86_64 6/20 Updating : ksysguardd-4.7.2-5.fc17.x86_64 7/20 Updating : kernel-tools-3.1.0-0.rc9.git0.3.fc17.x86_64 8/20 Updating : kernel-headers-3.1.0-0.rc9.git0.3.fc17.x86_64 9/20 Installing : kernel-3.1.0-0.rc9.git0.3.fc17.x86_64 10/20 grubby fatal error: unable to find a suitable template Cleanup: kernel-devel-3.1.0-0.rc6.git0.0.fc17.x86_64 11/20 Cleanup: kernel-headers-3.1.0-0.rc9.git0.0.fc17.x86_64 12/20 Cleanup: kernel-3.1.0-0.rc6.git0.0.fc17.x86_64 13/20 grubby fatal error: unable to find a suitable template grubby: doing this would leave no kernel entries. Not writing out new config. Cleanup: kdebase-workspace-4.7.2-4.fc17.x86_64 14/20 Cleanup: kdebase-workspace-libs-4.7.2-4.fc17.x86_64 15/20 Cleanup: kdm-4.7.2-4.fc17.x86_64 16/20 Cleanup: libkworkspace-4.7.2-4.fc17.x86_64 17/20 Cleanup: ksysguard-libs-4.7.2-4.fc17.x86_64 18/20 Cleanup: ksysguardd-4.7.2-4.fc17.x86_64 19/20 Cleanup: kernel-tools-3.1.0-0.rc9.git0.0.fc17.x86_64 20/20 Verifying : ksysguardd-4.7.2-4.fc17.x86_64 20/20 Removed: kernel.x86_64 0:3.1.0-0.rc6.git0.0.fc17 kernel-devel.x86_64 0:3.1.0-0.rc6.git0.0.fc17 Installed: kernel.x86_64 0:3.1.0-0.rc9.git0.3.fc17 kernel-devel.x86_64 0:3.1.0-0.rc9.git0.3.fc17 Updated: kdebase-workspace.x86_64 0:4.7.2-5.fc17 kdebase-workspace-libs.x86_64 0:4.7.2-5.fc17 kdm.x86_64 0:4.7.2-5.fc17 kernel-headers.x86_64 0:3.1.0-0.rc9.git0.3.fc17 kernel-tools.x86_64 0:3.1.0-0.rc9.git0.3.fc17 ksysguard-libs.x86_64 0:4.7.2-5.fc17 ksysguardd.x86_64 0:4.7.2-5.fc17 libkworkspace.x86_64 0:4.7.2-5.fc17 Complete! -- But in fact grub.conf did get updated. # cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,4) # kernel /vmlinuz-version ro root=/dev/mapper/VolGroup-lv_root # initrd /initrd-[generic-]version.img #boot=/dev/sda default=0 timeout=5 splashimage=(hd0,4)/grub/splash.xpm.gz hiddenmenu title Fedora (3.1.0-0.rc9.git0.3.fc17.x86_64) root (hd0,4) kernel /vmlinuz-3.1.0-0.rc9.git0.3.fc17.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_M
grubby and the transition from grub to grub2
How does grubby decide which boot loader is running? I have a system upgraded from grub to grub2. I've yum erased grub and grub-efi. I also move/renamed /boot/grub elsewhere. Is that sufficient for grubby to update the next kernel install via grub2? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji rawhide broken
On Sat, Oct 22, 2011 at 05:30, Iain Arnell wrote: > Is anyone able to fix koji rawhide buildroot? > > DEBUG util.py:247: Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 > (build) > DEBUG util.py:247: Requires: grubby >= 8.3-1 > DEBUG util.py:247: Installing: grubby-8.2-1.fc17.i686 (build) > DEBUG util.py:247: grubby = 8.2-1.fc17 > DEBUG util.py:247: You could try using --skip-broken to work around > the problem > DEBUG util.py:247: You could try running: rpm -Va --nofiles --nodigest > DEBUG util.py:247: Error: Package: kernel-3.1.0-0.rc10.git1.1.fc17.i686 > (build) > DEBUG util.py:247: Requires: grubby >= 8.3-1 > DEBUG util.py:247: Available: grubby-8.2-1.fc17.i686 (build) > DEBUG util.py:247: grubby = 8.2-1.fc17 > > It looks like kernel-3.1.0-0.rc10.git1.1.fc17 needs to be untagged > until grubby-8.3-1.fc17 is built and available. > > Looks like the fc17 version didn't get built but you can grab the fc16 version from koji. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xorg-x11 gone squiffy in rawhide?
I had the same problem. I'm using the intel driver. Backed out xorg to a previous version. darrell On Thu, Apr 21, 2011 at 08:40, Paul Johnson wrote: > Hi, > > Just done quite a big update to my rawhide box, performed a reboot and have > been left without an x server. I thought it was the xserver, so downgraded > to 1.10.99.1-2.20110418.fc16, but still the same problem. > > I'm getting a segfault at adress 0xb2b4c using the neuveau driver > > Help! I'm reduced to using a win7 box > > TTFN > > Paul > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xorg-x11 gone squiffy in rawhide?
I'm running 1.10.0-5.fc16 (There were two 1.10.99 newer versions) darrell On Thu, Apr 21, 2011 at 08:48, Paul Johnson wrote: > Hi, > > On 21 April 2011 16:45, darrell pfeifer wrote: > >> I had the same problem. I'm using the intel driver. >> >> Backed out xorg to a previous version. >> >> I did that too, but no go :( > > TTFN > > Paul > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is Rawhide supposed to be useful?
On Tue, May 10, 2011 at 09:04, Adam Jackson wrote: > On 5/10/11 11:34 AM, Jonathan Corbet wrote: > > > Things breaking in Rawhide are not a surprise; indeed, if it doesn't > > occasionally bite the hand that's feeding it, somebody probably isn't > > trying hard enough. But if it can remain this fundamentally broken for > > weeks because the relevant developer forgot to fix it, it's hard not to > > conclude that nobody is really running it. > > In the week before F15 change freeze, are you really surprised that > nobody's running the F16 dumping ground? > > > I am running the F16 dumping ground. I do daily updates to rawhide and report bugs as I see them. In other words, I'm always running the "rolling" release. Breakage for those of us who live on this edge is something we're familiar with. It would just be helpful to have the occasional heads-up for known breakages, rather than having to discover them in unpleasant ways. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome borked?
On Mon, Jun 20, 2011 at 04:41, Paul Johnson wrote: > Hi > > >> Its both a black screen of death and a black box process. Very > frustrating. > >> > >> In gnome 2 when the session crashed one could still run apps (add the > term > >> shortut to nautilus, right click on the desktop and you have a term to > launch > >> a wm and a browser to look for solutions). In gnome 3 you're finished. > > > > Well it is just a window, you can alt-f4 out of it. > > tried that - you get windows up with no minimise bar etc. Close them > and you get the logout warning again... Something is borked - looks > like gnome-shell here. > > It might go beyond gnome shell. For me, gdm also failed. gnome-setting-daemon seemed to be crashing. I backed that out and then a different crash ensued. After several months of trying out gnome and trying to keep an open mind, it was a good opportunity to switch to kde for a while. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome borked?
On Mon, Jun 20, 2011 at 13:04, Clyde E. Kunkel wrote: > On 06/20/2011 06:46 AM, Paul Johnson wrote: > > Hi, > > > > After doing a rather large update to my rawhide box, it seems that it > > no longer wants to play fair with Gnome giving a very unfriendly > > "Something has gone wrong which I can't recover from. You should > > logout and try again" message. Other than some desklet errors, nothing > > seems to be wrong (obviously it is though). > > > > Any ideas what the problem is or how to fix it? > > > > PFJ > > main.js threw exception: Error: FIXME: Only supporting fixed size ARRAYs > > https://bugzilla.redhat.com/show_bug.cgi?id=714472 > > Waiting for a fix...too many dependencies to revert gnome-shell I guess. > > > With the latest gnome-shell and gnome-settings-daemon from koji, gnome is back working again. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100213 changes
Mike, On Sat, 2010-02-13 at 17:00 +, Rawhide Report wrote: > > kernel-2.6.33-0.44.rc8.git0.fc13 > > > > * Fri Feb 12 2010 Chuck Ebbert 2.6.33-0.44.rc8 > > - 2.6.33-rc8 > > > > * Fri Feb 12 2010 Chuck Ebbert > > 2.6.33-0.43.rc7.git6 > > - 2.6.33-rc7-git6 > > > > * Thu Feb 11 2010 Chuck Ebbert > > 2.6.33-0.42.rc7.git5 > > - 2.6.33-rc7-git5 > > - Drop merged patches: > > fix-conntrack-bug-with-namespaces.patch > > commit ad60a9154887bb6162e427b0969fefd2f34e94a6 from > > git-bluetooth.patch > > > > * Mon Feb 08 2010 Josh Boyer > > - Drop ppc ps3_storage and imac-transparent bridge patches > > Anyone else having problems getting this kernel (even the .40 before it) > to get anywhere past the grub menu, much less boot? > > grubby was messed up for a bit. https://bugzilla.redhat.com/show_bug.cgi?id=562514 You may have to edit you grub.conf. Look for missing lines compared to working stanzas. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100213 changes
2010/2/13 Tomasz Torcz > On Sat, Feb 13, 2010 at 11:35:53AM -0600, Bruno Wolff III wrote: > > On Sat, Feb 13, 2010 at 09:27:59 -0800, > > darrell pfeifer wrote: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=562514 > > > > > > You may have to edit you grub.conf. Look for missing lines compared to > > > working stanzas. > > > > That might not be the problem here. I am getting the initrd lines added > > now when I install new kernels. And when you have this problem an obvious > > error messages is displayed (at least when you have grub set to let you > > see what's happening when you boot). > > Please double-check initrd paths. Mine had superflous "/boot" in them. > As I have separate /boot partitions, grub.conf should have just > "initrd /initrams-...", without "/boot/". > > I've also had a couple of other oddities this week that have caused hangs. A version of rsyslog was causing the boot to hang. Moving it out of init.d for a while fixed it until a new version came along. The latest intel driver isn't working for me. I backed out to the next oldest version. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
initramfs not being created for last couple of kernels
The last couple of rawhide kernels (including the one from today) have failed to boot for me because there is no initramfs. There is no dracut log, the initrd line is missing from the grub2 paragraphs and there is no corresponding /boot/initramfs. Is there already a bugzilla entry for this? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: initramfs not being created for last couple of kernels
On Fri, Dec 16, 2011 at 11:22, Josh Boyer wrote: > On Fri, Dec 16, 2011 at 2:19 PM, darrell pfeifer > wrote: > > The last couple of rawhide kernels (including the one from today) have > > failed to boot for me because there is no initramfs. > > > > There is no dracut log, the initrd line is missing from the grub2 > paragraphs > > and there is no corresponding /boot/initramfs. > > We've seen this a few times without root cause. > > > Is there already a bugzilla entry for this? > > There are a couple. Do you happen to have any out-of-memory or > segfault traces in dmesg or /var/log/messages for depmod, > new-kernel-pkg, or dracut? > > > There is nothing in /var/log/messages during the yum install. There was a new dracut, but running the dracut line by hand and installing the grub2 initrd line by hand works fine. I didn't try the dracut line with the appropriate theme though (so my initramfs image is smaller than usual) darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
system clock stuck on utc
The latest rawhide/kernel leaves the system clock stuck on UTC. My local time shows up as what is really UTC. This has happened on two different systems I've updated. I'm using ntp which appears to be running just fine. Still looking for the cause. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SELinux-related Rawhide breakage today
On Wed, Feb 1, 2012 at 14:16, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > But as long as we live in the Rawhide/Non Rawhide world things are > going to be strange and mistakes are going to happen. > > Why anyone is on Rawhide and not trying out usrmove is beyond me at > this time. Rawhide is supposed to be the latest and greatest code... > > If we are going to do usrmove, then lets do it and get over the hump. > > I am on rawhide and I usually update daily (though sometimes I am on koji and update hourly to be completely insane). There are times when there is a major change when I don't update as often because I expect the change will cause problems that I don't have time to fix/troubleshoot, or know I won't be able to submit a decent bug report. There is also the need to test the next day because the fix might cause another breakage to show up. Nothing like having a fresh batch of testers. Also, thankfully, the change has not been pushed to rawhide but is available for testing elsewhere. I'm very happy that this process has started to happen for the larger changes to coordinate all the pieces that need to be in place. When the change does get moved to rawhide I'll have the decision of remaining with what I have or being part of the test at whatever state it is in. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
filesystem
As far as I've seen on the list, the /usr move stuff was supposed to be confined by tagging to f17-usermove so it wouldn't affect rawhide until the big switch was pulled. Trying to update from koji (which will appear in rawhide tomorrow) gives - Upgrade 2 Packages Total size: 2.0 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check ERROR You need to update rpm to handle: rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64 RPM needs to be updated You could try running: rpm -Va --nofiles --nodigest There is no update to rpm available in koji. Systemd 39-3 also shows up in koji because it is tagged both for f17 and f17-usrmove. Filesystem is a dependency so it won't update either. There are also several others, all with depend on filesystem (so it looks like the change to filesystem is the root of the problem) At some point I'm more than happy to do the /usr move, but it looks like at the moment rawhide is effectively going to be forced in that direction. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: filesystem
On Fri, Feb 3, 2012 at 16:33, Jason L Tibbitts III wrote: > >>>>> "dp" == darrell pfeifer writes: > > dp> As far as I've seen on the list, the /usr move stuff was supposed to > dp> be confined by tagging to f17-usermove so it wouldn't affect rawhide > dp> until the big switch was pulled. > > Well, yes, but the big switch has actually been pulled. > > - J< > > Can you point me to the announcement? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: filesystem
On Fri, Feb 3, 2012 at 17:15, Adam Williamson wrote: > On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote: > > As far as I've seen on the list, the /usr move stuff was supposed to > > be confined by tagging to f17-usermove so it wouldn't affect rawhide > > until the big switch was pulled. > > Yes. We just pulled the big switch. :) > > The heads-up announcement that Harald did just over a week ago was a very good thing. >From the smileys it seems there is a recognition that the change is a big deal. It would be nice if a) the date of the actual switch pulling had been announced in advance. b) the (now modified) instructions in basic form were re-iterated on the list. c) the switch was pulled at a time when the main people who made the change were available rather than known to be away at a conference darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: filesystem
On Fri, Feb 3, 2012 at 17:53, Adam Williamson wrote: > On Fri, 2012-02-03 at 17:47 -0800, darrell pfeifer wrote: > > > > > > On Fri, Feb 3, 2012 at 17:15, Adam Williamson > > wrote: > > On Fri, 2012-02-03 at 16:27 -0800, darrell pfeifer wrote: > > > As far as I've seen on the list, the /usr move stuff was > > supposed to > > > be confined by tagging to f17-usermove so it wouldn't affect > > rawhide > > > until the big switch was pulled. > > > > > > Yes. We just pulled the big switch. :) > > > > > > > > The heads-up announcement that Harald did just over a week ago was a > > very good thing. > > > > From the smileys it seems there is a recognition that the change is a > > big deal. > > > > > > It would be nice if > > > > > > a) the date of the actual switch pulling had been announced in > > advance. > > b) the (now modified) instructions in basic form were re-iterated on > > the list. > > c) the switch was pulled at a time when the main people who made the > > change were available rather than known to be away at a conference > > This is still Rawhide, and it can still eat your babies. The main point > of the side branch was to allow us to back things out smoothly if it > became clear there were bigger problems than anticipated, not for > hand-holding. > > I don't believe the instructions have actually changed much if at all > from the original email, but Harald will likely send something out soon. > -- > If you continue to repeat the "eating babies" myth then it will become self-fulfilling. If you want to respect people who are testing, then maybe there is something better than "we don't have to exercise any care and we don't care, wink, wink, grin." There isn't anything in my request that seems difficult to do. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: filesystem
On Sat, Feb 4, 2012 at 16:27, Harald Hoyer wrote: > Am 04.02.2012 02:47 schrieb "darrell pfeifer" : > > > c) the switch was pulled at a time when the main people who made the > change were available rather than known to be away at a conference > > > > We are reading, we have laptops, we can fix things what's your problem? > > > In a previous comment I said: "The heads-up announcement that Harald did just over a week ago was a very good thing.". Thank you for being excellent to me. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd and svn problems (rawhide)
On Mon, Jan 3, 2011 at 08:53, Paul F. Johnson wrote: > > > First is httpd (apache). > > I can do /etc/init.d/httpd stop and the server stops, but when I try to > start the server I get > > Starting httpd (via systemctl): Job failed. See system logs and > 'systemctl status' for details. > > systemctl status httpd.service shows > > httpd.service - LSB: start and stop Apache HTTP Server > Loaded: loaded (/etc/rc.d/init.d/httpd) > Active: failed since Mon, 03 Jan 2011 16:39:18 +; 33s ago > Process: 3902 (/etc/rc.d/init.d/httpd stop, code=exited, > status=0/SUCCESS) > Process: 1959 (/etc/rc.d/init.d/httpd start, code=exited, > status=1/FAILURE) >Main PID: 2054 (code=exited, status=1/FAILURE) > CGroup: name=systemd:/system/httpd.service > └ 2086 /usr/sbin/httpd > > cat /var/log/messages | tail is also unhelpful > > Jan 3 16:41:34 PB3 systemd[1]: httpd.service: control process exited, > code=exited status=1 > Jan 3 16:41:34 PB3 systemd[1]: Unit httpd.service entered failed state. > > The stop command leaves one httpd process running. Kill it off first. httpd fails to start because it is trying to create a file in /var/run/httpd but the directory doesn't exist. As a temporary workaround I've been 1) stop httpd 2) kill the last remaining httpd 3) create /var/run/httpd 4) start http There is a outstanding bug that Lennart created. I also expect that the script will be converted sometime to work natively with systemd. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: possibly rough day in rawhide
Thanks for the warning (they really are appreciated). I updated to koji from the last hour, just to be a bit insane. With all the gnome and glib changes in place, gnome gets to the point of displaying the desktop icons. The panel never appears and the three desktop icons keep flashing rapidly, like it is trying to restart. ctl-alt-backspace doesn't kill it. .xsession-errors says nm-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. polkit-gnome-authentication-agent-1: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gnome-screensaver: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. gnome-volume-control-applet: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. (gnome-panel:3972): EggSMClient-WARNING **: Failed to connect to the session manager: IO error occured opening connection The application 'gnome-panel' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed -- darrell On Mon, Jun 21, 2010 at 12:01, Matthias Clasen wrote: > Just a quick warning: > > I have built a glib update that affects some users of GDbus and other new > apis. We'll try to get everything straightened out by tomorrow, but you > never know... > > > Matthias > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 23, 2010 at 18:26, Lennart Poettering wrote: > Heya, > > I have just uploaded a new systemd and a new upstart package which make > systemd the default init system for Rawhide. The scheme I followed makes > sure that in case systemd actually breaks systems there is an easy path > back to upstart. And here's how it works: > > - "upstart" and "systemd" are now parallel installable. When you upgrade > rawhide you will get both installed. (we'll drop upstart eventually, > but during the testing phase i made sure to explicitly install both, > so that there is a safe backup init system) > > > Just gave it a try with the koji of moments ago. ---> Package systemd-sysvinit.x86_64 0:4-3.fc14 set to be installed --> Processing Dependency: systemd = 4-3.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 --> Processing Dependency: upstart >= 0.6.5-6.fc14 for package: systemd-sysvinit-4-3.fc14.x86_64 ---> Package systemd-units.x86_64 0:4-3.fc14 set to be updated --> Running transaction check ---> Package systemd.x86_64 0:4-3.fc14 set to be installed ---> Package upstart.x86_64 0:0.6.5-7.fc14 set to be updated --> Processing Dependency: sysvinit-userspace for package: upstart-0.6.5-7.fc14.x86_64 --> Running transaction check ---> Package upstart-sysvinit.x86_64 0:0.6.5-7.fc14 set to be installed --> Processing Conflict: systemd-sysvinit-4-3.fc14.x86_64 conflicts upstart-sysvinit --> Processing Conflict: upstart-sysvinit-0.6.5-7.fc14.x86_64 conflicts systemd-sysvinit --> Finished Dependency Resolution Error: systemd-sysvinit conflicts with upstart-sysvinit Error: upstart-sysvinit conflicts with systemd-sysvinit You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Sat, Jul 24, 2010 at 23:34, Kevin Fenzi wrote: > >> > > First it seems that my boot would fail. It was unable to find or run a > 'default.target' and would hang. Unfortunately it advises you to check > the logs, but since syslog isn't up yet and you can't do anything to > look at dmesg thats not very helpfull. ;( > > If there is no /etc/systemd/system/default.target could we fall back to > a single user target? > > Also, in my switchover, I got no getty's setup by default. Happily I > was able to figure out how to add them here by looking at the FAQ (once > I found it. ;) > > What symbolic link did you set to get a graphical target? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
I installed the latest systemd and added the appropriate symbolic link to graphical startup. My system hangs when almost complete at the plymouth throbber. In text mode it gets to the end of starting services and hangs. gdm never starts. In /var/log/messages, these seem to be the suspicious lines Jul 28 14:21:26 darrell init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:26 darrell kernel: init[1]: Job dev-mapper-vg_darrell\x1dlv_root.device/start timed out. Jul 28 14:21:35 darrell init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c.device/s tart timed out. Jul 28 14:21:35 darrell kernel: init[1]: Job dev-disk-by\x1duuid-f060d5d3\x1ddef6\x1d4247\x1d9162\x1da810e55ca01c. device/start timed out. df shows the volume as /dev/mapper/vg_darrell-lv_root Any suggestions? darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, Jul 28, 2010 at 19:33, wrote: > Add init=/sbin/upstart to the end of the kernel line and it will boot up > using upstart. Last lines in my boot read failing to load default.service > and then failing to start default.service. > > Check one of the recent previous messages. ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target Will solve that problem and get you a bit further along the way. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Wed, Jul 28, 2010 at 21:20, wrote: > I found a fix on bugzilla: > rpm -e --nodeps systemd-units > yum install systemd-units > Which created the symlinks and default.service which seemed to be missing, > and allowed the boot to finish, but I may have been to quick to use it. One > CPU core is at maximum and Chrome won't open, so I'm temporarily back to > upstart till I get time to look at it further. > > https://bugzilla.redhat.com/show_bug.cgi?id=618315 > > > Thanks for the info and the bugzilla. Reinstalling systemd-units got me a mostly working system. I also had the same problem with one core using 100% CPU, in my case for Xorg. Added my comments to the bug. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 has been branched!
On Fri, Jul 30, 2010 at 10:00, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/30/2010 06:00 AM, John Poelstra wrote: > > Jesse Keating said the following on 07/29/2010 09:03 PM Pacific Time: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> https://fedoraproject.org/wiki/Branch_Freeze_Policy > >> > >> I know it's been a rough couple of days here, python-2.7 and boost > >> rebuilds creating build havoc, systemd creating some interesting > >> confusion, and dist-git to top it all off. But we'll work through it as > >> best as we can, as we always do. Onward into the future! > >> > Are the koji static repos coming back soon? Current rawhide is mid-way through the boost/python havoc. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 has been branched!
On Fri, Jul 30, 2010 at 10:45, Dennis Gilmore wrote: > On Friday, July 30, 2010 12:24:06 pm darrell pfeifer wrote: > > On Fri, Jul 30, 2010 at 10:00, Jesse Keating > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On 07/30/2010 06:00 AM, John Poelstra wrote: > > > > Jesse Keating said the following on 07/29/2010 09:03 PM Pacific Time: > > > >> -BEGIN PGP SIGNED MESSAGE- > > > >> Hash: SHA1 > > > >> > > > >> https://fedoraproject.org/wiki/Branch_Freeze_Policy > > > >> > > > >> I know it's been a rough couple of days here, python-2.7 and boost > > > >> rebuilds creating build havoc, systemd creating some interesting > > > >> confusion, and dist-git to top it all off. But we'll work through > it > > > >> as best as we can, as we always do. Onward into the future! > > > > Are the koji static repos coming back soon? Current rawhide is mid-way > > through the boost/python havoc. > > > > darrell > static repos have long been deprecated > koji creates a latest link each time a newRepo task finishes > http://kojipkgs.fedoraproject.org/repos/dist-rawhide/latest/x86_64/ for > instance > > I had been pointing to http://koji.fedoraproject.org/static-repos/ <http://koji.fedoraproject.org/static-repos/>for the longest time. I'll update it. thanks. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 has been branched!
On Fri, Jul 30, 2010 at 10:45, Dennis Gilmore wrote: > On Friday, July 30, 2010 12:24:06 pm darrell pfeifer wrote: > > On Fri, Jul 30, 2010 at 10:00, Jesse Keating > wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On 07/30/2010 06:00 AM, John Poelstra wrote: > > > > Jesse Keating said the following on 07/29/2010 09:03 PM Pacific Time: > > > >> -BEGIN PGP SIGNED MESSAGE- > > > >> Hash: SHA1 > > > >> > > > >> https://fedoraproject.org/wiki/Branch_Freeze_Policy > > > >> > > > >> I know it's been a rough couple of days here, python-2.7 and boost > > > >> rebuilds creating build havoc, systemd creating some interesting > > > >> confusion, and dist-git to top it all off. But we'll work through > it > > > >> as best as we can, as we always do. Onward into the future! > > > > Are the koji static repos coming back soon? Current rawhide is mid-way > > through the boost/python havoc. > > > > darrell > static repos have long been deprecated > koji creates a latest link each time a newRepo task finishes > http://kojipkgs.fedoraproject.org/repos/dist-rawhide/latest/x86_64/ for > instance > > This looks like it hasn't been updated since 06:38 this morning (so newrepo isn't running?) darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] systemd is now the default init system in rawhide
On Fri, Jul 30, 2010 at 14:05, Adam Williamson wrote: > On Wed, 2010-07-28 at 21:56 -0700, darrell pfeifer wrote: > > > I also had the same problem with one core using 100% CPU, in my case > > for Xorg. > > I've filed a bug on this - > https://bugzilla.redhat.com/show_bug.cgi?id=619889. > -- > Speaking of blockers, I don't know if this qualifies, but it pretty much makes X unusable. https://bugzilla.redhat.com/show_bug.cgi?id=602910 I've also had trouble with the latest X not being usable at all on my laptop (Just a small start of a gnome window in about 1/6 of the screen) I haven't filed a bug yet (gun-shy since restoring after a dead X is really tedious, even with my "working X rpm's" backup. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On Tue, Jun 12, 2012 at 9:30 AM, Adam Williamson wrote: > On Tue, 2012-06-12 at 11:08 -0400, Jay Sulzberger wrote: > > > Let Fedora help bring to market better hardware. > > > > Do not agree that Microsoft should have the Hardware Root Key on > > just about all x86 style computers for sale next year. > > That tide still appears to be coming in despite your commands, Your > Majesty... > - > It isn't particularly fair to do one post telling someone they are being un-excellent, followed immediately by another post which is un-excellent. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Latest rawhide may destroy /boot
Last night on my rawhide laptop I installed kernel 3.7.0-0.rc6.git4.1.fc19. Upon reboot I got a grub shell prompt. Turns out my /boot was empty. I've been installing and using pretty much every recent kernel, including the nodebug ones. I notice that I also installed a newer version of dracut a couple of days ago. I'm pretty sure I've installed and run several kernels since the newer dracut, so I'm not sure it is the problem. For the record, my workaround was Boot an F17 resuce disk chroot /mnt/sysimage Insert a slightly old F18 disk (that didn't have rescue mode) rpm --oldpackage of the kernel and dracut off the F18 disk reboot darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
