Re: Problem installing Vmware Workstation 10.0.3
On Sat, Oct 25, 2014 at 4:35 PM, Lawrence E Graves wrote: > It will not compile. Is there a patch available to fix this problem. I have > searched the web and vmware.com I personally could not find one. Thank for > your help. Follow the instructions here: https://wiki.archlinux.org/index.php/VMware#Configuration You'll need all 3 patches on a fresh F21 system. Note that the awesome Arch wiki people always keep this up-to-date, so keep an eye on it if newer kernels break things again or you need to do a new install. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta / Final release criteria for Workstation
On Mon, Sep 29, 2014 at 5:27 PM, Adam Williamson wrote: > Appearance is something we'd want to enforce if it were actually done, > but I get the impression the Qt variant of Adwaita isn't actually > written yet. There's no need for such a thing. Qt renders apps with native GTK widgets when run in a GTK environment like GNOME. The only caveat is Qt 4 only supports GTK 2, so the vast majority of Qt apps will get rendered with GTK2 at the present time. As stuff moves to Qt 5, it will start getting rendered with GTK 3 when run in GNOME. So unless you consider GTK2 Adwaita ugly, a criterion for this should be okay. ;-) -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: slow mirror workaround?
On Mon, Apr 21, 2014 at 1:33 PM, Felix Miata wrote: > This time Ctrl-C and immediate repeat worked a charm. Is it a normally OK > thing to do? Isn't there some way to configure Yum to see when ETA on a > package is and stays beyond reasonable length to try some other mirror? Oh, as for your other question: if CTRL+C works, it's safe. Yum deliberately ignores SIGINT when it would be dangerous, like when it is actually installing RPMs. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: slow mirror workaround?
On Mon, Apr 21, 2014 at 1:33 PM, Felix Miata wrote: > This time Ctrl-C and immediate repeat worked a charm. Is it a normally OK > thing to do? Isn't there some way to configure Yum to see when ETA on a > package is and stays beyond reasonable length to try some other mirror? In yum.conf, you can set "minrate" to a bandwidth in bytes per second, and then set "timeout" to a time in seconds. If the download speed of a package falls below the bandwidth set in "minrate" for a period longer than the time set in "timeout", yum aborts the download and tries another mirror. For more information about these options, see `man yum.conf`. The default setting is geared toward only dropping connections that are basically totally screwed. The yum developers can't know what kind of connection you have in advance, and setting it too high will result in yum never working for those unfortunate souls with terrible bandwidth. It's basically a choice between slow mirrors aggravating people with fast connections or yum just flat out not working with slow connections. I understand why they went with the latter. :-) FWIW, dnf seems to have different logic for this that seems to work better in my limited experience, so you might also want to try that. (This also means that this problem will go away for everyone in a future Fedora release. :-) -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Criterion revision proposal: KDE default applications
On Fri, Dec 13, 2013 at 3:54 AM, Gene Czarcinski wrote: > Indeed! There are environments/situations where there is no network > connectivity (at least to the Internet) and never will be. It is this type > of situations that will require a DVD. I run Fedora on a system that exists in on the side of a mountain in the remote part of the Arizona desert that is lucky to even have electricity and running water. No Internet, except tethering on my smartphone in an area that doesn't even have 3G coverage. (Internet access would sort of defeat the usual purpose of me venturing out there, anyway. That machine wouldn't even exist period if it were not used by others; I'd just take my laptop out there or maybe not even that. ;-) Trying to run a `yum update` out there would probably take longer than I usually spend there, and I'm not particularly worried about security updates, since the only way that system could possibly be more airgapped would be for it to exist on Mars. :-p Anyway, the DVD is _completely_ useless for this system. Pretty much every use case I have for this system requires packages from a certain third-party repository we all know and love, and even if Fedora contained all the packages I needed for it, they all certainly wouldn't on the DVD. Also, I really don't care about 95% of the packages on the DVD; I certainly don't need six different desktops. ;-) So instead when I refresh it from time to time, I just anaconda install onto a USB stick, yum install everything I want to it, then take it out there and dd it to the hard disk, manually making grub happy if necessary. This also allows me to configure it the way I want before I leave, so when I get out there it only takes me a few minutes to get it completely updated. I guess I could craft a kickstart and use livecd-creator instead, but that seems like more hassle than it's worth. Plus I keep that USB stick around so I have something that matches that system exactly at home, so if I ever decide I want to install some more stuff on it I can be sure I download all the RPMs necessary for a complete transaction. (Supposedly there's some offline download/install support in PackageKit for that usecase too, but it doesn't seem to be documented very well. The only reason I even know it exists is because hughsie asked on his blog if he could kill it. ;-) So if we really care about this usecase, we need to rebirth revisor or something similar so people can actually make images for their disconnected systems that have the stuff they want on them easily, instead of a grab bag of packages most of which they have no use for. For bonus points, maybe flesh out the offline update support so there's a sane way to update/install stuff on them afterward. Keeping the DVD around "because offline systems" is really just ignoring these users' actual needs. It would be nice if some development effort were put to making this actually better, but it's really an edge case that can already be handled by other, less elegant solutions like mine, so I really don't blame developers for not bothering with it. The only other use case we really have for the install DVD is for handing out at conferences, etc., and I think the multi-live DVD is a much better fit for that personally. > Another situation is where I am installing into a qemu-kvm virtual system. > Yes, there will be Internet connectivity. Yes, it is nice to have > everything updated on install. But, running with just the DVD image is a > lot faster (takes much less wall-clock time). Nowadays we have nice qcow2 images for that use case. Much better than the DVD IMHO, especially since a `yum update` is the first thing I'd do regardless... -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Thu, Oct 17, 2013 at 2:09 PM, Eric Blake wrote: > Well, now it's failing to mount on boot: Did you change anything yet? That kind of looks like the same exact bug Mike is running into. But "bg" mounts are supposed to keep trying to mount in a loop, and automounts ought not to even try to mount until you access them, so you shouldn't even be running into that?? -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Thu, Oct 17, 2013 at 12:06 AM, Mike Chambers wrote: > With the fix above, the really wait script now works. Rebooted twice to > be sure and the nfs dir got mounted both times as it should. Thanks for > that :) > > So it is nm-online that is saying it's online when really it's not? > Then obviously everything else tries to do it's thing since network > should be up? Yup. > Guess I need to change systemd bug to nm-online or whatever > bug/component that falls under. It's just NetworkManager. I went ahead and moved your bug and added a comment explaining what we figured out here. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Tue, Oct 15, 2013 at 8:33 AM, Mike Chambers wrote: > Tried your script but got an exit code, ugh can't remember it now. That was my fault, sorry. The quoting was screwed up and an escape character was transposed. (I blame Monday. :-p) The correct line should be: ExecStart=/bin/bash -c "until ifconfig p5p1 | grep '192\.168'; do continue; done" (Also make sure it's all on one line despite my mailer's insistence that it should be two. ;-) Also, come to think of it, skipping right to a ping test might be most accurate: ExecStart=/bin/bash -c "until ping -c1 8.8.8.8; do continue; done" Feel free to swap out Google's IP address for your NFS server or something if you'd like. >> 3.) NM-wait-online is working fine, but systemd isn't waiting for it >> for some reason. > > I think above is the problem, but can't swear to it.' sti Actually, looking at the log you posted in that bug, NM-wait-online is in fact returning successfully before systemd attempts to mount your NFS share, so it is indeed one of: 1.) The `nm-online` tool lies. 2.) NFS is failing for some other random reason other than the network not being up. Either way, it's not a systemd bug. Fixing really-wait-online.service as described above will narrow down whether it's 1 or 2. If it's 1, you'll already have a temporary fix working and can complain to the NetworkManager folks. If NFS mounts still fail, it is most definitely not the network, so file a bug against nfs-utils and let them try and troubleshoot their obtuse error output. > Got confused on your above temp fix. So adding home-download.mount to the > end of the Before line, in my wait.online service file? Shouldn't be necessary. As I said above, your logs indicate systemd is in fact doing what it is supposed to without this hack. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Mon, Oct 14, 2013 at 2:41 PM, Eric Blake wrote: > Dunno. Whatever I got by installing F17 with anaconda then > incrementally upgrading through F18, F19, and now F20, and where I set > up my /etc/fstab by copying the same configuration that worked for me > since F12 pre-systemd days. So it might not be ideal, but it's one of > those "it works well enough for me that I'm not going to waste time > tweaking it unless it breaks first" situations. Except that it's > noticeably broken enough at shutdown that I bothered to ask on the list :) > > The corresponding /etc/fstab entry: > > nas:/backup /mnt/backup nfs bg,user,_netdev 0 0 Okay, so the "bg" option is a little different from what most people refer to as automounting, in that it just repeatedly attempts to mount the share until it succeeds, whereas true automounting waits until you attempt to access the mount to even try to mount it. Of course, this distinction matters very little to _you_, but it might indicate what systemd is getting wrong here. I'm curious as to whether systemd even tracks the mount properly in this case. Does `systemctl status mnt-backup.mount` indicate success or failure? If it indicates success, systemd definitely should be tearing down the mount on shutdown. (systemd by design is supposed to reverse Before/After deps for stop operations.) Definitely file a bug in this instance. If it indicates failure, systemd isn't getting informed that this mount actually succeeds. You could file a bug against systemd regarding this, but their answer might just be "use real automounting if you want this to work properly." To do that, switch your "bg" mount option for "x-systemd.automount" and see if it gets unmounted properly on shutdown afterwards. Their answer could just as easily be "yeah, we need to fix this", so please do file the bug anyway, if only for the benefit of others who might run into this. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Mon, Oct 14, 2013 at 9:04 AM, Eric Blake wrote: > I've got a similar problem - I've got my laptop set up to automount an > NFS share over wifi, and frequently hit a hang during system shutdown > because systemd allows Networkmanager (and the wifi) to be taken down > before NFS is fully unmounted, where the system then stalls for several > minutes waiting for the NFS unmount that is impossible at that point. I > have no idea where to look at adding a dependency that says that yes, my > wifi network connection really must have a longer lifetime on BOTH sides > of the NFS mount point. Are you using systemd's automounting logic or plain ol' autofs? -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Mon, Oct 14, 2013 at 8:56 AM, Mike Chambers wrote: > Ok, think I've figured out the problem, but might be beyond my expertise > to fix it.. > > 1 - Network Manager is set to come online/start > 2 - Network Manger wait-online shows in log as well here. > 3 - Network Manger device itself shows up (as in I guess drivers and > assigned what name it is called, p5p1 is my wired ethernet). > 4 - Systemd tries here to mount the remote nfs directory, which fails > 5 - Network Manger actually configures itself, via dhcp, to get it's > network settings, such as IP, dns, etc.. > > So it seems, via /var/log/messages that nfs is trying to get mounted > BEFORE the network is completely configured. There are several possibilities here: 1.) DHCP on your network is slw and NetworkManager-wait-online is timing out after the default 30s waiting for it. 2.) NetworkManager-wait-online is just stupid and doesn't wait for DHCP to complete. 3.) NM-wait-online is working fine, but systemd isn't waiting for it for some reason. I believe something in the logs would indicate if it's 1. If that's the case, you can increase the timeout by copying /usr/lib/systemd/system/NetworkManager-wait-online.service to /etc/systemd/system/ (so rpm doesn't overwrite your changes on updates) and increasing the `-t` argument to `nm-online` in that file. If it's 2, file a bug against NetworkManager, which ships the `nm-online` program that is being stupid. :-p If it's 3, systemd obviously deserves the bug. > So no idea which one is wrong, either mounting gets done alot later > (guess I could add to rc.local again like used to until fixed?), or NM > needs to be configured a lot earlier. Well, lets try a more systemd-esque hack that will also identify whether the problem is 2 or 3 as described above. Drop something like this in /etc/systemd/system/really-wait-online.service: -- [Unit] Description=Really wait for the damn network Requisite=NetworkManager.service After=NetworkManager.service Wants=network.target Before=network.target network-online.target [Service] Type=oneshot ExecStart=/bin/bash -c 'until ifconfig p5p1 | grep '192.\168'; do continue; done' TimeoutSec=120 [Install] WantedBy=multi-user.target -- Remember to adjust the network interface and grep string to something that makes sense for your network, and run `systemctl daemon-reload && systemctl enable really-wait-online.service` to enable it when you're done. (And if you're aware of a better method for figuring out DHCP is done than grepping the output of `ifconfig`, feel free to use it. ;-) If mounting works after that, NM-wait-online is really the culprit and NetworkManager deserves the bug. If mounting still fails, systemd is not ordering things right and deserves the bug. And if systemd is to blame, fix your system nao by explicitly ordering your little wait-online service before the mount unit (e.g. mnt-foo.mount) discussed upthread. Just add said mount unit to the end of the Before line in that file. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Sun, Oct 13, 2013 at 8:02 AM, Mike Chambers wrote: > Got this from the logs just after a reboot a few mins ago... > > Oct 13 09:58:45 scrappy systemd: Starting NFS file locking service > Oct 13 09:58:45 scrappy mount: mount.nfs4: mount system call failed > Oct 13 09:58:45 scrappy systemd: home-download.mount mount process > exited, code=exited status=32 `man 8 mount` sez an exit code of 32 means "mount failed". Very helpful. >:-( > Oct 13 09:58:45 scrappy systemd: Failed to mount /home/download. > Oct 13 09:58:45 scrappy systemd: Dependency failed for Remote File > Systems. > Oct 13 09:58:48 scrappy rsyslogd: log message from journal doesn't have > MESSAGE > Oct 13 09:58:45 scrappy systemd: Unit home-download.mount entered failed > state. One thing I forgot that's always an issue...do you use NetworkManager or ye olde network service? If it's the former, try running `systemctl enable NetworkManager-wait-online` and rebooting. Sometimes systemd tries to mount stuff before NM gets the network up. (I thought they had fixed this to just do the right thing when remote FSes were in the mix nowadays, but maybe I'm mistaken. Or it broke again with F20??) Also, double-check your network connection settings and make sure the "system connection" box is checked. I'm pretty sure this is the default (or maybe even not configurable) with GNOME, but other desktops' NM UIs sometimes don't set this, so the network doesn't come up on boot by default. If all that fails, is the above just the output from `systemctl status`? `journalctl -b` might reveal some messages from the kernel that systemctl's magic log grepper might not be picking up. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 20 nfs
On Sat, Oct 12, 2013 at 8:05 AM, Mike Chambers wrote: > On Thu, 2013-10-10 at 11:34 +0200, Adam Williamson wrote: >> Check 'remote-fs.target': this is the systemd target that controls >> mounting anything considered a 'remote' filesystem, similar to the old >> 'netfs' service. > > Looked and it is there, but not sure what to look for besides being > there. Any particular info that should be there? Or can someone take a > look after a fresh install that might know the program better to see if > it's missing something? Actually, you need to check the status of the mount unit itself. (Which is required by remote-fs.target.) They're named by switching out slashes for for dashes in the mount point. For instance, if you have a nfs share mounted on /mnt/foo, it's mount unit is named "mnt-foo.mount" and you can find out what's going on with it by running `systemctl status mnt-foo.mount`. You can run just plain `systemctl` for a list of units if you need to. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: maintaining minimal
On Sat, Sep 28, 2013 at 10:50 PM, Felix Miata wrote: > In trying to find a way to reach a state similar to #2 using KDE instead of > Gnome, I had tried installing several KDE apps individually to see what > didn't seem to be required, since if trying to install all the apps I wanted > at once I would have no chance of discerning what might be responsible for > particular items of bloat. What I'd actually like is no more than is > technically required by the DE to run what I need: Konsole, Konqueror, > Ksnapshot, Kcalc and Mozilla-built binaries. It seems before writing here I > should have tried such after adding the above listed intermediates, as the > dep count plummeted. A super-minimal KDE installation isn't really possible right now due to the monolithic nature of the KDE libraries and runtime in KDE 4. KDE Frameworks 5 aims to fix this, so it should be possible in the future: http://dot.kde.org/2013/09/25/frameworks-5 If you're looking for a lightweight Qt-based desktop, check out Razor-qt: http://razor-qt.org/ or just `yum install razorqt` -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: how do I tell what release yum upgrade will give me?
On Mon, Jul 29, 2013 at 10:51 PM, Adam Williamson wrote: > There isn't a particularly easy way, you just have to make sure > fedora-release-rawhide is installed and tweak the enabled repos, AFAIK. > I guess if you edited the .repo files directly they wouldn't get > overridden on updates? I haven't really played with it much, to be > honest, I just adjust as necessary for whatever I'm trying to do as I go > along. That won't work. fedora-release just Obsoletes fedora-release-rawhide at the branch point [1] so fedora-rawhide.repo is removed completely. The only way to avoid it would be to prevent yum from honoring the obsoletes the first time you update after the branch, but that really isn't any easier than just reinstalling fedora-release-rawhide after the fact. -T.C. [1] http://pkgs.fedoraproject.org/cgit/fedora-release.git/commit/?h=f19&id=756e5e18042c4f820fb6059e640747a7a2b1e2a0 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Negative karma for missing update descriptions?
On Jul 14, 2013 6:21 PM, "Ankur Sinha" wrote: > > On Fri, 2013-07-05 at 11:59 +1000, Ankur Sinha wrote: > > Getting back on topic, I propose the wiki page be modified to say that > > karma only depends on whether the package update works or not, > > irrespective of the update description. A 0 karma comment can be > > dropped, but not a -1. > > Another instance: > > https://admin.fedoraproject.org/updates/FEDORA-2013-11668/dvd > +rw-tools-7.1-13.fc19 > > The update has got -3 karma for descriptions. This will *never* reach > users and fix their bugs in this state! Huh? The maintainer fixed the description and I just gave it the last +1 it needed to autopush stable. This worked exactly like it was supposed to. > Adam, I think this has gone too far now :( > > A clear set of guidelines/policy on update descriptions and whether > karma depends on them needs to be put in place before a war breaks out. So far the only standard being enforced is that the contents of the update description not be "Here is where you give a description of your update." That's not really that unreasonable. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: need PreferredMode troubleshooting help [solved]
On Fri, Jun 21, 2013 at 12:07 AM, Adam Williamson wrote: > KDE has a checkbox for *everything in the world*, KScreen actually "fixes" this. The old display config pretty much exposed every xrandr option under the sun, and just as tersely. (In fact, I think it just shelled out to xrandr and only did so if you configured something, which is why it never messed with Felix's config.) KScreen's config is much nicer and it mostly just Does The Right Thing. > so I'm sure you can > reverse/reconfigure it somewhere. System Settings > Display > I haven't used it, but I'm assuming it > can set resolution and refresh rate as well as multi-monitor > positioning, hence useful for single monitors. Yup. :-) -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: need PreferredMode troubleshooting help [solved]
On Thu, Jun 20, 2013 at 10:15 PM, Felix Miata wrote: > That was it. 'yum remove kscreen' wanted to remove kde-workspace. 'rpm -e > --nodeps kscreen' mostly fixed it. There's a strong flicker I can't recall > ever seeing before from the Radeon's DVI output (also in SUSE) as if running > below 60 refresh, while actually running 75, but its VGA and Intel's output > work normally. 'zypper se -s reen' finds no similar 13.1 package for 4.10.4. You can just disable kscreen without resorting to forced rpm commands if that's what you want: qdbus org.kde.kded /kded org.kde.kded.unloadModule kscreen qdbus org.kde.kded /kded org.kde.kded.setModuleAutoloading kscreen false > Now the questions have become: > > 1-why is it required for single display F19 KDE users? As Adam points out, it's very useful for single monitor setups as well. > 2-does it need to by default usurp xorg.conf directives? As I understand it, expecting X to handle anything more than one display sanely is unpossible, so if the desktops want to provide a sane experience in this regard, they need to handle things themselves. I'm sure that GNOME and KDE both wouldn't be doing this if they didn't have a good reason. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta TC4 karma requests
On Sun, May 12, 2013 at 3:24 PM, Chris Murphy wrote: > It's sorta messy to use GRUB2-EFI as a boot manager. Ideally the firmware > manufacturer would supply a decent GUI boot manager so you can choose the OS, > rather than rely on GRUB acting as a boot manager. > > The better alternative right now on UEFI computers, is rEFInd or gummiboot as > the substitute boot manager, which then points to the native boot manager for > Windows and Linux (on Linux that's EFI STUB which is built into the kernel). > This totally obviates GRUB2, and I understand that I'm not actually answering > your question. I already use gummiboot, since GRUB2 can't boot Fedora on my system. [1] My main reason for trying this out was to see if GRUB2 could boot Windows, as that might be an interesting datapoint to add to that bug. -T.C. [1] https://bugzilla.redhat.com/show_bug.cgi?id=951761 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta TC4 karma requests
On Fri, May 10, 2013 at 4:14 PM, Adam Williamson wrote: > If anyone has a UEFI install of Windows and can test installing F19 Beta > TC4 alongside it, please do - the os-prober update should mean that the > Windows install will now be present in Fedora's grub menu (before it was > not). I haven't got a chance to try installing TC4, but this doesn't seem to work as intended on a fully up-to-date existing F19 install: % rpm -q grub2 os-prober grub2-2.00-16.fc19.x86_64 os-prober-1.58-1.fc19.x86_64 # grub2-mkconfig -o /boot/EFI/fedora/grub.cfg Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.9.1-301.fc19.x86_64 Found initrd image: /boot/initramfs-3.9.1-301.fc19.x86_64.img Found linux image: /boot/vmlinuz-3.9.0-301.fc19.x86_64 Found initrd image: /boot/initramfs-3.9.0-301.fc19.x86_64.img Found linux image: /boot/vmlinuz-3.9.0-0.rc8.git0.2.fc19.x86_64 Found initrd image: /boot/initramfs-3.9.0-0.rc8.git0.2.fc19.x86_64.img Found linux image: /boot/vmlinuz-0-rescue-9388a5eb453d59f4fd98567b37061720 Found initrd image: /boot/initramfs-0-rescue-9388a5eb453d59f4fd98567b37061720.img Found linux image: /boot/vmlinuz-3.9.1-301.fc19.x86_64 Found initrd image: /boot/initramfs-3.9.1-301.fc19.x86_64.img Found linux image: /boot/vmlinuz-3.9.0-301.fc19.x86_64 Found initrd image: /boot/initramfs-3.9.0-301.fc19.x86_64.img Found linux image: /boot/vmlinuz-3.9.0-0.rc8.git0.2.fc19.x86_64 Found initrd image: /boot/initramfs-3.9.0-0.rc8.git0.2.fc19.x86_64.img Found Windows Boot Manager on Microsoft/Boot/bootmgfw.efi Windows Boot Manager is not yet supported by grub-mkconfig. done Is this supposed to work with grub2-mkconfig also, or only from anaconda? -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Beta TC3 karma requests
On May 4, 2013 6:44 PM, "Ed Greshko" wrote: > > On 05/05/13 04:08, Adam Williamson wrote: > > On Sat, 2013-05-04 at 12:57 -0700, Adam Williamson wrote: > >> Hey folks! Just wanted to let everyone know, if TC3 installation is more > >> or less working for you, please up-karma > >> https://admin.fedoraproject.org/updates/python-blivet-0.12-1.fc19,anaconda-19.24-1.fc19 > > Oh, and please don't anyone -1 the update because of the password > > masking drama. The update feedback process isn't a good way to discuss > > design decisions. There's other escalation paths for that if it proves > > necessary. (I think the masking thing was in the previous anaconda build > > too, anyhow.) > > Would the inability to select the KDE desktop, due to dependency issues, qualify for a -1? No, but a bug filed against the offending package would be considered a release blocker. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Rawhide dead slow on my laptop
On Mon, Apr 8, 2013 at 4:26 AM, Ozan Çağlayan wrote: > Hi, > > I don't know where to start for debugging but current rawhide on my > SandyBridge laptop is barely usable. Even a window switch takes 1-2 > seconds. I looked over powertop and top outputs, load average when > idle (even no gnome-terminal, ran the commands on VT) can be between > 0.8-1.1. Xorg is generally at the of top output, 30-40% CPU usage on > average. I also see some irq related stuff for iwlwifi in top output. > I was passing enable_rc6=0 to i915 but removed that but that didn't > help too. > > Is there a known issue with 3.9 kernel that you are aware of? What > should I investigate further before opening a bug in bugzilla? Rawhide kernels have debugging options enabled, which can cause significant slowdowns in many situations. Try using the rawhide-kernel-nodebug repository to get non-debug kernels for Rawhide and see if your problems persist: http://fedoraproject.org/wiki/RawhideKernelNodebug -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] Announcing the release of Fedora 18.
On 1/15/13, cornel panceac wrote: > Release Notes say: > > "For a detailed listing of all changes, refer to the Fedora Technical > Notes." > > Where can Fedora Technical Notes be found? I don't think the docs team is doing technical notes anymore; they don't seem to have been done for Fedora 17 either. They really were only marginally useful--they just listed every package that has recieved and update since the previous release of Fedora. You can get the same information out of yum. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Rawhide file-conflict gnupg <> gnupg2
On Friday, July 27, 2012, Frank Murphy wrote: > Transaction Check Error: > file /usr/share/man/man1/gpg-zip.1.gz from install of gnupg2-2.0.19-3.fc18.i686 conflicts with file from package gnupg-1.4.12-2.fc18.i686 Please file a bug against both these packages. File conflicts are forbidden by the Fedora Packaging Guidelines. -T.C. > -- > Regards, > Frank > "Jack of all, fubars" > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Seeing a lot of systemd-namespace-* directories in /tmp
On Wed, May 9, 2012 at 12:41 AM, Joachim Backes wrote: > Hi all, > > during a running F17 I always see a lot of directories in /tmp called > systemd-namespace- with owner root and colord. Can I remove > them safely? These are private tmp directories for various daemons. They're part of this new F17 feature: http://fedoraproject.org/wiki/Features/ServicesPrivateTmp They're only safe to delete if the service that is using them is no longer running or otherwise no longer needs it. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: running speakup on f17 beta
On Sat, May 5, 2012 at 8:46 AM, Hussain Kadhem wrote: > I want to get speakup working on the Fedora 17 beta installation I'm > running. IIRC, speakup is now packaged with the mainline linux kernel. > However, it doesn't seem to be present -- running modprobe > speakup_soft fails, nothing shows up with 'locate speakup', and it > isn't in /lib/modules. Any help would be appreciated. It's in the staging tree, which means it's on its way to being included in the mainline kernel but hasn't quite made it yet. If you have RPMFusion enabled, you can get the staging drivers by installing the 'kmod-staging' package. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: google-chrome transaction error...
On Thu, May 3, 2012 at 9:56 PM, Rob Healey wrote: > Greetings: > > Upon trying to install this software, I got this issue... > > Transaction Check Error: > file /usr/bin from install of > google-chrome-unstable-20.0.1123.4-135092.x86_64 conflicts with file from > package filesystem-3.1-1.fc18.x86_64 It's a problem with Google's packaging and Rawhide that they need to fix. See http://thread.gmane.org/gmane.linux.redhat.fedora.testers/98099 -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Oracle 11gR2 on F17
On Thu, Apr 26, 2012 at 12:46 PM, Tommy Pham wrote: > Hi, > > I'm having another problem installing Oracle 11gR2 on F17. I'm getting: > This is a known bug in Oracle's installer, and apparently they don't care since they don't support Fedora. There is a workaround described here: https://forums.oracle.com/forums/thread.jspa?threadID=1091616 > Has anyone tried to install Oracle 11gR2 on F17? -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: /var/log/messages permissions issue...
On Sun, Mar 18, 2012 at 8:18 PM, Rob Healey wrote: > Greetings: > > I was trying to look at the system messages this evening, and this is what I > got... > > [root@BurningBushes ~]# grep shell | /var/log/messages > -bash: /var/log/messages: Permission denied You were attempting to pipe the output of `grep shell` to a program called `/var/log/messages`. '/var/log/messages' is not executable, so bash fails with that permission denied error. Since you're missing the third argument to `grep`, it waits for input from stdin to search, which is why you had to CTRL+C to get back to the shell. Drop the pipe symbol so the command reads `grep shell /var/log/messages` and you'll instead search /var/log/messages for "shell". ;-) > It didn't display anything on my terminal window, and I had to do a > [Control] C to get out of it... -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Alert from turning off/on wireless
On Sun, Mar 11, 2012 at 10:09 AM, Steven Stern wrote: > On my (very old) laptop, I turned off the wireless (via the hardware > switch) then turned it back on, generating an alert. This action > should be allowed by the default policy. (Fedora 17) > > > SELinux is preventing NetworkManager from read access on the file > /etc/sysctl.conf. This is already fixed in git: https://bugzilla.redhat.com/show_bug.cgi?id=799591 -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: sudo-1.8.3p1-5.fc17.x86_64 breaks sudo functionality
On Wed, Feb 29, 2012 at 3:08 AM, Joachim Backes wrote: > After updating to sudo-1.8.3p1-5.fc17.x86_64, all sudo command calls > are broken. > > Example: > > sudo ls > > sudo: unable to dlopen /usr/libexec/sudoers.so: /usr/libexec/sudoers.so: > undefined symbol: sss_sudo_sudo_free_result > sudo: fatal error, unable to load plugins > > Downgrading to sudo-1.8.3p1-4.fc17.x86_64 helps. > > Anybody sees this too? This has already fixed, it's just pending going into updates-testing: https://admin.fedoraproject.org/updates/sudo-1.8.3p1-6.fc17 -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
On Wed, Feb 22, 2012 at 8:38 AM, Timothy Davis wrote: > On Wed, 2012-02-22 at 08:22 -0700, T.C. Hollingsworth wrote: >> On Wed, Feb 22, 2012 at 8:06 AM, Timothy Davis wrote: >> > Once again grub2 has installed dozens (at least 20) different entries in my >> > boot menu. I understand that Fedora is bleeding edge and not for the feint >> > of heart >> > I accept that and have no problem tweaking anything. But come on now! I >> > feel >> > like I should just rewrite the mkconfig program. >> > My system is as follows: 160Gb IDE (Windows 7), 120Gb IDE (stuff ext4), >> > 160Gb SATA (swap, f16x64, ubuntu 11.10, slackware 13.37, vector linux 6 kde >> > classic, f17 alpha) 250Gb SATA 4Gb boot and the rest is home >> > I know my setup is not typical and tweaking boot will always happen >> >> Is it just the (recovery mode entries bothering you? Add >> 'GRUB_DISABLE_LINUX_RECOVERY=true' to /etc/default/grub kill those. >> >> -T.C. >> > It's not the recovery mode entry that bothers me, but the fact that for > all of the kernels in my boot parttion gets assigned to F17 or what > every the last distro installed. Maybe the mkconfig program isn't samrt > enought or maybe I should go ahead and write my own. You share a boot partition between all the distros? Yeah, grub2-mkconfig as it stands really has no way of figuring out which one's which in that case. You don't strictly have to edit/rewrite grub2-mkconfig, as long as Fedora is the only distro messing with GRUB. Fedora does not rerun grub2-mkconfig on update, the grub2.cfg is patched by grubby. If you go in and fix /boot/grub2/grub.cfg, it should stay. (This is *not* the case for most other distros, however.) If you do want to hack on grub2-mkconfig, it runs scripts located in /etc/grub.d/ to make up the configuration. See /etc/grub.d/README for details. Note that changes there could get clobbered on grub2 updates, so be careful. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
On Wed, Feb 22, 2012 at 8:06 AM, Timothy Davis wrote: > Once again grub2 has installed dozens (at least 20) different entries in my > boot menu. I understand that Fedora is bleeding edge and not for the feint > of heart > I accept that and have no problem tweaking anything. But come on now! I feel > like I should just rewrite the mkconfig program. > My system is as follows: 160Gb IDE (Windows 7), 120Gb IDE (stuff ext4), > 160Gb SATA (swap, f16x64, ubuntu 11.10, slackware 13.37, vector linux 6 kde > classic, f17 alpha) 250Gb SATA 4Gb boot and the rest is home > I know my setup is not typical and tweaking boot will always happen Is it just the (recovery mode entries bothering you? Add 'GRUB_DISABLE_LINUX_RECOVERY=true' to /etc/default/grub kill those. -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
