Re: Security Chip
There's no need to be concerned. You're conflating a few different issues. The security chip is a TPM, and they have been fairly common for several years. It just allows secure key storage for software that might need it. A TPM won't get in your way. The other issue is UEFI Secure Boot. There's lots of opinions on the matter, plus it's quite complicated, so I'll leave that to you to research. That being said, I received a T440S this week, which is running the same UEFI. Fedora 20 takes care of all the secure boot and UEFI setup without any issue. I am using f20 with secure boot and didn't need to configure a thing. On Friday, February 21, 2014, CS DBA wrote: > Hi All; > > I just ordered a Lenovo Thinkpad W540, > > > the specs list this: > Security Chip 2 Security Chip Enabled > > > I plan to run Fedora 20 on it. Is this something I should be concerned > about? Can it be disabled in the bios? > > Thanks in advance... > > > > > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org > -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: DNF vs. YUM
On Thu, Mar 13, 2014 at 6:44 PM, Sam Varshavchik wrote: > Jan Zelený writes: > >> On 13. 3. 2014 at 13:41:48, Tethys wrote: >> > On Thu, Mar 13, 2014 at 1:35 PM, Mark Haney >> wrote: >> > > So, let me get this straight, DNF doesn't check the (online?) repo >> > > metadata when I call 'sudo dnf update'? That's how I'm reading this. >> > > >> > > If that's true, why the devil not? >> > >> > At a guess, for marketing reasons. People see apt as being quicker >> > than yum, and in a large part that's because it doesn't update >> > metadata where yum does, so people are comparing two different things. >> > I believe that not checking metadata is retarded and I don't think >> > we're right in moving to the same architecture. But it wouldn't >> > surprise me if that's the rationale. >> >> And you are absolutely correct. >> >> The metadata are quite large and downloading them every single time is >> time consuming. There is usually no harm in getting the updates a few days >> later and if you really want to get the very latest updates, you still >> have >> options how to achieve that - either change the time period for how long >> the >> MD should be cached or run dnf clean * before you run the update. Don't do that. > And that's exactly how it's going to end up playing out, I'll bet anything > on this. Most people will simply clear the cache explicitly, before they run > dnf. Or, they'll put it in a crontab to run every night. Perhaps consulting the dnf documentation is a better option than pursuing either of these silly behaviors. man dnf.conf metadata_expire time in seconds The period after which the remote repository is checked for metadata update and in the positive case the local metadata cache is updated. The default corresponds to 48 hours. So your cron job every night could be more simply achieved by setting this to 86400, and your `dnf clean all` before every dnf option could be automatically achieved by setting it to 0. Additionally if the need arises to use intentionally use cache (even if expired), -C can be used with dnf. There's nothing to complain about here because you're given total control over this behavior. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Disable whatever is cleaning /tmp
> IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How it got > by the vetting process is beyond me. There shouldn't be anything that uses anything beyond a negligible amount of storage. Remember that there is no guarantee that /tmp data is preserved between invocations. Why would there ever be a significant amount of data stored there? From two F20 systems: for i in $(mount -l | grep '^tmpfs' | grep -o '/[^ ]*'); do sudo du -hs $i; done Server: 0 /dev/shm 720K /run 0 /sys/fs/cgroup 0 /tmp Workstation: 3.8M /dev/shm 1.1M /run 0 /sys/fs/cgroup 652K /tmp There are a number of locations for temporary files, which provide different features. /tmp is on tmpfs because the FSH standard defines that directory as so transitory that it shouldn't matter. For those that don't want to use tmpfs, use /var/tmp/. Complaints about this sort of thing are either a failure of the user or software developer to keep up to date on the file system standards. On Fri, Apr 25, 2014 at 12:03 PM, Rick Stevens wrote: > On 04/25/2014 06:05 AM, Tim issued this missive: > >> Allegedly, on or about 24 April 2014, Rick Stevens sent: >>> >>> Also note that by default, /tmp is now a tmpfs (RAMdisk) thing, so any >>> info in /tmp will NOT survive a reboot. >> >> >> What happens when you run out of RAM? Could that be the cause of /tmp >> being prematurely wiped out? > > > No, but IIRC the tmpfs filesystem created and mounted on /tmp is 50% > of your system RAM. Once that is committed, it's done. It won't use up > all of your RAM and /tmp won't get any bigger than that, but then again > half of your available RAM is no longer available for program usage. > > IMHO using a tmpfs for /tmp is a spectacularly stupid thing to do. How > it got by the vetting process is beyond me. > > -- > - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - > - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - > -- > -Beware of programmers who carry screwdrivers- > -- > > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Disable whatever is cleaning /tmp
> To mandate RAM allocation in this way will take many people, including > myself, by surprise. It's been this way on Fedora for over two years (https://fedoraproject.org/wiki/Features/tmp-on-tmpfs). Most other new distributions do it, too. From that feature page, "Solaris has been doing this since 1994. (Much like other Unixes, too.) Debian's next release defaults to tmpfs on /tmp, too. ArchLinux defaults to this as well. Ubuntu has plans for their 12.10 release." There's basically no disagreement about it among the distributions. > 50% of RAM is a *lot* of RAM, with serious performance impacts, and I do not > do this on my systems. You know that it's not a static allocation, right? If you're only using a few KB of /tmp, the file system is only consume a few KB. 50% is just the absolute maximum that can be used, and it's a default which can be controlled via mount option (or /lib/systemd/system/tmp.mount Options=size=... with systemd). I think you should do some investigation on how tmpfs works, and the benefits of this configuration before jumping to incorrect conclusions. On Fri, Apr 25, 2014 at 12:51 PM, wrote: > Justin Brown writes: > >> Complaints about this >> sort of thing are either a failure of the user or software developer >> to keep up to date on the file system standards. > > > My understanding was that file system hierarchy was supposed to be about how > files are arranged so that they would be consistent across distributions. It > should not be about whether we put file systems in RAM or on RAID or on any > particular medium. > > To mandate RAM allocation in this way will take many people, including > myself, by surprise. For many users, 50% of RAM is a *lot* of RAM, with > serious performance impacts, and I do not do this on my systems. > > > -- > David Benfell > See https://parts-unknown.org/node/2 if you do not understand the > attachment. > > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org > -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Disable whatever is cleaning /tmp
David, This doesn't make sense. Tmpfs can be swapped out, so you're gaining absolutely nothing and taking on a development and maintenance burden. IO for /tmp would have to come from disk when using tmpfs (in the case of heavy swapping) or a traditional file system either way. In the end, we're probably talking about 1MiB combined between the 4 tmpfs file systems on Fedora. On Fri, Apr 25, 2014 at 1:47 PM, wrote: > Justin Brown writes: > >> 50% >> is just the absolute maximum that can be used, and it's a default >> which can be controlled via mount option (or >> /lib/systemd/system/tmp.mount Options=size=... with systemd). > > > Thank you for telling me what to kill. > > I have way too much trouble with my systems being swap-bound to tolerate any > allocation of the sort. > > > -- > David Benfell > See https://parts-unknown.org/node/2 if you do not understand the > attachment. > > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org > -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
SNA Acceleration for Intel Graphics
I'm trying to test Intel's SNA acceleration on Haswell, but Xorg is not loading my settings. All of the documentation on enabling SNA is basically the same. Create /etc/X11/xorg.conf.d/20-intel.conf containing Section "Device" Identifier "Intel Graphics" Driver "intel" Option "AccelMethod" "sna" BusID "PCI:0:2:0" EndSection Then reboot. Unfortunately, my Fedora 20 system always keeps using UXA acceleration based on ~: grep -ie uxa -ie sna /var/log/Xorg.0.log (II) UXA(0): Driver registered support for the following operations: I've read through the full /var/log/Xorg.0.log file and don't see any sort of errors. From the beginning of the log, this section seems like the only relevant part: (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |-->Screen "Default Screen Section" (0) (**) | |-->Monitor "" (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (==) Automatically adding GPU devices Has anyone else been able to enable SNA in Fedora 20 and were any special steps needed? Thanks, Justin -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Save everybody some surprises in Fedora 22!
I've been using DNF for a year or so primarily. The one gripe that I have is that DNF tends to avoid giving useful information with broken packages. A required package version isn't available? Yum will print out tons of information on which package failed, what version is installed, and what version is available through yum. On the other hand, DNF just gives up without any useful output. Absolutely no information that there was a package conflict, much less what the details are. With Fedora embracing community repositories through COPR, the default packaging tool absolutely needs to present this information to users. There are also still situations where a user gets a Python stack trace, which is, bluntly, sloppy programming. Exceptions always need to be handled and presented in a reasonable format for users. The failure to catch exceptions instills the belief that the authors don't understand the failure modes of their application. I'll make one additional comment about how DNF doesn't go far enough to actually be useful enough to be next-generation. The slowest step for users who keep their packages generally up-to-date is the download and parsing of metadata. The Fedora OS repository metadata is over 36MiB (and completely static after release) that has to be downloaded and still takes a long time to parse. Why DNF didn't attempt to even address server-based queries or partial metadata download is beyond me. I shouldn't need to download full metadata of all packages just to figure out what needs to be updated, and similarly a package queries should happen on the remote mirror. There's no reason why every client needs to download and parse that much metadata. While DNF works pretty well and is marginally faster, it doesn't really offer that much benefit. I anticipate that we'll see DNF 2 or some other new package manager show up that at least alters the metadata situation if not going radically parallel to support simultaneous modification of many packages. On Mon, Jun 9, 2014 at 4:58 PM, Ralf Corsepius wrote: > On 06/09/2014 05:49 PM, Jan Zelený wrote: >> >> On 9. 6. 2014 at 16:41:59, Ralf Corsepius wrote: >>> >>> On 06/09/2014 02:30 PM, Matthew Miller wrote: On Mon, Jun 09, 2014 at 09:59:15AM +0200, Jan Zelený wrote: >> >> till October) will give folks plenty of time to hone their dnf skills. >> IMO, for many (majority?) it will be a drop-in replacement for yum. > > > Yes, that's the plan. There are some differences but they are all well > documented. Is the plan to actually rename dnf to yum at that point? >>> >>> >>> 1. Is there a yum compatibility test suite? It dnf is supposed to be a >>> drop-in replacement, not having one would seem grossly silly and should >>> be treated as "full stop show stopper". >>> >>> 2. If dnf is supposed to be a drop-in replacement, a more reasonable >>> approach but to force dnf upon all users by brute force, would be to >>> apply "alternatives". >>> If it is truly a drop-in replacement, that seems like the less disruptive approach for users (and scripts) everywhere. >>> >>> >>> Agreed. I regret, but so far, dnf I do not see much sense in dnf. >> >> >> Dnf is not supposed to be 100% drop-in replacement (hence the list of >> incompatibilities in the dnf documentation). I'd rather say that it's >> supposed >> to be as compatible as possible, focusing on the most widely used features >> first. > > > Well, in this case ... you don't want to hear, what I think of this. > > What you currently are doing, definitely is against the Fedora users' > interests, to say the least. > > Ralf > > > > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://admin.fedoraproject.org/mailman/listinfo/users > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Wifi losing connectivity after 1-2 minutes on F22
> It has to be an older one -- not a brand new one or you run into the same > problem of having a too-new adapter. That's not true. It varies device by device. Some new devices have excellent drivers. Always check http://linuxwireless.org/. === Gavin, Many drivers have debug mode, which will output to the kernel logger (`journalctl -k` or `dmesg`). It varies by driver, and you'll have to poke around in /sys to find it, and probably write 1 to a file. Additionally, putting wpa supplicant in debug mode `-dd` option to `/usr/lib/systemd/system/wpa_supplicant.service` might get you more information. On Fri, Jun 3, 2016 at 5:42 PM, wrote: > On Thu, 2 Jun 2016, Gavin Simpson wrote: > >> Nothing that jumps out at me. Here's the entries from the journal from >> the last time I restarted the wifi to a point where the connection is >> lost: >> >> [snip' >> >> > > Speaking as a fedora user, this has happened to me a number of times over > the years. I've posted to this and other forums each time and get the same > kind of responses of tweaking this or that (particularly the MTU). > > And... every time, it either didn't work or worked poorly. I am convinced > it was the driver. > > What I ended up doing was go out and buy a slightly-out-of-date external usb > wifi adapter. It has to be an older one -- not a brand new one or you run > into the same problem of having a too-new adapter. > > Then, I use the thing for a couple of months (or until the next version > comes out), and viola! It's magically working again. > > The laptop I'm using is a case in point. I bought it in the early days of > Fedora 22. Nothing I tried would make the damn thing go for more than about > 5 minutes. In installed Mint, and it didn't work. I installed Manjaro, and > it didn't work. > > So, I plugged in my three-year-old usb wifi adapter and chugged along with > that until Fedora 23 came out. And, voila, it worked perfectly. > > Things aren't nearly as bad as they were 20 years ago, when you had to go > out and buy an obsolete machine or else spend a month trying to make the > hardware work. But occasionally, the drivers are still not quite "there" > yet on brand new boxes. > > > billo > > -- > users mailing list > users@lists.fedoraproject.org > To unsubscribe or change subscription options: > https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines > Have a question? Ask away: http://ask.fedoraproject.org -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
