Re: [gentoo-user] what about dracut and systemd?
On Fri, Jul 28, 2017 at 9:04 PM, John Covici wrote: > On Fri, 28 Jul 2017 21:00:50 -0400, > Rich Freeman wrote: >> >> On Fri, Jul 28, 2017 at 8:52 PM, John Covici wrote: >> > I have not done a world update in a few weeks and I like to check >> > things out first before doing this. I am seeing that the latest >> > update of dracut has the -systemd as a mandatory flag. So, since I >> > have to use systemd, does this mean I can no longer use dracut -- I >> > have found dracut very nice and would be sad to give it up. >> > >> > Any ideas on what is happening here? >> >> I'm not running 045 but it looks to me that systemd is just supported >> automatically if it is installed. The USE flag was removed, but >> support was not. > > OK, thanks a lot, I wish they would have news items for such things, > or at least a changelog which seems to be missing in that directory. > I have no idea why you don't have a changelog - those are system-generated from the git logs and maintainers have nothing to do with them. The relevant commit message seems to be: commit 90bb5611b5aa9279ff3b0d4f5c25240bf4b0f9db Author: Mike Gilbert Date: Sun Jul 2 19:06:08 2017 -0400 sys-kernel/dracut: bump to 045 - Clean up ebuild code in general - Remove unnecessary version setting - Simplify gentoo.conf config file - Depend on >=sys-apps/kmod-15 for libkmod - Stop removing systemd and other modules - Drop systemd USE flag - Depend on sys-apps/coreutils[xattr] (bug 613516) Bug: https://bugs.gentoo.org/615898 Bug: https://bugs.gentoo.org/613516 Package-Manager: Portage-2.3.6_p9, Repoman-2.3.2_p77 :100644 100644 6525882cc17... 04a511a44f1... M sys-kernel/dracut/Manifest :00 100644 000... 86fddcc57bb... A sys-kernel/dracut/dracut-045.ebuild -- Rich
Re: [gentoo-user] Why bash script, that works in "Debian", does not work on "Gentoo" install CD?
On Fri, Jul 28, 2017 at 4:47 PM, Neil Bothwick wrote: > On Sat, 29 Jul 2017 00:24:09 +0700, Ста Деюс wrote: > >> But something tells me the reason of absence of the installer are >> much deeper. > > Yes, it is that no one has felt the need to devote the considerable > amount of time needed to code and test an installer that takes into > account the far wider range of choices in Gentoo. > While there are some that consider the lack of an installer some kind of virtue, I think you've really hit the crux of it here. There is no reason that Gentoo couldn't have an installer that at least gives you a default stage3 to start from, or a few alternative options. However, in the end it requires that somebody actually build it. From what I've seen when this issue comes up people fall into two categories: 1. People who really want an installer because they're struggling to get Gentoo working. Well, if they struggle to get it working chances are they're going to struggle even more to build an installer for everybody else to use. 2. People who could build an installer if they wanted to, but they don't really need to, because they either are happy with doing it manually, or already have some rough scripts that are good enough for them. Nobody is going to "ban" a Gentoo installer, and there have been points in time where people have worked on one. However, until somebody actually both wants to build one and is able to build one we probably won't have one. That isn't some kind of policy - it is just the reality of how volunteer FOSS projects work. -- Rich
Re: [gentoo-user] what about dracut and systemd?
On Fri, Jul 28, 2017 at 8:52 PM, John Covici wrote: > I have not done a world update in a few weeks and I like to check > things out first before doing this. I am seeing that the latest > update of dracut has the -systemd as a mandatory flag. So, since I > have to use systemd, does this mean I can no longer use dracut -- I > have found dracut very nice and would be sad to give it up. > > Any ideas on what is happening here? I'm not running 045 but it looks to me that systemd is just supported automatically if it is installed. The USE flag was removed, but support was not. -- Rich
Re: [gentoo-user] How to mask or remove new ebuild
On Sun, Jul 23, 2017 at 11:26 AM, Raphael MD wrote: > On Jul 22, 2017 22:06, "Rich Freeman" wrote: >> >> On Sat, Jul 22, 2017 at 8:43 PM, Raphael MD wrote: >> > >> > >> > Now I need to install Kdevelop-5.1.0, and emerge are asking to install >> > kde's >> > dependencies' version 5.7.1. My installed versions are 5.6.2. But emerge >> > even it I masked those packages, refuse to install. >> >> It sounds like you're running into a qt update issue (I assume you're >> talking about qt here - your description isn't very specific). >> >> If so, I suspect this will help you: >> https://wiki.gentoo.org/wiki/Qt/FAQ#Solving_the_block >> > > I understand, but I've updated my system 15 days ago. I don't want to > re-emerge all KDE stuff again and spends 2 days. I don't think the qt update forces a KDE rebuild, but I'm not 100% certain on that. > > Are there a way to roll back emerge-sync? Sure, just switch to a git repo and checkout a previous commit. > Because emerge-sync clean my old > ebuilds and I can't mask the new ones, because I don't have the old ones. > This appear to be the best solution. I doubt that. If you think rebuilding KDE is painful then trying to hold back the tide of upgrades is going to be something else entirely. > > For while I've learnt some things about Gentoo, ever save old ebuilds, never > run emerge-sync only to upgrade firefox-bin and last, never emerge packages > without --oneshot, wether this packages isn't very very important. > > And new, KDE appears to become a nightmare to have on pc. It's beautiful but > is "terrificful". I've never really had issues with KDE, but I don't really use many of the KDE applications, such as kmail/koffice/etc. I also have baloo disabled (I think - that thing is like a zombie that never quite dies). However, it really is an integrated set of packages. When it wants to update all 150 of them, best to just let it. You can always save binary packages to make it easier to go back, or use snapshots/etc at the filesystem level. However, there is really no getting around the forward march of progress on Gentoo. I'm running it on a Phenom II and sure the updates can be slow (just waiting for full Ryzen support on a longterm kernel to make the jump). A release-based distro has a different set of tradeoffs but it would generally result in you always staying on a stable version of KDE, for the small selection of distros that support KDE well. -- Rich
Re: [gentoo-user] How to mask or remove new ebuild
On Sat, Jul 22, 2017 at 8:43 PM, Raphael MD wrote: > > KDE Appear to be a nightmare, because every 'emerge --sync' I do to solve > other problems, if KDE base has an updated version issued, and you, > acidentaly, need to install any other KDE packages that you don't have > installed yet, you suffer with a lot of dependency updates problems. > > De fato, you need to update whole KDE base. As long as you aren't trying to mix keywords you should generally end up with compatible versions without a lot of hassle. Now, if you want to install some random ~arch kde packages on an otherwise-stable system then you might run into problems. > > Now I need to install Kdevelop-5.1.0, and emerge are asking to install kde's > dependencies' version 5.7.1. My installed versions are 5.6.2. But emerge > even it I masked those packages, refuse to install. It sounds like you're running into a qt update issue (I assume you're talking about qt here - your description isn't very specific). If so, I suspect this will help you: https://wiki.gentoo.org/wiki/Qt/FAQ#Solving_the_block I'd have to dig up the reason behind this - there was an issue that prevented portage from being able to figure out how to resolve this one on its own. You probably should have run into this a while ago when running a regular emerge -uD world. -- Rich
Re: [gentoo-user] [OT] Simple to upgrade Linux distro
On Wed, Jul 19, 2017 at 5:26 PM, Dale wrote: > > I have a question or two on this. The reason I went with KDE, I use it > and it is closest to being windozeish. On occasion I read where some of > those other "lighter" desktops are 'feature rich' like KDE is. Example, > plug in a USB device and it pops up with a menu to select from a lot > like KDE does. Is LXDE or Mate like that? > To some degree I'd think Mate would offer this kind of experience. Lightweight options like lxde or xfce are probably going to fall short. Full Gnome or KDE are are probably as close as you're going to get to a Windows-like environment. Another option I'd toss out there is ChromiumOS, though it isn't really intended as a mainstream option on non-Chrome hardware. For $120 a Chromebook is pretty hard to beat, IMO (and a Chromebit or similar solution is even cheaper). That isn't what you're looking for, but when relatives ask me about PC recommendations I tend to lean Chromebook unless they REALLY need to run thick applications, because they're basically zero maintenance and idiot proof. Oh, and they're Gentoo derivatives. :) Nobody seems to be mentioning full Ubuntu - assuming it performs well it should of course be considered as an option as well. I'm all for Xubuntu but it might not be the best fit depending. -- Rich
Re: [gentoo-user] AMDGPU KMS Problems
On Wed, Jul 12, 2017 at 5:34 PM, jdm wrote: > > I checked the config of the kernel (inc firmware) and could not find > an issue. I then tried arch/fedora/ubuntu and all froze at boot and then > worked with nomodeset. Ok, this is pointing to a likely hardware issue IMO - I gotta imagine that one of those distros would have noticed the RX 480 not working - it is hardly an obscure card. > > 1) Is this likely to be a kernel issue (amdgpu drm)? Probably not, imo. However, I would try booting using a mainline kernel (4.12 right now) just to confirm. Any distro would be fine - but try it on the bleeding edge kernel on one of them. > 2) Could this be a firmware issue (amd)? Maybe, but probably not. You might want to check if your motherboard has any published issues. I'd think that amd would be pushing their motherboard partners to support their cards. > 3) Could this be a motherboard/processor issue? > 4) Can you think of any ways round this so I can use the RX 480 gpu I suspect it is some kind of motherboard-GPU issue. Maybe it is firmware - I'd search for that. Some kind of power issue could also be the problem. Maybe your board has issues supplying enough power (I understand the RX 480 draws quite a bit through the PCI slot), or maybe the new motherboard+CPU+RX480 combo is stressing your power supply (either overall, or on one of the rails). Granted, if your old card was also a radeon it probably was also a power hog. Those are just the things I'd probably poke at - somebody else might have other ideas. Hopefully you'll get it working - I doubt I'll need an RX 480 but I probably will move to Ryzen sometime soon now that it is starting to mature on linux (though I wouldn't mind seeing it supported in a longterm kernel first, especially since I'm using btrfs and zfs on this box). -- Rich
Re: [gentoo-user] Re: Wayland - too early to try?
On Tue, Jul 11, 2017 at 10:51 AM, Ian Zimmerman wrote: > On 2017-07-11 09:02, Rich Freeman wrote: > >> > I use GNOME with Wayland for some time and I actually didn't notice >> > that I switched until I tried to get synergy working ( mouse sharing >> > software, which only works on X ), seems like GDM automatically >> > chose Wayland since some upgrade. XWayland works pretty seamlessly >> > as well, so I'll just stay with Wayland for now, but it might be >> > more annoying to use it with other DEs/WMs. > >> > However, I have less screen tearing with fullscreen applications >> > with Wayland than I had with X ( with radeon + mesa ). > >> My sense is that this is probably what people would see. It will >> probably work fine for any of the major DEs, but you'll find these >> little cases of tools that aren't ported. One BIG area that will be >> affected is X11 forwarding. I'm not sure if that works over ssh or >> not with wayland, but wayland in general doesn't support network >> sockets. > > What about "3rd party" window managers like openbox? From my limited > understanding of wayland, that functionality just goes out of the window > (OOPS, sorry); window management becomes a responsibility of the toolkit > and there is no way to plug in a different one. I'm going out on a limb a bit here, but my understanding is not so much that it is impossible for arbitrary applications to talk to wayland (that seems silly - it is just an API). Rather, the major toolkits simply have already done all the hard work so that if you use one of those toolkits then your application will work. I'm sure there is no reason an application that doesn't use qt/gtk/etc couldn't just make direct calls to wayland. However, it will require a lot more porting work on the part of upstream, and so it probably won't happen quickly. In the same way an application written to use QT probably can be made to work on OSX or Windows with very little additional work, because the toolkits provide a single API across all the platforms. You could write an application that works on all these platforms without using a toolkit, but then the developer needs to maintain all the API abstraction. Getting back to openbox/etc, I suspect that you have a couple of extremes here: * Full-fledged DEs like Gnome/KDE. They have a ton of functionality that would be impacted by Wayland, but they also use toolkits that have probably already taken care of this. * Very minimal window managers (think fvwm/twm/etc). They may not use a toolkit that was ported, but on the other hand their functionality is minimal and porting might not be so hard. Also, there seems to be some effort to port more minimal toolkits like motif to wayland. * In-between environments (think xfce, openstep, etc). They don't benefit from the toolkit but still have a lot of functionality to port. I heard that xfce is being ported to gtk for just this reason. I suspect that Wayland is going to drive adoption of gtk/qt much more widely. For the effort of directly porting to Wayland you could just port to gtk and then get coverage on other platforms as well. > > Or does xwayland help with that? I'll be grateful for an explanation of > this area, as I'm worried about the future of the X server but I'm also > married to openbox. > I suspect that xwayland would cover some of this, but I haven't messed with either. -- Rich
Re: [gentoo-user] Wayland - too early to try?
On Tue, Jul 11, 2017 at 7:37 AM, Rasmus Thomsen wrote: > > I use GNOME with Wayland for some time and I actually didn't notice that I > switched until I tried to get synergy working ( mouse sharing software, > which only works on X ), seems like GDM automatically chose Wayland since > some upgrade. XWayland works pretty seamlessly as well, so I'll just stay > with Wayland for now, but it might be more annoying to use it with other > DEs/WMs. > However, I have less screen tearing with fullscreen applications with > Wayland than I had with X ( with radeon + mesa ). > My sense is that this is probably what people would see. It will probably work fine for any of the major DEs, but you'll find these little cases of tools that aren't ported. One BIG area that will be affected is X11 forwarding. I'm not sure if that works over ssh or not with wayland, but wayland in general doesn't support network sockets. -- Rich
Re: [gentoo-user] To install a testing version of a package on a stable OS installation.
On Sun, Jul 9, 2017 at 3:59 PM, Ста Деюс wrote: > > Is it possible to compile/install a testing version of a package w/ its > dependencies on a stable OS installation? -- I mean, if a have stable > installation of whole the system, can i compile and install a testing > version of single package and the packages this single package depends > on? > Yes, for the most part. Obviously if whatever you want to install has a rats nest of unstable dependencies it can get messy. It isn't like you're going to be able to install one component of kde-6 on an otherwise kde-5 system, for example (when that comes along), and expect it to work. Typically you just stick whatever you're interested in /etc/portage/package.keywords. Then when you try to emerge it portage will indicate if any dependencies aren't fulfilled and offer to auto-unmask them for you. I find it to be a best practice to make /etc/portage/package.keywords a directory, and create files inside for various purposes. I have a file to put keywords in there for arch testing purposes. I have a file called zautounmask, which is where portage will dump auto-unmask settings (since it is last alphabetically). Over time when you have a million entries in these files having them separated will tend to make it a lot easier to clean them up. I can delete my auto-unmasked entries at any time and portage will just re-create the entries it actually needs the next time I do an update. Note that in general Gentoo doesn't do QA around mixed keywords. Typically it works fine, but you will run into exceptions. You'll be less likely to run into issues if you avoid running mixed keywords on things like core dependencies. You won't have trouble in general finding people to help, but ultimately nobody is going to officially bend over backwards to make it work. If you can identify what is causing a problem there is a decent chance it will get fixed (assuming upstream is cooperative - if some package doesn't work with a newer dependency upstream might just say they can't be bothered to fix it and it might not be easy to patch on our end). -- Rich
Re: [gentoo-user] Re: About using only precompiled pkgs
On Thu, Jul 6, 2017 at 8:55 AM, Harry Putnam wrote: > Rich Freeman writes: > > "I also have gentoo pre-build binary packages where it can > overnight..." > > Not so much interested in binary... now that I see its really sort of > a non-starter for someone looking to avoid `emerge world' where > posssible, but I am interested in how your overnight runs are done, > the details, as they might apply to getting parts or all of an update > done unattended. Perhaps parts of your system can be adapted for use > where emerging all or parts of an update are the goal. I would tell you to search the list archives, but I really struggle to get Google to find anything there. At night I run a script which does an emerge --sync, emails me the output of emerge -pu world, and then tries to build binary packages of everything in it. The next morning I read my email to see what is to be updated, and if I'm happy I just do the emerge with a -k to use binary packages where available. I'll detail the scripts below since searching is not turning out well. > Can you flesh out some of the details? Especially the `where it can' > part. How do you know what can or or can't be done unattended? The issue is when there are layers of dependencies being built. If package A and B need to be updated, and B depends on A at build time, then portage can only create a binary package for A, unless you want it to actually install the package. I'm not building these in some kind of chroot or container - I'm using --buildpkgonly so it never gets installed. I guess another option would be to spin up a container/etc, do all the building and packaging, and then destroy the container. Then I'd have a complete sent of binary packages. I should think about that, though I'd probably want it to use a snapshot of my root when doing so and that could get tricky (since my host isn't intended to be used as a template). If you wanted to do a full unintended install there would be no issues at all, other than the risk that you might walk in and find the computer not working and have to figure out why. I prefer to review my updates before installing them - Gentoo has gotten a LOT better at this stuff but it isn't Debian stable or RHEL/CentOS. Here are my scripts. This does an emerge sync (called from cron): https://github.com/rich0/rich0-gentoo-scripts/blob/master/emergesync This does the package builds (called from previous script): https://github.com/rich0/rich0-gentoo-scripts/blob/master/buildupdates This package installs the updates (called manually after I review the emailed proposed changes): https://github.com/rich0/rich0-gentoo-scripts/blob/master/instupdates The whole thing could be refactored and cleaned up, since the emerge parameters are hard-coded in each script. But, it is good enough for my purposes. These are very safe to use since nothing gets installed unless you ask for it. It is nice having portage build chromium overnight and then I just do a 30 second install the next morning. However, for something like a qt/kde update you're still going to watch a lot of stuff build. If all it saves me is kdelibs I'll consider it a win. -- Rich
Re: [gentoo-user] About using only precompiled pkgs
On Wed, Jul 5, 2017 at 8:57 AM, Harry Putnam wrote: > I skimmed thru some of the documentation about using binary pkgs > online, but it kind of indicated it might not be possible to get > everything in that format. As long as you use the default USE flags I don't see why you wouldn't be able to get everything online which is binary-redistributable. If you want USE=-bindist (which most people do) that list is going to be smaller. The biggest issue is that I don't think anybody maintains a public repository of packages. Tools exist to build one, and I'm sure that organizations may use these internally. However, there isn't anywhere a user can just point portage at and ask it to go fetching binary packages. > > Wondering if using mostly binary pkgs is a biggish hassle or if it can > be done... and done without the time-sink always involved in `emerge > world'..(over time)? For a single system there isn't much benefit in general, though for reinstalls you can certainly save binary packages of everything you do build. I do this for everything I build. I also have Gentoo pre-build binary packages where it can overnight so that I can do quick installs during the day after reviewing the list of new packages to install. However, I'm still building everything once no matter what, so it doesn't save on CPU. I'm just time-shifting the builds to before when I review the package update list (I don't blindly install updates). If I had multiple identical hosts then the binary packages would probably save me a heap of time though. > So, can someone be a gentoo user and NOT subscribe to one of the > main tenets of the gentoo view of things. Building packages is a means to an end - finding ways to do it only as much as possible merely makes you efficient, and I'd certainly say that this is in the spirit of Gentoo. I'd love to see a Gentoo binary repository with default USE flags, with the package manager being smart enough to find whether the configuration it wants to install happens to be pre-built. Users could still tweak USE flags. Obviously tweaking global USE flags is going to make most of the binary packages useless and it would fall back to current behavior. However, if you only wanted to tweak flags that impact a subset of the packages you'd benefit from the binary builds of anything your settings didn't touch. CFLAGS would be a bigger problem. While I imagine that we could have more than one set of those pre-built we certainly couldn't cover every variation Gentoo users want. CFLAGS have a much wider impact than even USE flags. Something like this would probably also drive changes like changing USE=-docs to an install mask. There is no sense keeping two versions of a binary package around just to avoid installing docs. -- Rich
Re: [gentoo-user] Re: ntp Vs openntp vis a vis Plasma desktop
On Fri, Jun 16, 2017 at 10:34 AM, R0b0t1 wrote: > > Is it not possible to add it via a USE flag? Even if there are no real > compile time options, could the flag pull in ntp? Could a USE flag do this? Sure. Should it? No. "The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed." https://devmanual.gentoo.org/general-concepts/use-flags/ If this is an optional runtime dependency the general practice is to just output a message after installation. Adding dependencies or USE flags are both poor solutions in these situations. GLEP 62 was actually created to address this, but it hasn't gone anywhere. To be fair, just printing an elog message isn't that painful a solution. -- Rich
Re: [gentoo-user] 1-long 3-short beeps
On Fri, Jun 16, 2017 at 9:01 AM, wrote: > > I find it hard to believe as the computer was working for 3-months > without any problem with video card in 8-bit PCI slot. > Something was definitely lost in translation here. I suspect you might be referring to 16x slots or 8x PCIe slots? I didn't think 8x slots were all that common, but I'm not much of a motherboard enthusiast. I tend to see more 1x and 16x in most boards I've looked at. PCIe uses a serial bus with packets, so the concept of bit width is a bit more nebulous. Each lane essentially has a one bit data bus. When multiple lanes are used they aren't transmitting parallel bits for the same word, but rather each is independently sending one byte at a time sequentially, with some kind of interleaving. I believe the physical layer uses an 8bit->10bit encoding, so you could view it as an 8-bit protocol in some sense. Above the physical layer the transmissions make up packets and those packets can have somewhat large payloads (hundreds of bytes). You could almost view PCIe the way you might look at ethernet. The main difference in slots and cards is the number of lanes supported. Each lane increases the rate at which data can be sent. Any device or slot can fall all the way back to 1x if the number of lanes doesn't match. Assuming the physical connectors allow for it you can stick a 1x card in a 16x slot, or a 16x card in a 1x slot. Any lanes that have matching connections will be used. Now, most slots tend to be closed off at the end so physically a 16x card won't fit on most 1x ports but you could stick a riser in-between as an adapter - the issue is purely mechanical and not electrical. Maybe your motherboard has a picky firmware and cares which slot the card goes in. It seems just as likely that one of your slots went bad and moving it to the other makes things better. If you did have a 16x card you would of course prefer to stick it in the 16x slot to get the best performance out of it. -- Rich
Re: [gentoo-user] e2fsck -a /dev/sdb1
On Thu, Jun 15, 2017 at 3:37 PM, Mick wrote: > On Thursday 15 Jun 2017 21:40:30 dan...@sonck.nl wrote: >> On Jun 15, 2017 9:28 PM, Mick wrote: > >> This is the first time I heard about discharge damage while unplugging. I >> highly doubt that but for curiosity sake I like some document >> proving/explaining this. > > I'd like one too, but until one appears have a look at what's happening in > this video around 0:46min. > > https://www.youtube.com/watch?v=PdiJWQmSi0k > > The principle is similar. There is current flow and unplugging the conductors > apart causes an arc. Of course the voltages involved are much smaller and so > is the damage. > You're comparing a 500kV breaker at a substation to a USB device? I'm very skeptical of the claim that any electrical effects associated with unplugging a device is going to cause issues with any USB device. They're basically designed to be hot swapped. Now, the filesystem is an entirely different matter - disconnecting a mounted filesystem can cause all kinds of issues. I think this is the most likely issue people are going to run into, and of course you should not have a mounted filesystem when removing a device. Some filesystems are more resilient to this sort of thing than others. I would think that something like a log-based filesystem like f2fs would be pretty impervious to loss of anything but uncommitted data. COW filesystems should also be pretty resilient. Filesystems set to journal data should be fine, but ones that overwrite data in-place might be left in a somewhat inconsistent state. I suspect this applies even when using ordered data mode on something like ext4 (your metadata is going to be fine, but if you were overwriting 15 blocks in-place I'd think that you could end up in a situation where half are updated and half are not). I'd be interested in somebody who knows better on this last point. Ideally you want the failure mode to be that the state of of the disk corresponds to what you would expect at the conclusion of a write system call (maybe not all the calls in the cache, but it should end on a boundary). I'd also buy the argument that some poorly designed USB drives could end up with data loss to something other than the block being immediately written, but honestly I'm skeptical that this is a widespread problem. -- Rich
Re: [gentoo-user] 1-long 3-short beeps
I think on ASUS that code means no VGA detected. I'm not sure if modern firmwares still output to port 80, but if so that might be another way to narrow it down assuming you have a card. I'm sure there are faults on the motherboard side that could result in problems accessing the video card even if the card is otherwise functioning. A physical slot problem certainly could do it. I suspect you'll end up replacing the motherboard one way or another... -- Rich On Wed, Jun 14, 2017 at 11:18 AM, wrote: > My 2-months old system is giving me 1-long 3-short beeps. > No, video display. > I've swapped the video cards, it is not it. > > Is it a motherboard? > Asus 970 PRO GAMING AURA Mobo > > I've taken the system to the outfit that put it together (under warranty). > > -- > Thelma > -- Rich
Re: [gentoo-user] how to get started with automated update world
On Wed, Jun 7, 2017 at 4:26 PM, Harry Putnam wrote:
>
> Maybe some of you can steer me toward some documentation or tools etc
> that help a gentoo user to do automated updates.
>
Unmonitored updates sounds like a recipe for problems. However, I do
have a cron job that does a --sync and then builds binary packages for
everything, and it emails me the emerge -pu output. Then if I'm happy
with it I can just install the binary packages.
To build everything (this could be cleaned up a bit or parallelized,
and I stole it off of the lists):
#!/bin/sh
LIST=$(mktemp);
emerge -puD --changed-use --color=n --columns --quiet=y --changed-deps
--with-bdeps=n --backtrack=100 world | awk '{print $2}' > ${LIST};
for PACKAGE in $(cat ${LIST});
do
printf "Building binary package for ${PACKAGE}... "
emerge -uN --quiet-build --quiet=y --buildpkgonly ${PACKAGE};
if [[ $? -eq 0 ]];
then
echo "ok";
else
echo "failed";
fi
done
To install the packages you built:
ionice -c 3 nice -n 15 emerge -uDkv --changed-use --keep-going
--with-bdeps=n --changed-deps --binpkg-changed-deps=y --backtrack=100
world
Note that binary packages can only be built one level of dependencies
deep, so if you're doing something like a kde update you'll still end
up doing a LOT of building. Then again, it often takes care of some
pretty big first-level dependencies like kdelibs. Typically over 80%
of my package installs end up being from binaries, and often the stuff
that isn't is small. If somebody triggers a rebuild of chromium then
that is a different story, but most chromium updates get built
overnight.
--
Rich
Re: [gentoo-user] conflict with same package, same USE
On Fri, Jun 2, 2017 at 9:17 AM, Sam Jorna wrote: > On 02/06/17 23:09, Rich Freeman wrote: >> The stage3 make.conf shouldn't include this. Now, if you copied your >> make.conf from some other source like a LiveCD then that could explain >> where it came from. The flag was actually invented mainly for things >> like LiveCDs, and these are all built using USE=bindist (we couldn't >> legally distribute them otherwise). > > The stage3 make.conf does include USE=bindist by default, as it includes > packages affected by this flag (specifically openssh and openssl). It's > required, as I understand, because the stage3 does distribute binaries > of these packages, thus must have the patent-encumbered parts disabled. > Interesting. It looks like we do set that in make.conf by default now - that might be a change from the last time I did an install as I didn't have to remove this in the past. There is no legal requirement to set bindist in the make.conf installed by the stage3. There absolutely is a legal requirement to set bindist in the make.conf used to BUILD the stage3. The two do not need to be the same. -- Rich
Re: [gentoo-user] conflict with same package, same USE
On Fri, Jun 2, 2017 at 8:55 AM, Daniel Frey wrote: > On 06/02/2017 03:08 AM, Hogren wrote: >> Thank you all for the help. >> >> I saw a "bindist" in my global USE flag ! >> >> I really don't remember when I had that. May be when I saw it for the >> first time, I said to me "Hey a weak protocol (EC)? disable it !" … >> >> For the moment, no more problem ! >> >> >> Thank you >> > > You probably didn't put it there. When I built a new machine some time > ago I was having similar issues and noticed that as a default in make.conf. > The stage3 make.conf shouldn't include this. Now, if you copied your make.conf from some other source like a LiveCD then that could explain where it came from. The flag was actually invented mainly for things like LiveCDs, and these are all built using USE=bindist (we couldn't legally distribute them otherwise). -- Rich
Re: [gentoo-user] Can't rebuild gentoo kernel-4.9.16 with gcc-5.4.0
On Tue, May 30, 2017 at 1:50 PM, Mick wrote: > On Tuesday 30 May 2017 13:08:39 Neil Bothwick wrote: >> On Tue, 30 May 2017 04:20:17 -0700 (PDT), Mick wrote: >> > > After gcc-config, make sure you run: >> > > # env-update >> > > # source /etc/profile >> > > >> > > It looks like something still points to your old compiler. >> > >> > Thanks Joost, I've rebooted many times since the move/rebuild of almost >> > everything with gcc-5.4.0. Actually, now that you mention it ... I >> > can't recall if I rebuilt the linux-headers. Hmm ... will look into >> > that next. >> >> As you are rebuilding the kernel, it may be that you have parts still >> built with the old compiler. Try running make clean. > > Yes! That fixed my problem. Thank you Neil and Joost. :-) > This will go a lot slower if you're constantly rebuilding after tweaking options, but I direct my kernel builds to a tmpfs. mkdir /var/tmp/linux make O=/var/tmp/linux oldconfig make O=/var/tmp/linux -j# make O=/var/tmp/linux modules_install make O=/var/tmp/linux install emerge @module-rebuild This leaves your sources completely untouched - it will just be the clean git repo (or wherever you get your sources from). Note that if you want to later build/upgrade any kernel modules you'll need to create /var/tmp/linux and run: make O=/var/tmp/linux modules_prepare (This is because you don't just have all the needed files lying around all the time for when portage needs them.) Also, you need to make sure your config file is in /boot or that /proc/config.gz support is enabled, because there won't be a /usr/src/linux/.config file lying around for when portage does kernel config checks. It automatically falls back to the running kernel when this is missing. >From what I understand this is actually what the linux devs consider the preferred way to build kernels anyway. Now, the downside is that if not much has changed make can't re-use anything. The upside is that you always get a completely clean build, and since all the objects end up in a tmpfs it builds a lot faster (compared to a clean build on disk). I switched over to this when my /usr/src moved to tmpfs to cut down on wear, and also because upstream actually recommends it. But, aside from issues like the one you just ran into you won't really run into much trouble building the way most people seem to do it. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On Thu, May 25, 2017 at 12:28 PM, J. Roeleveld wrote: > > Not sure how long ago this was. I'm planning on redoing the whole laptop in > the near future anyway. > > If anyone knows of a better way (that works without TPM) I would like to hear > about it. > I'd read up on LUKS. That seems to be the way everybody is doing stuff like this today. It probably isn't much different in security but it is more standard, which means more convenience when booting from rescue disks and so on. I bet with something like dracut you can probably configure it more easily as well. However, I've not looked into the details. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On Thu, May 25, 2017 at 10:16 AM, J. Roeleveld wrote: > On May 25, 2017 1:04:07 PM GMT+02:00, Kai Krakow wrote: >>Am Thu, 25 May 2017 08:34:10 +0200 >>schrieb "J. Roeleveld" : >> >>> It is possible. I have it set up like that on my laptop. >>> Apart from a small /boot partition. The whole drive is encrypted. >>> Decryption keys are stored encrypted in the initramfs, which is >>> embedded in the kernel. >> >>And the kernel is on /boot which is unencrypted, so are your encryption >>keys. This is not much better, I guess... > > A file full of random characters is encrypted using GPG. > Unencrypted, this is passed to cryptsetup. > > The passphrase to decrypt the key needs to be entered upon boot. > How can this be improved? > The need to enter a passphrase was the missing bit here. I thought you were literally just storing the key in the clear. As far as I can tell gpg symmetric encryption does salting and iterations by default, so you're probably fairly secure. I'm not sure if the defaults were always set up this way - if you set up that file a long time ago you might just want to check that, unless your passphrase is really complex. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On Thu, May 25, 2017 at 7:04 AM, Kai Krakow wrote: > Am Thu, 25 May 2017 08:34:10 +0200 > schrieb "J. Roeleveld" : > >> It is possible. I have it set up like that on my laptop. >> Apart from a small /boot partition. The whole drive is encrypted. >> Decryption keys are stored encrypted in the initramfs, which is >> embedded in the kernel. > > And the kernel is on /boot which is unencrypted, so are your encryption > keys. This is not much better, I guess... > Agree. There are only a few ways to do persistent encryption in a secure way: 1. Require entry of a key during boot, protected by lots of rounds to deter brute force. 2. Store the key on some kind of hardware token that the user keeps on their person. 3. Store the key in a TPM, protected either by: a. entry of a PIN/password of some sort with protections on attempt frequency/total b. verification of the boot path (which should be possible with existing software on linux, but I'm not aware of any distro that actually implements this) If you don't have hibernation then you can just generate a random key on boot, and that is very secure, but your swap is unrecoverable after power-off. Of the options above 3b is the only one that really lets you do this with the same level of convenience. This is how most full-drive encryption solutions work in the Windows world. Chromebooks use a variation on 3a I believe using your google account password as one component of the key and putting it through the TPM to have a hardware component and to throttle attempts. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On Wed, May 24, 2017 at 2:16 PM, Andrew Savchenko wrote: > > Apparently it is pointless to encrypt swap if unencrypted > hibernation image is used, because all memory is accessible through > that image (and even if it is deleted later, it can be restored > from hdd and in some cases from ssd). > Yeah, that was my main concern with an approach like that. I imagine you could use a non-random key and enter it on each boot and restore from the encrypted swap, though I haven't actually used hibernation on linux so I'd have to look into how to make that work. I imagine with an initramfs it should be possible. -- Rich
Re: [gentoo-user] Re: tmp on tmpfs
On Wed, May 24, 2017 at 11:34 AM, Ian Zimmerman wrote: > On 2017-05-24 08:00, Kai Krakow wrote: > >> Unix semantics suggest that /tmp is not expected to survive reboots >> anyways (in contrast, /var/tmp is expected to survive reboots), so >> tmpfs is a logical consequence to use for /tmp. > > /tmp is wiped by the bootmisc init job anyway. > In general I haven't found anything that is bothered by /var/tmp being lost on reboot, but obviously that is something you need to be prepared for if you put it on tmpfs. One thing that wasn't mentioned is that having /tmp in tmpfs might also have security benefits depending on what is stored there, since it won't be written to disk. If you have a filesystem on tmpfs and your swap is encrypted (which you should consider setting up since it is essentially "free") then /tmp also becomes a useful dumping ground for stuff that is decrypted for temporary processing. For example, if you keep your passwords in a gpg-encrypted file you could copy it to /tmp, decrypt it there, do what you need to, and then delete it. That wouldn't leave any recoverable traces of the file. There are lots of guides about encrypted swap. It is the sort of thing that is convenient to set up since there is no value in preserving a swap file across reboots, so you can just generate a random key on each boot. I suspect that would break down if you're using hibernation / suspend to disk. -- Rich
Re: [gentoo-user] tmp on tmpfs
On Wed, May 24, 2017 at 5:43 AM, wrote: > On 17-05-24 at 05:34, Rich Freeman wrote: > [..] >> Others have mentioned zram. I've used it, but unless something has >> changed one of its limitations is that it can't give up memory. That >> is less of an issue if you're using swap since it can be swapped out >> if idle. However, if you're not using swap then you're potentially >> giving up a chunk of RAM to do it, though less RAM than a tmpfs if it >> is full most of the time (which I doubt is typically the case). > Seems to work fine here (with kernels newer than the late 3.x when I started > using zram): > Thanks. Useful to know. Perhaps something changed. Then again, I don't think I actually tested it so it could have also been misinformation somewhere. -- Rich
Re: [gentoo-user] tmp on tmpfs
On Wed, May 24, 2017 at 1:16 AM, Ian Zimmerman wrote: > > I have long been in the camp that thinks tmpfs for /tmp has no > advantages (and may have disadvantages) over a normal filesystem like > ext3, because the files there are normally so small that they will stay > in the page cache 100% of the time. > The file being in the page cache only speeds up reads of the file. On a conventional filesystem the file will still be forced to be committed to disk within 30 seconds, or whatever you've set your max writeback delay to. That means guaranteed disk write IO. If the drive is mostly idle it will have no impact on performance, but if the disk is fairly busy then it will, especially for spinning disks. For an SSD /tmp would be a source of erase cycles (which also have performance implications, but there it is more of a wear issue). When the file is removed that would also generate write IO. The flip side is that on most systems /tmp probably doesn't get THAT much IO. On Gentoo doing your builds in tmpfs definitely has a large performance impact, because there are a lot of files created during the build process that are sizable but which don't end up getting installed (object files mostly). Plus you have the extraction of the source itself. For a typical build that is many MB of data being extracted and then deleted after maybe a minute, which is a lot of useless IO, especially when the actual install is probably creating a fairly sizable IO queue on its own. To avoid a reply, I'll also note that tmpfs does NOT require swap to work. It does of course require plenty of memory, and as with any situation where lots of memory is required swap may be useful, but it is not a requirement. Others have mentioned zram. I've used it, but unless something has changed one of its limitations is that it can't give up memory. That is less of an issue if you're using swap since it can be swapped out if idle. However, if you're not using swap then you're potentially giving up a chunk of RAM to do it, though less RAM than a tmpfs if it is full most of the time (which I doubt is typically the case). -- Rich
Re: [gentoo-user] Re: htop wants cgroups
On Sun, Apr 30, 2017 at 4:17 PM, Kai Krakow wrote: > Am Sun, 30 Apr 2017 10:33:05 -0700 > schrieb Jorge Almeida : > >> It makes sense that the kernel has it. Should it be enabled? For a >> server, probably. For a single-user workstation? Maybe. > > Maybe I don't have the ordinary workstation, but I use it to limit > memory of sometimes-run-away services (memory-wise) and to control > resource usage of container machines I'm using during development. > Probably not the ordinary use-case... > Honestly, I can't think of why you wouldn't want to use it. The use cases of killing orphan processes and managing resources at a service level have already been mentioned. Another use case is that the kernel automatically takes cgroups into account when scheduling. So, if one of your services launches a bunch of children they'll be weighted together when allocating CPU. That means that a service with ten threads won't get 10x the CPU of a service with one thread if CPU becomes limiting, assuming equal niceness/etc. On a multi-user system the same would apply to the user running 100 processes vs 1. I also use cgroups to monitor memory use/etc at a service level. Sure, they're somewhat optional, but they're a pretty useful kernel feature. -- Rich
Re: [gentoo-user] systemd questions: hdparm unit file, OpenRC packages
On Mon, Apr 10, 2017 at 3:27 AM, Raffaele Belardi wrote: > After 10+ years of LXDE/OpenRC I decided to give Gnome/systemd a try. > > 1. With OpenRC I used hdparm to put an external USB disk to sleep: > > $ cat /etc/conf.d/hdparm > sdb_args="-S24" > > Looks like systemd does not provide a unit file for hdparm yet, right? If so > I suppose I'll have to write my own. > In general I suppose the same holds for everything that was under > /etc/local.d/ As Kai pointed out there are units/generators to run the stuff under local.d. You could certainly create a unit for hdparm but a local.d script is probably fine for something done once like this, especially if there is no need to maintain any kind of state and undo it later. > > 2. Which OpenRC-related packages can I unmerge? > - sys-apps/sysvinit > - sys-apps/openrc This stuff ends up being pulled in by the system set, but you can eliminate it if you create a symlink from /lib/gentoo/functions.sh to /etc/init.d/functions.sh. Don't ask me why stuff STILL sources the old location, other than it being so trivial that nobody cares that much. I've put openrc in package.provided just to avoid the needless upgrades. You can ditch sysvinit if you set USE=sysv-utils on systemd (so that you still get stuff like reboot/halt/poweroff, though I'm not sure how essential those actually are these days). > - app-admin/sysklogd Never used it, so obviously you can live without that. > - cron/anacron after transition to systemd timers You might want to also look at sys-process/systemd-cron as a bridge. It basically generates timer units from your crontab and also runs the stuff in /etc/cron.*.d/. But, timer scripts also work just fine and I do that for stuff that I want a bit more control over. > - sys-apps/debianutils provides savelog functionality also provided by > systemd but also installkernel so I shall not remove it I use logrotate personally, and I still need it for stuff that doesn't use syslog. > - others? That depends how far down the rabbit hole you want to go. Systemd has semi-replacements for stuff like ntpd, dns, etc. They're not intended as full replacements. If you're serving time/dns/etc then you probably won't want it. If you just want something to manage it locally on the host then these are fairly viable replacements. There is also networkd, which I use on systems that don't have wifi. Systemd basically tries to provide all the essential services from a client-only perspective. -- Rich
Re: [gentoo-user] bitcoin-qt, openssl and the bindist USE flag
On Sat, Apr 8, 2017 at 5:57 PM, Alan McKinnon wrote: > On 08/04/2017 20:16, Francesco Turco wrote: >> I'm trying to globally enable the "bindist" USE flag on my system > > Why on $DEITY's green earth would you even think of doing that? > > Dont. Just ... don't. I don;t know what you are trying to accomplish > doing that, but it can't end well. > > Set that flag in package.use for the packages where you want it to be set. > There are valid reasons to want to set that flag globally. Maybe you want something you can legally distribute. However, you do need to accept that there are tradeoffs. Some packages will have features disabled, and other packages will simply be impossible to use. You can certainly get a working box with USE=-bindist (our stage3s are built that way). The more you want something resembling a conventional desktop the more you're going to have to be willing to compromise on this one. Don't like it? Well, unfortunately you're going to have to re-implement some fairly basic stuff, and even then you could run into patent encumbrances that are going to be really painful to work around. Gentoo is just the messenger here. It isn't like we're the ones preventing you from redistributing stuff. We don't care if you ignore us. Others might care more. -- Rich
Re: [gentoo-user] Re: [OT] Tools for putting HDD back to new state
On Mon, Apr 3, 2017 at 2:34 PM, Kai Krakow wrote: > > Just dd /dev/zero to the complete device. That purges everything you > need: partition tables, boot sectors, contents: > > # dd if=/dev/zero of=/dev/sdX > If it contains data you'd prefer not be recoverable you might want to use shred or ATA secure erase. Shred overwrites the drive with random data using a few passes to make recovery more difficult. Some debate whether it actually adds value. Secure erase is a standard command supported by most drives. It has the advantage of being MUCH faster, and it also should take care of things like relocated blocks and such which might not be seen by the OS. It has the disadvantage of being a black box that might not actually work or which might have some kind of NSA back door. Typically it is implemented by the drive controller encrypting all your data transparently using a random key in normal operation, and then the secure erase command tells it to forget the key and generate a new one. I suspect that secure erase would probably be the closest thing to restoring "factory" condition for a drive. Instructions can be found at: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase Unless I'm in a hurry I tend to do the best of both worlds. I run shred, and then I do a secure erase. And of course another option is to always encrypt your drives all the time anyway, which means that even if the drive fails and you can't erase it that your data is secure anyway. -- Rich
Re: [gentoo-user] disaster recovery - planning
On Mon, Mar 20, 2017 at 7:15 PM, wrote: > Besides standard "data" backup, if I was to plan for a disaster > recovery; what to include in a backup system if I was to rebuild a new box? > > - /etc > - /var/lib/portage/world > - /usr/src/linux/.config > - /var/spool/fax/ (if needed) > - /var/www/localhost/htdocs/ (if needed) > - crontab (users and root) > Here is what I'm backing up to the cloud via duplicity (where storage is expensive so I have a more selective set of rules here): --include /boot --include /usercache --include /etc --include /data/www --include /data/home --include /root --include /var/lib/samba --include /var/spool/tftp --include /var/lib/cdcat --include /var/bind --include /usr/local --include /var/lib/portage/world --include /data/diskless/gentooinst64 --include /data/diskless/mythliv2 --include /var/lib/bitcoin/.bitcoin/wallet.dat --include /var/lib/quassel/ --include /var/lib/ --include /data/sstorage3/containers/mariadb/ --include /data/sstorage3/containers/vpn/ --include /data/sstorage3/containers/ddclient/ --include /data/sstorage3/containers/dns/ (I realize that a lot of this references mountpoints that are useless to you, but the end of the paths is probably good enough as a checklist. Yes, I realize a few of those are redundant, but I suspect they might get around exclusions.) My excludes for these more expensive backups contain things like: www cache directories for some apps Trash directories NNTP client caches Download directories ~/.cache mail client caches (I use IMAP) bitcoin blockchains mysql data directory (I separately run mysqldump and back that up) .snapshots on volumes that use zfs/btrfs /usr and /var/log on my containers Any random /tmp that would otherwise be caught In general I try to stick stuff I want to back up in /home, and stick stuff I don't want to backup elsewhere and just symlink it into /home where needed. The include/excludes just handle the random stuff where this policy isn't practical. Now, I also keep local backups of everything and the rules are much more inclusive there. I just exclude things like /sys, /proc, anything with a bind mount (so as to not save it twice), /usr/portage (changes constantly, trivial to restore), all those .snapshots directories, and the same sorts of things in chroots (but not containers). As far as the suggestion to use ansible/etc goes for things like /etc - I certainly agree it is a best practice. -- Rich
Re: [gentoo-user] Diskless nodes
On Sat, Mar 18, 2017 at 4:25 AM, Ural wrote: > Rich Freeman: >> On Thu, Mar 16, 2017 at 11:12 PM, wrote: >>> >>> So, instead of getting into trouble of making disk-less node I figure it >>> out my Atom (small box) can access Main server via X2GO. I tested it on my >>> local network and speed wise it works OK. Buy my computer is much faster >>> than the Atom. So after upgrade I'll see how it will run. All boxes have >>> gigabit network cards. >>> >> >> While this would certainly work, you should also consider using a >> windows technology like rdp/citrix to connect directly from the client >> to the VM guest. That might actually give you better performance. >> >> It is analogous to running a linux VM in a window and typing into its >> console, vs running a linux VM headless and using ssh to connect to >> it. Ssh is probably going to give you a more integrated experience >> and better performance, because you're not virtualizing a console with >> minimal support for stuff like the clipboard/etc. >> > > Try using Nomachine.com NX. It is fastest remote connection, but it is > proprietary. There is open source client available for Linux > x2go is based on NX. I doubt that NX + VM console window is faster than Citrix for accessing a Windows machine. NX was largely inspired by Citrix. Both approaches have their pros and cons. NX is the right solution for accessing a linux X11 server. rdp/citrix is probably the right solution for accessing a windows console. So, the question is whether you want to be accessing the VM console running on Linux, or directly accessing the windows console running inside the VM. I suspect that the latter is going to be a bit cleaner when you consider things like clipboard support and such. But, if you want to be able to start/stop the VM and such then obviously you can't do that from the windows console. -- Rich
Re: [gentoo-user] Converting to mirror - filesystem maintained or need to restore
On Sat, Mar 18, 2017 at 5:14 AM, Neil Bothwick wrote: > On Sat, 18 Mar 2017 13:29:36 +1100, Adam Carter wrote: > >> IIRC when you add a device to a mirror say with; >> mdadm --create --verbose /dev/md127 --level=mirror --raid-devices=1 >> --force /dev/sdb3 >> >> I thought the filesystem is maintained and so /dev/md127 should be >> immediately mountable, however, it doesnt mount. >> mount: wrong fs type, bad option, bad superblock on /dev/md127, >>missing codepage or helper program, or other error > > You have created a block device at /dev/md127 but you haven't created a > filesystem on it, there's nothing to mount. > > Unless you are trying to add a device to an existing array, in which case > you shouldn't be using --create. > Yeah, if you are sticking "--force" on a command line you had better know exactly what you're doing. I suspect that mdadm was refusing to wipe out the existing array and destroy all the data on it until this was added. mdadm is quite versatile. You can add/remove individual disks from any type of raid online without losing data (well, removing disks may require resizing filesystems first as the device could get truncated depending on what you're doing). However, --create is not used to modify existing arrays, unless by modify you mean delete-the-old-and-create-something-new. Since you only specified one device, you might actually be able to recover. I'm not sure what your existing device was, but if it wasn't /dev/sdb3 then what you might have done is create a second array with the same device name. Now, /dev/md127 at that moment will point to the new empty array, but the old array may still be untouched on disk, so you might be able to activate it and still have all the data. Then you could delete the new array (be VERY careful here that you're deleting the right one), and then correctly add /dev/sdb3 to the old array. Can you spell out your configuration? What devices constituted your original array and what was it called? What device did you intend to add to it? What happens when you run mdadm --query and mdadm --examine on both your old and new devices? I'll confess that it has been a few years since I've used mdadm but if the actual disks are still intact then you should be able to re-assemble everything correctly. -- Rich
Re: [gentoo-user] Diskless nodes
On Thu, Mar 16, 2017 at 11:12 PM, wrote: > > So, instead of getting into trouble of making disk-less node I figure it out > my Atom (small box) can access Main server via X2GO. I tested it on my local > network and speed wise it works OK. Buy my computer is much faster than the > Atom. So after upgrade I'll see how it will run. All boxes have gigabit > network cards. > While this would certainly work, you should also consider using a windows technology like rdp/citrix to connect directly from the client to the VM guest. That might actually give you better performance. It is analogous to running a linux VM in a window and typing into its console, vs running a linux VM headless and using ssh to connect to it. Ssh is probably going to give you a more integrated experience and better performance, because you're not virtualizing a console with minimal support for stuff like the clipboard/etc. -- Rich
Re: [gentoo-user] Diskless nodes
On Thu, Mar 16, 2017 at 3:02 PM, wrote: > On 03/16/2017 05:58 AM, k...@aspodata.se wrote: >> Thelma: >>> Is anybody running Diskless machine, booting over network? >>> How is the speed? >> >> I've done diskless before but it has been a few years since, >> it was working just fine. Don't remember any specific issues >> once you get it working. >> >>> I have a Gentoo machine running Windows7 via VM. >>> I need to network another PC and connect to that VM so I was thinking >>> setting up Diskless node but never done it before. >> >> You have to ask someone else about diskless MS-Windows. >> > > I think I would "tax" the resources on the serving machine too much. I > would need to run another VM-2 - Windows7 on the server that create > access to VM-1 - Windows7 running the main program on the server. > Can you clarify what you're trying to do? Are you looking to run windows on a VM on a server as a "virtual desktop" and just access it remotely from a diskless thin client using RDP or something like that? If so there are a few options for this and it is actually a somewhat normal configuration. Indeed you can still buy dedicated thin client hardware that can be configured to do nothing more than boot up and connect to your VM using RDP (or better still something like a Citrix server). Often the thin clients just run linux and a citrix client, but they could also run an embedded windows. They aren't really diskless per se so much as flash-based but they aren't designed for any kind of local storage other than their configuration. The main advantage is that you don't have to worry about employees or such storing data locally since they can't, and they use little power and boot up really quickly and can't get viruses and such. The downside is that they're a one-trick pony and these days there are better options, like rolling your own with a Pi or whatever. Now, if what you want is a diskless linux client there are a bunch of options. It might be used to run RDP and connect to a windows VM just like a traditional thin client. Or it could just do whatever you'd want to do with linux. I was PXE booting a mini-ITX linux box as a mythtv frontend for years until the board died. Typically in this configuration you'd serve the kernel and initramfs via PXE or similar and then mount the root over nfs, but there are other options like iSCSI or even just using a huge initramfs containing your whole OS. However, I'm not sure that is how I'd actually do it these days. A Pi is dirt cheap, so I'd probably just use one of those and the OS is on a flash disk. That makes it pretty easy to back up, and you could install updates from another box. Doing it with Gentoo though would be a little more painful. With my mini-ITX with an nfs root it was easier, since it was Atom-based. I just updated the root filesystem from inside a chroot on more powerful box. I just had to set an appropriate -march so that it would run on both systems. That isn't quite as simple in the pi example unless your build box is a compatible ARM server. You're stuck cross-compiling everything otherwise. -- Rich
Re: [gentoo-user] ISP extortion [ Partially Resolved ]
On Sat, Mar 11, 2017 at 7:06 PM, Corbin Bird wrote: > > Will act on the ( lawyer, deposit ) suggestions. And a new e-mail provider. > Good luck with that... Honestly, I think a lawyer is a waste of money here. If you're in the USA these sorts of arrangements are completely commonplace. It also is common to put nonsense like "you can't talk to the FCC" in contracts, though you can basically just ignore that sort of thing. In any case, in the end the ISP is going to make a unilateral decision about whether they're willing to bend any of their rules for you, and if you don't like their decision your only options are internet or no internet. Yeah, it is stupid, but that's life in the USA. By all means talk to your elected representative. Or, better still, contribute $100k to their re-election campaign as that will get you a lot further. Be prepared to outbid the ISP who no doubt has already made a nice contribution. We can all commiserate about how lousy this is, but you're wasting your time+money if you think you're going to win some kind of legal battle with them. -- Rich
Re: [gentoo-user] ISP extorsion - how to negate / get around?
On Fri, Mar 10, 2017 at 2:50 PM, Corbin Bird wrote: > > My ISP ( Charter ) merged with Time-Warner. New name "Spectrum" > > 1 # : Now I have intermittent connectivity. Nothing you can do about that if it really is connectivity. > > 2 # : And with the death of FCC privacy rules, the new ISP is forcing me > to update their records ( for sale-of purposes ). This includes phone ( > all ), SSN, bank account numbers, and credit card numbers. > > 3 # : the ISP attempting to force agreement to "no communications > allowed with the FCC". Also is attempting to force agreement to > "Arbitration with the ISP as the Arbiter" for all complaints. > > 4 # : billing is only online now. Not allowed to see a Account > Statement, or receive any "receipt for payment" until I comply with ISP > demands. While I certainly agree with your frustrations on these, I suspect your options are pretty limited if they really are a monopoly. You may just have to live with these if you don't want to do something exotic for internet access. > 5 # : external e-mail clients ( Thunderbird, Claws-Mail, etc. ) are now > starting to have problems. ISP solution -> must use their web based > e-mail app only ( only works with Windoze, surprise! ). > > 6 # : ISP is starting to filter customers web access. The ISP is > deciding what sites customers are allowed to see. ( look up the practice > called "ransom" ). I would see if a VPN works for you. It would solve these problems at least. Of course, they could do something to block the VPN, but I believe some services can work over SSL/etc unless your ISP is carefully blacklisting them. > > NOTE : The ?hijack technique? will corrupt the portage trees if you use > "emerge-webrsync". > Can you define "corrupt" here? Looking at the source emerge-webrsync should at the least do a digest check if available (and if it isn't available I'd be interested in that), and if you set the webrsync-gpg FEATURE flag in make.conf it should also check the gpg signature. Unless your ISP is doing a Gentoo-specific MITM the first should detect problems, and unless our gpg checking is completely broken the latter should detect anything the ISP tries to do to the file. They could of course prevent you from syncing, but tampering shouldn't be an issue. -- Rich
Re: [gentoo-user] [Off-Topic] arch-openrc
On Thu, Mar 9, 2017 at 12:40 PM, Marvin Gülker wrote: > On Thu, Mar 09, 2017 at 07:57:19AM -0500, Rich Freeman wrote: >> Honestly, as somebody who monitors all the systemd bugs on Gentoo it >> isn't actually that much work, and I suspect that it wouldn't be that >> much work maintaining openrc scripts on Arch. I doubt they rename the >> apache binary 3x per year, or move its location around the filesystem. > > Maybe not the apache binary, but who keeps track of things like sticking > the logrotate cronjob into systemd timer unit files (something I just > recently experienced on an Arch machine when I was looking for where > logrotate was called from and how often)? We don't generally create timer units for cron jobs installed by packages. We do have systemd-cron which can be a cron substitute using timers if you prefer for things in cron.d directories, or you can just run a regular cron. > Changes to mount units? We certainly don't do anything with mount units, and I'd be surprised if Arch messes with them though they could certainly do so. We just use fstab, and systemd has a generator by default which handles fstab. I'm not aware of anybody using mount units as a substitute for fstab, though it might make sense in situations where you want to use a mount as a dependency for a service. > Other > things absorbed by systemd? It's not like going without systemd is just > about setting different compilation options on upstream software. Not to > mention upstream software that has a hard dependency on systemd, like > GNOME I have heard -- these are going to require patching. Things like > these are going to grow rather than shrink, so I expect much work to come > onto the no-systemd people. > Well, if Arch is using these kinds of features then sure that is more work, and Gnome is a whole different beast. If nobody bothers to package a network manager because networkd is popular that would be a gap (though I doubt that is the case since networkd doesn't handle some cases). Most of the stuff that systemd does is at a moderate level of functionality. timedatectl certainly is good enough for a typcial system but it isn't intended to be an ntpd server implementation. networkd will handle a lot of typical cases, especially on servers, but as far as I'm aware it isn't really a great solution for laptops using Wifi. Resolved can handle the client side of DNS but certainly can't be an authoritative name server. The general goal systemd has is to provide a lot of the guts of a typical system to cut down on the variety of 3rd party stuff, but still allow that stuff to be used when it adds value. So, journald isn't a complete syslog implementation, but for what most people need it is adequate, etc. I guess all it is missing is an MTA. :) -- Rich
Re: [gentoo-user] [Off-Topic] arch-openrc
On Thu, Mar 9, 2017 at 6:59 AM, Marvin Gülker wrote: > > With Arch, it's different. The no-systemd people need to run after all > cahnges made by the Arch team, and then place their own changes on top > of that. This creates certainly a lot of work, and certainly requires a > lot of manpower, which I am not sure these people have available. This, > in consequence, leads me to security considerations. How quickly do > security problem fixes propagate to arch-openrc? Honestly, as somebody who monitors all the systemd bugs on Gentoo it isn't actually that much work, and I suspect that it wouldn't be that much work maintaining openrc scripts on Arch. I doubt they rename the apache binary 3x per year, or move its location around the filesystem. If anything systemd is a bit more of a moving target since we started with distro-built scripts and have largely moved towards upstream-provided ones, while also dealing with changes in systemd itself (the latter has more to do with support for more features or changes in conventions than actual breakage). Now, systemd on Gentoo vs openrc on Arch might not be equivalent, since on Gentoo we are a bit more accustomed to heterogeneous environments and the way we maintain packages is structured around this. Systemd on Gentoo also has the advantage of more upstream support, since a LOT of packages have upstream-provided units that get installed by the build scripts. -- Rich
Re: [gentoo-user] [Off-Topic] arch-openrc
On Wed, Mar 8, 2017 at 4:06 PM, Daniel Frey wrote: > On 03/08/2017 11:08 AM, Rich Freeman wrote: >> And a parting bit of trivia: The overwhelming majority of >> Gentoo-based installations use upstart as their service manager, >> despite it not even being in the Gentoo repository. >> > > This I find interesting, what data source is this based off of? > ChromeOS. It is a Gentoo derivative, and uses upstart as its service manager. And it gets installed on more new laptops than OSX. Yes, the #1 desktop Linux distro is a Gentoo derivative. Take that Canonical. :) -- Rich
Re: [gentoo-user] [Off-Topic] arch-openrc
On Wed, Mar 8, 2017 at 1:50 PM, Mick wrote: > Well what do you know?! Alternative to monolithic stack solutions now exist > as alternatives for other distros too: > > https://sourceforge.net/projects/archopenrc/ > > PS. I do not wish to kick off a flame war on this topic, enough electrons have > been wasted in past rants. Just to inform those who may be interested in > this. Interesting. It looks like they bundle all their openrc scripts in the openrc package. I was curious about this since the right place to put scripts is one of those things that tends to come up in debate. In Gentoo openrc, systemd, and anything else keep their scripts in the packages they go with. Pros: - You don't end up with scripts for packages you don't use. - The openrc/systemd/runit/upstart/etc packages don't get bumped 3 times per week when any script changes anywhere (IMO the biggest driver) - If upstream provides the scripts (common for systemd, less so for openrc but it may happen) then make install can take care of them Cons: - You do end up with scripts for service managers you don't use (assuming you don't mask them). - Individual package maintainers have to be at least somewhat concerned with these scripts even if they don't use the service manager they apply to. I think the Gentoo way is better because of the elimination of bumps. However, Arch is much more strongly in the systemd camp (as I understand it), so I suspect there would be more resistance there to maintaining openrc scripts inside individual packages. So, openrc ended up having to bundle them all in one package. The Gentoo approach took a Council decision as some package maintainers objected to the inclusion of systemd units. Other than the initial debate IMO it has gone smoothly since. And a parting bit of trivia: The overwhelming majority of Gentoo-based installations use upstart as their service manager, despite it not even being in the Gentoo repository. -- Rich
Re: [gentoo-user] rotating backup script
On Tue, Mar 7, 2017 at 12:04 AM, wrote: > I was looking at this rotating backup script > > source: > https://community.spiceworks.com/topic/34970-how-to-create-rotating-backups-of-files > If you're looking for rotating backup solution based on rsync I'd take a look at rsnapshot. It is in the Gentoo repo, and it has been completely dependable in my experience. You get the same kind of storage you'd expect with plain rsync (just a replica directory tree that you can freely read, cp from, etc). However, it does stuff like ensure backups are complete before rotating them in, handling the rotation itself, and also linking incremental backups with hard-links to reduce storage. It isn't quite de-duplication but it gets you 90% of the benefit vs having a bunch of complete backup directories that each take up the capacity of a full backup. Basically it copies the last backup using hard links, then rsyncs over that. The result is what looks like a bunch of full backups but without all the space use. If you're looking for something even more space-efficient that is still based on rsync but which does not store its files as a simple replica directory tree then look at duplicity, which is also in the Gentoo repo. It stores the data in compact archive files like most other backup solutions, but it uses librsync to do most of the heavy lifting. If 1kb changes inside the middle of a 1TB file it only stores the extra 1kb, just as rsync would only transfer the 1kb. It also has a bunch of backend options, including a few cloud services like S3. For remote backups it is pretty smart about how it stores metadata vs data so that if the local cache gets out of sync it can just re-fetch the metadata from the cloud without having to retrieve the actual backup data, and it supports gpg. I personally use both right now. High-value files are saved using duplicity to an S3 backend, fully gpg encrypted. Since I like to mess with zfs/btrfs I also keep a full replica of those drives locally on ext4 using rsnapshot. This is very easy to restore should btrfs eat my data (and I've made use of it twice). Rolling your own can certainly be an educational experience, but IMO it is unnecessary. Of course, be sure to test recovery no matter how you end up setting everything up. -- Rich
Re: [gentoo-user] SHA-1 has just been broken
On Mon, Mar 6, 2017 at 2:59 PM, Andrew Savchenko wrote: > On Thu, 2 Mar 2017 19:04:06 -0500 Rich Freeman wrote: >> >> Huh? I thought protection against DMA attacks was half the reason for >> an IOMMU in the first place. >> >> https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit > > Even the page you cited contains: > ``Some units also provide memory protection from faulty or > malicious devices.'' > > Please note the word "some" here. > > IOMMU was created to restrict OS access to devices (and bring > desired guest VM direct hw access when needed). While it may be > used the other way around — to protect OS from device — it usually > don't work this way, not every IOMMU even supports this. How can it be possible to bring VM guests direct hw access without providing protection of the OS from devices? They use the same mechanism. The driver in the VM tells the card to write to address XYZ, not knowing that address XYZ in the guest is different from address XYZ in the host. The host programs the IOMMU to remap the device access to the correct address. The same mechanism would let the host remap device DMA to anywhere, or nowhere. Restricting OS access to devices seems odd unless you're talking about something like a phone with a second protected CPU. I imagine most CPUs treat IO access as a privileged operation, and certainly x86 does. So, if a process attempts to write to an IO port it will be interrupted and the OS can block the access. > > If we'll look further, IOMMU bypass is a part of normal operation > of many device drivers: > https://lists.gt.net/linux/kernel/365102 Yeah, I wasn't familiar with how poorly it is actually implemented, and obviously the IOMMU is only as good as its programming. > And the funniest stuff: even if IOMMU can be and is configured to > sandbox malicious devices, it can be easily bypassed in most real > world implementations: > https://hal.archives-ouvertes.fr/hal-01419962/document This is just an exploit, and in this case the IOMMU wasn't configured to sandbox the device at all. If it were configured with minimal access it certainly wouldn't have write access to the IOMMU configuration. > So relying on IOMMU to protect from malicious devices is even more > naive than relying on SHA1 for crypto integrity needs. So, I think we're conflating poor implementation with a flawed algorithm. SHA1 is fundamentally insecure and there is nothing you can do to make it more secure without making it something other than SHA1. IOMMU is more of a concept, but I suspect that much of the hardware in actual use probably works just fine, but nobody spends much time ensuring that Linux actually secures it. Tighter controls around the software would make it secure. This seems a bit like saying that the concept of process memory protection is flawed because at various points in time some versions of Linux have had bugs that allow processes to modify memory they shouldn't be able to modify. The concept is completely sound, but the implementation is imperfect. I think the main reason that nobody tolerates sloppy implementation of memory protection is that a lot of software is written in C and if memory protection doesn't work it is only a matter of time before the host is crashing, especially for a software developer. On the other hand, most devices aren't designed with so many bugs so by the time you're actually plugging cards into PCs they're not going to be randomly accessing RAM, and it is a lot harder to get a device to write to random RAM locations than it is to have a pointer error in your C code unless you're actually developing a device driver (and if you have a bug in a device driver you could very well have programmed the IOMMU to let the device write to the wrong RAM anyway depending on where the error lies). But, sure, I'm perfectly happy to accept your assertion that device drivers today tend to open gaping holes in the IOMMU making their security unreliable. Linux namespaces are in a similar state, eventually they should become secure but right now the sense is that they have exploitable flaws. -- Rich
Re: [gentoo-user] Gpgme oddity
On Sat, Mar 4, 2017 at 11:30 AM, Peter Humphrey wrote: > On Saturday 04 Mar 2017 14:59:51 Alan McKinnon wrote: > >> ... It's a ~arch package, so you get to be a field tester when you use it >> :-) > > As Marc said, it isn't. But I'm incredulous that gpgme wasn't tested on a > standard KDE system. That just beggars belief. > In general, packages aren't tested on any particular desktop environment prior to stabilization. I'm sure the KDE packages get tested in KDE (probably on Plasma), but that's about as far as it is likely to go. Now, packages might happen to be tested under KDE. I'm not saying that is a good thing, or a bad thing, just that this is how it has worked for as long as I've been using Gentoo. -- Rich
Re: [gentoo-user] SHA-1 has just been broken
On Thu, Mar 2, 2017 at 6:26 PM, Andrew Savchenko wrote: > On Thu, 2 Mar 2017 03:42:24 -0500 taii...@gmx.com wrote: >> >> The IOMMU (theoretically) protects the CPU and memory from rogue >> devices, such as the hard drive. > > No. Any DMA capable device can bypass IOMMU. IOMMU was not > designed to protect OS from device. > Huh? I thought protection against DMA attacks was half the reason for an IOMMU in the first place. https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit -- Rich
Re: [gentoo-user] SHA-1 has just been broken
On Mon, Feb 27, 2017 at 8:10 PM, Miroslav Rovis wrote: > Apologies for my not being able to reply sooner! > > On 170227-18:18+0300, Andrew Savchenko wrote: > >> > And via a new private big business, the Github. Giving over all users to >> > big Github brother. >> >> ??? >> Github is entirely optional and is only for those who want to use it >> (we have both users and devs willing so), but in no way anyone >> demands its usage. > Yeah! Still, it would be great if git was used in distributed way, and > not from a central private business... > Git can pretty-much ONLY be used in a distributed way. In the sync workflow github is basically just a mirror. A lot of our mirrors are run by private businesses, and nobody knows what OS they're even hosted on, let alone whether the firmware and CPU microcode are FOSS along with their hard drive firmware. As far as distribution goes I think github is the wrong thing to worry about. What you want is traceable signatures from dev to user. Once you have that you can download from an NSA mirror and there shouldn't be any risk. All a mirror does is replicate data, and if modifications are detectable the worst they can do is a DoS. Most of the concerns that people tend to have with github is that you can become dependent on them for issue and pull request tracking and then if they decide to pull the plug you lose all that data. We try to minimize the use of these features and not make it a core part of the dev workflow. But, we do use pull requests and in theory we could lose those someday. The actual code itself gets pushed to the Gentoo infra Repo from a developer's box using plain old git after they've inspected/tested/etc it. So, there isn't really any way for Github to go injecting commits into the repositories we actually use. I guess they could do it for anybody using our github mirrors on the distribution side, but that's only because we don't have that all locked down and the same issue applies with any other mirror (rsync, etc). Again, you really need end-to-end signature checking to make any of these things truly safe. -- Rich
Re: [gentoo-user] SHA-1 has just been broken
On Mon, Feb 27, 2017 at 1:02 PM, Alan McKinnon wrote: > > I always though git's use of SHA hashes was to identify commits and > detect random bit flips, not to provide any measure of security. > As somebody said in Twitter recently (and Linus to some degree in his post), it is, except when it isn't. git supports gpg signatures on tags and commits. The only thing that binds these signatures to the information being signed are sha1 hashes and file sizes, and Google has already demonstrated the ability to manipulate hashes without changing file size. Those hashes apply to blobs and trees, and doing a collision on either lets you modify the contents of the tree. Now, if every commit is being carefully reviewed (via git diff/etc) then the chances of leaking the data needed to make collisions less expensive into the repo is low, as long as you're talking exclusively about text files (which is all we store in the tree). If you go storing pdfs or images/etc in a repo I'm less confident that you could detect attempts to sneak easy-to-collide data into a repo. So, this isn't a reason to panic, but it is a reason for concern. People have been talking about sha-1 collisions for a while. Commit signatures are not the only way to secure the Gentoo repository, but they seem like one of the most convenient to use, assuming we could trust them. I've always seen sha1 brought up as one of the biggest reasons not to. -- Rich
Re: [gentoo-user] SHA-1 has just been broken
On Mon, Feb 27, 2017 at 9:46 AM, Andrew Savchenko wrote: > > So danger of SHA1 collision is much closer than > 9,223,372,036,854,775,808 SHA1 computations or 1 110-GPU year. Indeed in every way it is closer than that than when Google started their project, and tomorrow it will be closer still. The subject line shouldn't really be "SHA-1 has just been broken" but "Another recent confirmation of SHA-1 being broken." We've known it has been broken for quite a while. In the same way, DES wasn't broken when the EFF built their ASIC-based machine. That was just the final nail in the coffin. Anybody who waited for somebody to actually build that machine (and I'd be shocked if bigger players than the EFF didn't have such a machine much sooner) was deluded. When somebody discovers an attack on a hash function that greatly reduces the cost to generate collisions into a number that is even remotely forseeable in the next decade, it is time to stop using that hash function. Sheer inertia ensures that even if everybody started changing overnight it probably would still cause problems when the attacks start getting practical. Sure, there are threat models where it doesn't matter, but on the SHA-1 front it seems like people have been underestimating their exposure. Certainly Gentoo has exposure until git is fixed and the active tree has non-SHA-1 hashes. Even then the historical tree is vulnerable if we don't rehash everything, though in practice I don't think that matters as much, and obviously slipping a non-preimage collision into the historical tree is impossible unless it is done before the hash functions are changed. Sure, you can wave your hands about how hard it is to expoit in practice, and I agree with many of these arguments. However, SHA-1 should be viewed as a vulnerability and fixing it as a priority. For Gentoo specifically it isn't really the weakest link in the chain as was pointed out in the other thread, so I'm not sure I'd go rushing out to fork git. Still, we shouldn't be entirely comfortable with git as it stands at the moment. -- Rich
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
On Sat, Feb 25, 2017 at 9:26 AM, wrote: > > yes the option was set for what reason ever...I will clear that. > Next question...: Do I need v86d still then? Probably not, but I have no idea why you even had it in the first place. > > Another thing which drives me crazy: > Linux-headers! > emerge insists of installing linux-headers-4.10. I am runnig > 4.9.12. Unstable is globally set (~amd64). In general I don't think matching the exact kernel version is important, though perhaps v86d cares if you need that. > > But giviing > > emerge sys-kernel/linux-headers-4.9 > or > emerge 'sys-kernel/linux-headers-4.9' > > gives me > > !!! 'sys-kernel/linux-headers-4.9' is not a valid package atom. > !!! Please check ebuild(5) for full details. > > Even > > emerge sys-kernel/linux-headers-4.10 > or > emerge 'sys-kernel/linux-headers-4.10' > > results in > > !!! 'sys-kernel/linux-headers-4.10' is not a valid package atom. > !!! Please check ebuild(5) for full details. > The syntax would be emerge '=sys-kernel/linux-headers-4.9' The = is critical, since that makes it an atom. Depending on your shell you might or might not need quotes. Again, I'm not sure you really need to worry about it. -- Rich
Re: [gentoo-user] Strange hickups while trying to compile a kernel in a chroot
On Sat, Feb 25, 2017 at 8:59 AM, wrote: > Fernando Rodriguez [17-02-25 14:36]: >> >> Check the CONFIG_INITRAMFS_SOURCE option. >> > > I will check the configs...may be there is something not readable > (permissions) ... I had copied a lot back and forth (I bought one > of those crappy harddiscs, which became full after a while...;) > Did you actually check the CONFIG_INITRAMFS_SOURCE option? It should be blank. If it is not, then whatever file it points to must exist. It might exist on your host, but not in your chroot. This option builds a kernel with an embedded initramfs, which is not normally something you need. Some Linux live DVDs might use something like this, but normal desktops generally do not. If your .config file originated from one of these that could explain the issue. Even if you wanted an initramfs this isn't the way to go about it. (A bit of trivia, Linux actually ALWAYS has an embedded initramfs, but by default it is empty.) -- Rich
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On Wed, Feb 15, 2017 at 5:58 AM, marco restelli wrote: > >> The short version is that the kernel is very limited in what it can >> take in the root= option on the command line, and grub and other >> bootloaders don't do anything to ID the root filesystem other than >> passing whatever root= parameter you specify (I'd be interested in any >> info to the contrary). > > I have always generated grub.cfg files with grub-mkconfig. In some > cases I see here > > search --no-floppy --fs-uuid --set=root > linux /kernel-XYZ root=/dev/sda4 ro > > As far as I understand it, the first line searches the partition where > the kernel is located identifying it through the UUID. Then the second > line loads the kernel passing /dev/sda4 as the system root. > > On the bootable USB stick, with an initramfs, however I have > > search --no-floppy --fs-uuid --set=root > linux /kernel-XYZ root=UUID= ro > > so now also the root filesystem is identified by its UUID. Correct. Just note that "root" in GRUB lingo is the filesystem that contains all the grub binaries, the kernels, and so on. That is typically /boot on a linux system. Unless they happen to be the same filesystem it isn't the same root you pass to the kernel. If it were then you would have the same UUID in the second example. > >> Anytime you see something like root=UUID=* that is being handled by an >> initramfs. > > I understand that this parameter is passed by the kernel to the init > script inside the initramfs which then uses "busybox findfs" to > translate the UUID into a device name. Is this correct? > I suppose that is one way it could be done, but of course it could be implemented in other ways. As far as I can tell Dracut does not use busybox findfs. I didn't do a careful read but a quick look at the source suggests that it is actually using udev and referencing /dev/disk/by-uuid and so on. I suspect the logic is that if udev could find the root device on the host when the initramfs was being built, then it should be able to find it in the initramfs if the same software is used to do it. -- Rich
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On Mon, Feb 13, 2017 at 5:53 AM, marco restelli wrote: > > Could you suggest any reference about how an initramfs can help making > it easier to identify the correct root filesystem? Does this > functionality overlap with what grub can do, or is something > different? > The dracut references are fairly extensive, but they probably assume that you already know about something like this. Keep in mind that on virtually all other distros end-users aren't expected to set up their own kernels or initramfs so there isn't a lot of general documentation out there. And even within Gentoo a lot of people seem to avoid an initramfs, so our own docs may not be as extensive as they could be. The short version is that the kernel is very limited in what it can take in the root= option on the command line, and grub and other bootloaders don't do anything to ID the root filesystem other than passing whatever root= parameter you specify (I'd be interested in any info to the contrary). The kernel itself can't handle UUIDs or filesystem labels. It actually can handle some situations like lvm on top of mdadm, but that is about as complex as it gets as far as I'm aware, and even in that situation there are some limitations. An initramfs is typically implemented in a bunch of shell scripts (though it is really a full userspace so in theory you can really have it do anything). That gives it a lot more flexibility. Typically they run udev which gives you all the /dev/disk/by-id symlinks and so on. They can also do things like fsck root before mounting it (though mounting it read-only and having it fsck itself isn't a terrible alternative, which is how things work without an initramfs). Basically an initramfs should be viewed as an extended bootloader. For more exotic setups they're essentially required (such as network-based root filesystems). The trend has also been to not add new root-finding capabilities to the kernel as the initramfs is the preferred way of doing things. If lvm+mdadm were being built today, I'm not sure they would make the kernel capable of directly mounting them as root. Anytime you see something like root=UUID=* that is being handled by an initramfs. And of course a UUID is more reliable than a device name, since the latter can change if you add/remove a device, or maybe even if your firmware is having a bad day. Identifying devices by UUID ensures the right one gets found, assuming it is available. If you're using something like mdadm/lvm there are alternatives to UUID, but the point is the same, you're using a logical identifier that is based on what is stored on the disks and not just what port it is connected to. -- Rich
Re: [gentoo-user] fatrace
On Sat, Feb 11, 2017 at 3:23 PM, Jorge Almeida wrote: > $ fatrace > Cannot initialize fanotify: Function not implemented > > Up–to–date system. Maybe the ebuild misses some dependency? > Or some kernel configuration? > Check CONFIG_FANOTIFY. -- Rich
Re: [gentoo-user] Need help interpreting kernel panic
On Sat, Feb 11, 2017 at 2:12 PM, Harry Putnam wrote: > > Again I get a kernel panic but this time its different. It seems to > mount the disks ok but then fails to find a working `init' command. > > Checking that with sysrescueCD I see /sbin/init does exist on that new vm. > and is executable. > > The disk setup is sda1=/boot sda2=swap sda3=/home sda4=/ > My guess is that it is mounting the wrong filesystem as root. It might be detecting /dev/sdb as /dev/sda. Also, the root device might be named /dev/xda4 depending on the kernel/etc. Systemrescuecd isn't using the same kernel/etc so it might not see the disks the same way. An initramfs with root=UUID="505f850e-b26a-4d0f-a02f-6ba573a48ad8" (or a label) would be a more reliable way to handle this, or you can probably just fiddle with the device names until you stumble on the right one. -- Rich
Re: [gentoo-user] Re: Working on fresh install, question about handbook statement
On Fri, Feb 10, 2017 at 9:05 PM, Harry Putnam wrote: > > Don't think I've had occassion to use emerge --config before. > Not many packages use it. I know mysql uses it to initialize the database, which is something you obviously don't want to do every time you update the package. Typically packages will tell you when to run it after install/update if it is available. -- Rich
Re: [gentoo-user] Working on fresh install, question about handbook statement
On Fri, Feb 10, 2017 at 4:52 PM, Harry Putnam wrote: > > What is really puzzling is the the words `reconfigure' that package. > But then there is nothing said about what this `reconfiguring' > consists of. > > It used to be we just either copied the appropriate zimezone section > to /etc/localtime... or symlinked it there. > > Can anyone explain what is meant by `reconfiguring' in this context or > how it is done? > emerge --config sys-libs/timezone-data All it does is copy the timezone data to /etc/localtime. Setting /etc/timezone is still important, because it ensures that anytime the package is updated the new data is copied over (a symlink would also accomplish this). Using emerge --config is a bit more elegant since it will tell you if you made any mistakes in /etc/timezone, and perhaps at some point in the future it might do other things. But, you are correct that the instructions used to just say to copy the file and be done with it, and there is no real harm in doing it that way. Just introducing users to emerge --config probably has a little value in it. -- Rich
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On Fri, Feb 10, 2017 at 6:58 AM, marco restelli wrote: > Hi all, >I am trying to understand a bit initramfs and genkernel and I have > few (basic) questions. > > I understand that one must have in the initramfs those modules which > are required to boot the system, for instance to access /dev . Now: Sort-of. You need an initramfs if the kernel cannot otherwise mount /, and /usr (if it isn't on the same filesystem as /). Being able to mount / is an absolute requirement, there are other ways to go about mounting /usr. An initramfs has some benefits even if the kernel could mount /, such as making it easier or more reliable to identify the correct root filesystem. > > - can a module be present both in the initramfs and as kernel module > in /lib/modules ? > Yes, and typically all of the initramfs modules are present in both. > - how does genkernel decide which modules to put in the initramfs ? I can't speak to genkernel specifically, but most initramfs generators include all modules. Other than space and miniscule load time there isn't much reason not to. > > - can modules included in the initramfs be unloaded once the system is > running, as modprobe -r Yes, assuming it isn't in use. Most of the stuff loaded by the initramfs is probably going to be in use until you shut down (such as the module for the root filesystem). > > - can modprobe load modules from the initramfs ? > Only if it is run from within the initramfs. Otherwise this is like asking whether a binary in a chroot can run something outside the chroot. Of course, typically all the initramfs modules are also present in /lib so modprobe will just load the module from there. > > Well, clearly I am a bit confused about the topic - I hope somebody > can help me a bit! > An initramfs is really just a chroot in some sense. Though, it would be more accurate to say that the system you're using after you've booted is the chroot, and the initramfs was the original host. The initramfs is the root filesystem when the kernel boots, and it basically does whatever it needs to to find the real root filesystem, mount it, and then it deletes its stuff to free up ram, chroots to the real root, and execs the real init. At that point very little of the initramfs is left, other than any kernel modules it might have loaded (which are no different from kernel modules loaded at a later point in time). It is just a way to do userspace bootstrapping. Coreboot/libreboot take this to yet another level. Rather than try to build the smarts into the kernel to handle every conceivable system configuration, the kernel provides the driver and some basic logic, and if you want to do something fancier you use an initramfs and the initramfs can do anything you can do in linux userspace to find and mount root. It could download root from a webserver, or launch postfix and wait for somebody to send the root filesystem as an attachment, or whatever your imagination can come up with. Usually, though, it ends up just mounting /dev/sda2 or whatever. Most distros use an initramfs by default because it is more robust and can handle things like UUIDs and labels. That way if you plug in a new drive and your existing drives get renumbered the correct filesystem gets mounted. That, and it lets them use highly modular kernels without having to know what kind of filesystem you'll use for /, since it can just be modprobed at run time. This lets them build all the drivers as modules, which costs some disk space and a lot of one-time compile time, but gives the end-user more flexibility without any need to custom-build a kernel. Gentoo is a bit unusual in encouraging users to build their own kernels, but of course once you do that then there is no need to build all the drivers, or use an initramfs for modules needed to mount /. Otherwise, there is nothing special about modules loaded from the initramfs. They're just kernel modules. -- Rich
Re: [gentoo-user] [SOLVED] Can I run a 32-bit CentOS chroot on a 64-bit Gentoo host?
On Thu, Feb 9, 2017 at 8:47 AM, Walter Dnes wrote: > On Wed, Feb 08, 2017 at 08:27:41PM -0500, Rich Freeman wrote > >> As you can see, there is limited ability for even root to accidentally >> mess something up. If you bind-mount /dev in a regular chroot >> (without a hardening technology on top) and something running as root >> in the chroot tries to write to /dev/sda, then it will have the >> obvious result. Note that Linux containers are not yet 100% secure so >> this should be viewed as a protection against accidental damage, not >> as equivalent to a VM. Non-root processes inside a container are >> considered to be pretty secure I believe, and I believe root is >> supposed to be OK if it is running in a container in a separate user >> namespace (so it is non-root on the host). > > If building Pale Moon inside a chroot as a regular user is a security > issue... then what can I say about doing personal 64-bit Pale Moon > builds directly on my desktop (*NOT* chrooted) as a regular user??? I was speaking of containers in general, not the concerns specific to building Pale Moon. -- Rich
Re: [gentoo-user] [SOLVED] Can I run a 32-bit CentOS chroot on a 64-bit Gentoo host?
On Wed, Feb 8, 2017 at 7:36 PM, Neil Bothwick wrote: > > It shouldn't matter that they are bind-mounted. The -x switch excludes > anything on a different filesystem. > Agree, but I will note that one of the advantages of using a container and mounting a new /dev is that you get a greatly reduced /dev which helps protect your physical devices. For example, here is /dev from one of my containers: # ls -l /dev/ total 0 crw--w 1 root tty 136, 3 Feb 4 08:57 console lrwxrwxrwx 1 root root 11 Feb 4 08:57 core -> /proc/kcore lrwxrwxrwx 1 root root 13 Feb 4 08:57 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Feb 4 08:57 full drwxr-xr-x 2 root root 0 Feb 4 08:57 hugepages lrwxrwxrwx 1 root root 25 Feb 4 08:57 initctl -> /run/systemd/initctl/fifo lrwxrwxrwx 1 root root 28 Feb 4 08:57 log -> /run/systemd/journal/dev-log drwxrwxrwt 2 root root 40 Feb 4 08:57 mqueue drwxr-xr-x 2 root root 60 Feb 4 08:57 net crw-rw-rw- 1 root root 1, 3 Feb 4 08:57 null lrwxrwxrwx 1 root root 8 Feb 4 08:57 ptmx -> pts/ptmx drwxr-xr-x 2 root root 0 Feb 4 08:57 pts crw-rw-rw- 1 root root 1, 8 Feb 4 08:57 random drwxrwxrwt 2 root root 40 Feb 4 08:57 shm lrwxrwxrwx 1 root root 15 Feb 4 08:57 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Feb 4 08:57 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Feb 4 08:57 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 Feb 4 08:57 tty crw-rw-rw- 1 root root 1, 9 Feb 4 08:57 urandom crw-rw-rw- 1 root root 1, 5 Feb 4 08:57 zero As you can see, there is limited ability for even root to accidentally mess something up. If you bind-mount /dev in a regular chroot (without a hardening technology on top) and something running as root in the chroot tries to write to /dev/sda, then it will have the obvious result. Note that Linux containers are not yet 100% secure so this should be viewed as a protection against accidental damage, not as equivalent to a VM. Non-root processes inside a container are considered to be pretty secure I believe, and I believe root is supposed to be OK if it is running in a container in a separate user namespace (so it is non-root on the host). -- Rich
Re: [gentoo-user] Can I run a 32-bit CentOS chroot on a 64-bit Gentoo host?
On Tue, Feb 7, 2017 at 2:54 PM, Walter Dnes wrote: > > Any idea how to gracefully handle the missing /dev problem? I tried > mounting /dev, /proc, and /sys, similar to the chroot process in the > Gentoo install instructions. But I couldn't unmount afterwards, short > of rebooting. If it's not a problem, I'm OK with the mounts sticking > around permanently. > Did setting up those mounts actually work? They should have. As far as unmounting goes, the handbook instructions recursively set up some mounts so you need to unmount stuff like /dev/pts before umounting /dev (and there might be other examples, I'm going from memory here). This is one of the reasons I like containers. When the last process exits, all this stuff goes away. I suspect sticking something like this before the chroot command might do the trick: unshare -p -f --mount-proc -m -i -u That will create a new PID, mount, IPC, and UTS namespace for the chroot. If you do the mounts after this then when the process exists any mounts will disappear. If you run ps -ea inside you'll see your shell running as pid 1. Now, if you set up your mounts before running unshare then they'll stick around since they were set up in the host namespace and not the container. Most tools for containers like nspawn/docker/lxc/etc will take care of this sort of thing for you. Unshare just exposes the system call without doing any of the setup for you (it is part of util-linux). -- Rich
Re: [gentoo-user] Can I run a 32-bit CentOS chroot on a 64-bit Gentoo host?
On Mon, Feb 6, 2017 at 10:40 PM, Walter Dnes wrote: > > What I'd like to do is a 32-bit CentOS chroot inside my 64-bit Gentoo > desktop host. I'm looking at rsync'ing the / directory from inside the > CentOS VM file system to a directory on the 64-bit host, and then chroot > into the copy on the host. > I'd strongly consider using a container instead of a chroot. There are really no downsides to doing so, and you're far less likely to run into issues once you understand how they work. While I'm not personally a huge fan of docker I'd be shocked if CentOS didn't have official docker images, which would make getting the base OS set up a one-liner. However, for just doing a build a chroot is probably adequate. Either way you'll get a lot more performance than from a VM, especially for something like a build. -- Rich
Re: [gentoo-user] New Installation
On Sun, Feb 5, 2017 at 11:53 AM, wrote: > > Thank you all, yes good advice. I have removed most of the entries from > the "USE=" what is left (and I'm not even sure I need them). This is a good way to get started. Get your system working, then start playing with it. At least you can browse the web while things build then. :) > > USE="... -berkdb I'd question this at a global level. I'm not saying it will definitely cause issues, but the selection of a storage backend seems like the sort of thing you'd want to make per-package and not globally, unless you have a specific aversion to berkdb. If you turn this off on some packages they might fail to run until you set up a mysql database or something for them, and that is probably overkill in some cases. The maintainer's default choice may be more appropriate, again unless you have a specific concern with it. This is the sort of setting that can make perfect sense in package.use. I'll be honest and admit that I probably should give my own USE flags another look. Most of them probably pre-date the existance of USE defaults when a lot more tweaking tended to be needed to get things working right. Believe it or not, this is probably the easiest it has ever been for somebody new to Gentoo. :) Back when I installed we were still recommending doing stage1 installs, and that was on far inferior hardward. Just imagine sitting in a chroot for a day or two before you can even get your box to boot. Oh, and no livecds either, if you didn't have another computer handy (which was more likely to be the case back then - no smartphones/etc), you made do with links. I think we at least made its home page the handbook. -- Rich
Re: [gentoo-user] New Installation
On Sun, Feb 5, 2017 at 11:16 AM, Floyd Anderson wrote: > > That’s why Gentoo is often regarded as the freedom of choice. This includes the freedom to shoot yourself in the foot. I suggest that new users consider going with the defaults except when they have a reason not to. Sure, we can all pass around our make.conf files, and people can just blindly copy what we're using. In a sense this is also stick with the "defaults" - just somebody else's choice of defaults. The difference is that if you don't do this then you're getting the defaults the maintainer thought best, and the settings that get the widest extent of testing. If you run into a problem, you're probably close to the upstream configuration, which means both upstream and the maintainer are probably going to be willing to lend you a hand. You're also closer to the settings used by other distros, which means their own documentation will help you. Stick with the profile defaults to start. By all means tweak something if you have a reason to, but make these conscious informed decisions. Keep things simple. When you start out with a very complex USE configuration on a distro you're new to, then you're going to struggle a lot to deal with the resulting issues. In terms of profiles themselves, hardened isn't the friendliest place to start. It tends to get used in server environments, and I suspect very few run a desktop environment in a hardened environment. I'd suggest chatting with others who run hardened to understand its limitations. I've been running Gentoo for a very long time now and I wouldn't expect to do a hardened desktop install and get through it without a bit of troubleshooting. -- Rich
Re: [gentoo-user] New Installation
On Sat, Feb 4, 2017 at 10:32 AM, Alan McKinnon wrote: > > Size of swap is the classic cargo-cult question, ++ > > Modern kernels DO get nervous if they have no swap at all - it's used > internally. So make a small amount of swap to make the kernel happy, say > 64M or so. Yes, megs. > So, uh, I'd be interested in some kind of citation for this, mainly because it also sounds a bit like cargo cult advice. :) What exactly doesn't work without swap, because I've been running without it for years? -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Thu, Dec 29, 2016 at 8:15 PM, Miroslav Rovis wrote: > > Thanks again to our developers who keep to the matchless Unix tradition, > and allow such great choice in Gentoo (also to the other, poetterware > side, as in choice, if you will)! > Well, the intent is to allow as much choice either way, though sometimes upstream constraints get in the way of that. As long as somebody is willing to do the work necessary to keep a choice reasonably viable we're not going to turn it away. While we differ in our preferences this is what ultimately unites us the most, IMO. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Mon, Dec 26, 2016 at 5:47 PM, lee wrote: > > Yes, and that doesn't show me news before I sync, or does it? > Correct. The order to do this in is: Sync Read news. Apply updates. Syncing doesn't affect anything other than /usr/portage (or wherever you're keeping it). -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Fri, Dec 23, 2016 at 8:52 PM, lee wrote: > > I didn't see portage or anything else give me any instructions or > warnings about this. The names just suddenly changed, and that screwed > things up. > https://www.gentoo.org/support/news-items/2013-03-29-udev-upgrade.html This shows up in eselect news list (and so on), and portage will tell you when you have unread news items. Note that it only shows up if you have
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 7:46 PM, Daniel Campbell wrote: > > How does a file take up less than a single FS block? An inode has to be > allocated _somewhere_, does it not? > So, the details are going to be filesystem-specific, but typically inodes go into some kind of area of the disk reserved for metadata, so that many of them can be stored in a single disk block. They're also fixed-length so storing them in groups lets you address them as an array. Likewise for directory trees, allocation tracking, and so on. In ext4 inodes are 256 bytes by default. So, obviously you can fit 16 of those in a single 4k disk block. 60 of those bytes are used to map the inode to the extents on the disk that contain the file's data. If the data within the file takes up less than 60 bytes then ext4 will store the data inside the actual inode itself since the mapping isn't actually needed in that case. That saves a whole block. Other filesystems do things differently. I don't profess to be a general expert, but I have read a fair bit on btrfs. Btrfs allocates spaces in b+ tree nodes that contain fixed-length records on one side (which would store things like inodes and other metadata records), and a heap full of variable-length records on the other. The latter can be used to store the content of small files. I believe btrfs can also use metadata space to store small regions of files as well (such as if you have a file that is just a few bytes larger than the next block boundary, or when you overwrite 1 byte of a large file which in btrfs does not get done in-place). The optimization of storing small bits of data without using entire blocks is a pretty common one. Another common optimization is dealing with large blocks of zeros in files. If you write a gigabyte of zeros in most filesystems it will certainly not take a gigabyte of space, even if the filesystem does not otherwise use compression. And of course you have stuff that consumes nothing but inodes, like links and device nodes and such. It isn't surprising that these optimizations are widespread on unix-like filesystems since small files for configuration/etc are so common. Not only does it save a ton of space, but it also saves a seek when the file is read. Finally, I'll just comment that if you're interested in brushing up on data structures, the documentation for any of the modern filesystems is a great thing to read up on. Since disk seeks are incredibly expensive but disks are very large a great deal of thought goes into how the data gets stored. -- Rich
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 3:06 PM, Alan McKinnon wrote: > > Doesn't it strike you as curious Not really. :) > 10s of harmless unit files (text), each less than one fs block? > Setting aside the core of this issue (which everybody has already gone on about ad nauseum, myself included), I figured I'd point out that on most modern filesystems very small text files don't actually use blocks per-se, but instead they're stored in the inode or other metadata records. They have to be quite small to fit, but Linux systems tend to have a lot of files that don't require an actual disk block as a result and it can save quite a bit of space cumulatively. -- Rich
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 2:46 PM, Rich Freeman wrote: > On Wed, Dec 21, 2016 at 2:20 PM, wrote: > >> The following USE changes are necessary to proceed: >> (see "package.use" in the portage(5) man page for more details) >> # required by kde-plasma/kwin-5.8.3::gentoo >> # required by kde-plasma/plasma-workspace-5.8.3-r4::gentoo >> # required by net-p2p/ktorrent-5.0.1::gentoo[shutdown] >> # required by @selected >> # required by @world (argument) >>>=media-libs/mesa-12.0.1 wayland > > > I suggest ignoring this for the moment and see if the info above > resolves your systemd issues. I'm not sure why kwin has the > dependency that it does, but it looks to me like it is set up as a > hard dependency that you can't avoid without modifying the ebuild. > I'll see if I can figure out more. The changes above should at least > get rid of whatever is pulling in systemd. > > Installing wayland shouldn't actually hurt anything. I noticed that I > have it installed likely for the same reason, and it isn't like it > will start running on its own. But, I'm not sure yet whether you can > avoid it. > Well, I should have just waited to reply, but here is the issue: https://mail.kde.org/pipermail/release-team/2015-July/008725.html kwin does in fact have a non-conditional dependency on wayland, so you need to install it. It won't do anything if you don't run it, but it is not possible to build kwin without wayland support. Judging by the claim in the email that it used to take 100 conditionals in the source to make it optional, I doubt anybody in Gentoo will be patching this anytime soon. I guess you could always fork it if you wanted to. So, sorry, not what you wanted to hear, and not really what I care to hear either since I don't use wayland, but at least it doesn't need to be running in this case. I wouldn't be surprised if that changes in the future, but everybody knows that xorg is on borrowed time right now. Well, if nothing else at least this splits the thread so that you can reply to the systemd and the wayland issues separately... -- Rich
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 2:20 PM, wrote:
>
> emerge -t --update --newuse --deep --with-bdeps=y --tree --keep-going
> --backtrack=30 --exclude media-video/nvidia-settings --exclude
> app-misc/screen --exclude app-misc/ytree --exclude dev-python/sip --exclude
> app-shells/bash @world -v
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
> [ebuild U ~] sys-apps/openrc-0.23::gentoo [0.22.4::gentoo] USE="ncurses
> netifrc pam unicode -audit -debug -newnet (-prefix) (-selinux) -static-libs
> -tools" 206 KiB
Hmm, do you have openrc in accept_keywords or something? You look
like you're using stable keywords in general, but openrc is pulling in
an unstable version. I suspect this is the root of your problem.
> [nomerge ] sys-apps/openrc-0.23::gentoo [0.22.4::gentoo] USE="ncurses
> netifrc pam unicode -audit -debug -newnet (-prefix) (-selinux) -static-libs
> -tools"
> [ebuild N~] virtual/tmpfiles-0::gentoo 0 KiB
> [nomerge ] virtual/tmpfiles-0::gentoo
> [nomerge ] sys-apps/systemd-226-r2:0/2::gentoo USE="acl kdbus kmod
> lz4 pam seccomp ssl (-apparmor) -audit -build -cryptsetup -curl -elfutils
> -gcrypt -gnuefi -http -idn -importd -lzma -nat -policykit -qrcode (-selinux)
> -sysv-utils {-test} -vanilla -xkb" ABI_X86="(64) -32 (-x32)"
So, openrc-0.23 is pulling in tmpfiles, which is pulling in systemd.
Well, there you go, just unmerge openrc and you won't have it pulling
in systemd any longer.
JUST KIDDING!!! Don't do that...
But, the first sentence is accurate. The problem is that you've
unmasked openrc 0.23, but you probably haven't unmasked
sys-apps/opentmpfiles.
So, the solution is one of two things:
Remove openrc from package.keywords and stay on 0.22.4. I'm not sure
why you were running unstable openrc in the first place, so I'm not
sure if this solution is acceptable to you.
Or, add opentmpfiles to package.keywords so that it can be installed.
Then portage should install that instead of systemd. The reason it is
trying to pull in systemd is that opentmpfiles is masked, and systemd
is stable, so it is going to go with the package that is stable.
In general you're running into this issue because you're running mixed
keywords. I do that, but keep in mind that this configuration is not
tested for consistency by our internal QA tools, so you're going to
sometimes run into issues like these. If you stick with all-stable or
all-testing then you won't run into these kinds of inconsistences.
Or, if you do that QA team that got mentioned in the other thread will
probably have already sent a nasty-gram to the devs involved. :)
> The following USE changes are necessary to proceed:
> (see "package.use" in the portage(5) man page for more details)
> # required by kde-plasma/kwin-5.8.3::gentoo
> # required by kde-plasma/plasma-workspace-5.8.3-r4::gentoo
> # required by net-p2p/ktorrent-5.0.1::gentoo[shutdown]
> # required by @selected
> # required by @world (argument)
>>=media-libs/mesa-12.0.1 wayland
I suggest ignoring this for the moment and see if the info above
resolves your systemd issues. I'm not sure why kwin has the
dependency that it does, but it looks to me like it is set up as a
hard dependency that you can't avoid without modifying the ebuild.
I'll see if I can figure out more. The changes above should at least
get rid of whatever is pulling in systemd.
Installing wayland shouldn't actually hurt anything. I noticed that I
have it installed likely for the same reason, and it isn't like it
will start running on its own. But, I'm not sure yet whether you can
avoid it.
--
Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Wed, Dec 21, 2016 at 1:56 PM, Heiko Baums wrote: > > And this again. You know the difference between OpenSource and ClosedSource? > > You pay for ClosedSource. For OpenSource you don't need to pay. But I > have neither time nor energy to explain you the philosophy (before > Poetterix) of OpenSource. OpenSource has nothing to do with whether something costs money. Not even RMS or ESR would agree with "For OpenSource you don't need to pay." For starters, all software costs somebody something. It might be offered for free TO YOU, but somebody spent a lot of time and effort making it, and somebody may or may not have been compensated to do it. Here is a decent overview from the FSF's perspective, though they're more focused on free software than open source: https://www.gnu.org/philosophy/free-sw.en.html Here is their take on free software vs open source: https://www.gnu.org/philosophy/free-software-for-freedom.html Now, if you asked ESR for his take he'd have a different perspective, though he'd agree with the FSF that neither has anything to do with whether you have to pay for it, and he would agree on the differentiation between OSS and FOSS. Some off the cuff definitions: Open Source: generally means the author makes the source code available. OSI has their take on it which most people accept: https://opensource.org/osd Free Software: licensed in a manner that guarantees the FSF's four freedoms. https://www.gnu.org/philosophy/free-sw.en.html In general all free software is open source, but not all open source software is free software. Either can be free as in beer or not. It is completely legal for me to download a Debian DVD, make some changes to it, put a copy of the source code on the DVD, and offer to sell it to you for $5000 licensed under its original licenses. The only thing I can't do is prevent you from sticking an image of that DVD on your website after you buy it so that nobody else has to buy it from me. In practice a lot of it tends to be free as in beer because FOSS licenses make it impossible to prevent somebody from offering it free of charge, and people tend not to pay for something when they can get the same thing for free. However, companies like Red Hat can and do charge for their distros all the same, usually offering things like support to entice people to pay. When you buy RHEL you're buying the software and not just the support, even if you could get most of it for free without paying for it. > But I can tell you this much. OpenSource and > its developers usually have no commercial intentions. This is true of some open source software. I'm not convinced it is even true for most of it. Half of the companies that contribute to Linux are for-profit entities that have a profit motive behind their contributions. Some of the most popular Linux distros like Ubuntu and RHEL are for-profit enterprises. A few major projects are backed by foundations, but IMO some of them are really only non-profit in the sense that they don't pay dividends to anybody (heck, the US National Football League is non-profit by that definition); some of them have small armies of executives and administrative staff like any other large corporation. Quite a bit of FOSS isn't developed by organizations like Gentoo which are community based with low amounts of money going around. A lot of FOSS is also failed commercial software, or parallel community versions to commercial software (think Fedora/CentOS, or the old MySQL model). And there is nothing wrong with any of this. It is just free software. At worst you can just ignore it. At best you can adapt it to your own needs, or just use it as-is if it fits your needs. We aren't worse off because somebody made it available to us. I might never use RHEL, but the fact that it is out there doesn't hurt me. Maybe the fact that RHEL is actually paying developers means that fewer of them have free time to donate (assuming that you don't care for the stuff RedHat does contribute), but who am I to begrudge somebody the right to make a living? Programmers don't have to be starving artists to claim some kind of moral superiority. Personally I prefer to work in a community-based environment, which is why I'm here and not running Debian (well, that's just one reason, I also prefer the Gentoo approach in general and have used Gentoo since long before openrc even existed, let alone systemd). Ultimately though we're just a small part of a much larger ecosystem. There are things about that ecosystem that I like more, and things that I like less. However, if we allow developers the freedom to create what they want to create then we're going to need to deal with the reality that sometimes they won't want to create the things we want them to. -- Rich
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 1:44 PM, wrote: > Corbin Bird [16-12-21 17:12]: > The first run of emerge tells me to add the systemd USE flag to dbus. > I did that and ran into to problems I reported. Ok, I think you left that bit out... And this is why it is helpful to understand why portage is doing something before just changing configuration settings. Adding the systemd USE flag to packages is a really quick way to end up with systemd getting installed. Generally speaking it shouldn't just happen by default... Can you show the output when you add -t to the emerge command? I think that will be helpful. However, I think an earlier poster was on the right track when he pointed out that the tmpfiles virtual requires an unstable version of openrc. I'm not sure why that was getting pulled in in the first place, and -t should show that. > > emerge: there are no ebuilds built with USE flags to satisfy > "media-libs/mesa[egl,gbm,gles2?,wayland]". > !!! One of the following packages is required to complete your request: > - media-libs/mesa-11.2.2::gentoo (Change USE: +wayland) > (dependency required by "kde-plasma/kwin-5.8.3::gentoo" [ebuild]) > (dependency required by "kde-plasma/plasma-workspace-5.8.3-r4::gentoo" > [ebuild]) > (dependency required by "net-p2p/ktorrent-5.0.1::gentoo[shutdown]" [ebuild]) > (dependency required by "@selected" [set]) > (dependency required by "@world" [argument]) > [1]20322 exit 1 emerge -t --update --newuse --deep --with-bdeps=y > --tree --keep-going > > What? > > Now wayland shall be installed? IK! > I want my UNIX back! Interesting. I just noticed that it pulled in wayland for me. I have no idea why kwin requires wayland support in mesa. It obviously works fine with xorg. I might do some looking into that. There isn't really anything non-UNIX about wayland, though I'm not sure I'd be in a rush to use it just yet. It is just a replacement for xorg (to say the least, it doesn't purport to be a feature-complete replacement and may never be). Your wayland issues and your systemd issues are most likely entirely unrelated... -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Wed, Dec 21, 2016 at 8:36 AM, Corbin Bird wrote: > > The old manual method of configuration is extremely flexible, you can > get the "who-knows-where-it-came-from-component" to work. The new > "automagic" of udev / systemd forget it. At least with script based > init systems I could change the run level to fix Xorg problems. udev and systemd operate based on text configuration files that are declarative in nature. You can certainly change the "run level" in systemd (what you'd call a runlevel in openrc would be a target in systemd). You can even pass the default target on the kernel command line, or change the default target in /etc. As with openrc they aren't numbered and you aren't limited to any particular number of them. There are some standard ones out of the box, like multi-user, emergency, getty, basic, etc. > > The systemd configuration files are designed for programmers, not > technicians. And their is a HUGE difference between "programmers" and > "technicians". Different aptitudes, different skills. The old .conf > files, technicians can easily handle. Requiring everyone to be a > programmer is a really bad idea. > The only "configuration" files openrc supports for services are shell scripts, as opposed to declarative configuration files used by systemd. Now, openrc init.d shell scripts might source configuration from some text file in /etc/conf.d, but there is nothing that prevents systemd units from doing the same. On Gentoo we stick the settings in drop-in files instead, but these are no more complex. Here is an example of a Gentoo systemd drop-in: /etc/systemd/system/ntpdate.service.d/00gentoo.conf [Service] Environment="SERVER=0.gentoo.pool.ntp.org 1.gentoo.pool.ntp.org 2.gentoo.pool.ntp.org 3.gentoo.pool.ntp.org" That hardly requires programming to understand. And here is the entire ntpdate unit file: /usr/lib/systemd/system/ntpdate.service [Unit] Description=Set time via NTP using ntpdate After=network-online.target nss-lookup.target Before=time-sync.target Wants=time-sync.target Conflicts=systemd-timesyncd.service [Service] Type=oneshot ExecStart=/usr/sbin/ntpdate -b -u $SERVER RemainAfterExit=yes [Install] WantedBy=multi-user.target No programming there either. Most of the stuff that is hard to understand in the file are the dependencies, and that is just because you need to learn the terminology that systemd uses, though most of that is straightforward. The After= line is roughly equivalent to "use net dns" in openrc, though systemd has a lot more virtuals defined out of the box and they're more granular. For example, systemd distinguishes between an interface existing, and an interface having an IP/etc, while on openrc we have just one virtual that covers the latter. I know, it almost sounds like the systemd design is intended to support running a diverse service ecosystem. Go figure... -- Rich
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 8:53 AM, Corbin Bird wrote: > > On 12/21/2016 06:59 AM, Matthias Hanft wrote: >> Corbin Bird wrote: >>> The "sys-fs/eudev" package is the Gentoo fork of "sys-fs/udev" for >>> people who don't want systemd. >> Ehm... I still use "sys-fs/udev" (not eudev) without systemd. >> No problems so far. Do I have to worry? >> > > It is currently part of the systemd code base. ( It was merged in some > time back. ) > The ability to separate "udev" code from "systemd" code is going away > very soon. People have been saying that for years. Maybe it will happen some day, maybe it won't. The sys-fs/udev package only works without systemd. It is the upstream udev implementation. > So if you want to run "udev" ... you going to be running "systemd". No > choice. If that ever happens the udev package will go away. Its only purpose is for running udev without systemd. By all means make an informed decision about whether you want to run udev or eudev. However, the udev package will never require systemd to be installed. -- Rich
Re: [gentoo-user] Portage spokes again...
On Wed, Dec 21, 2016 at 7:59 AM, Matthias Hanft wrote: > Corbin Bird wrote: >> >> The "sys-fs/eudev" package is the Gentoo fork of "sys-fs/udev" for >> people who don't want systemd. > > Ehm... I still use "sys-fs/udev" (not eudev) without systemd. > No problems so far. Do I have to worry? > Nope. Standalone udev is only intended to be installed on non-systemd systems. udev vs eudev have their pros and cons, but requiring systemd to be installed isn't among them. To the original poster: I would start with adding -t and reviewing your output before changing anything in make.conf. Yes, adding USE=-systemd probably shouldn't cause any problems, but in general I think it is better to understand the problem before you start trying to fix it. Adding --backtrack=120 or something probably is also a good move, in case it is a dependency issue that portage can figure out on its own. In general increasing --backtrack does not cause any problems, it just makes portage work more slowly. My guess is that you have some package installed that now wants to start pulling in systemd, but -t should identify what is going on and we can dispense with the hand-waving. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Wed, Dec 21, 2016 at 7:09 AM, wrote: > > The problem is that an ever increasing amount of programs list systemd > or some of its libs as a depenancy. So it is getting harder and harder > to opt out. > > The situation is similar to the one with udev and variants. Some > programs list udev as a requirement even though there is no requirment > on technical grounds. I.e. X, I can run X perfectly without udev, I > just have to make my own xorg.conf, or I might want to run X with udev > since then it handles multiple keyboards with different layouts > automatically. It's like when buying a car, some prefer automats, some > stick shift. There are pro and cons for both cases. > I get your frustration. Below is just my personal sense of things, ultimately the entire Council sets policy but this is my sense of the "Gentoo Way" and how I see things being likely to go. On Gentoo at a distro level we're never going to force package maintainers to make any particular package a dependency as long as the software works without it. At the same time we're not going to force maintainers to patch software to eliminate dependencies. We certainly encourage maintainers to do things like this within reason, but we don't require it. In your example, if upstream xorg starts sticking dbus calls to udev/systemd/etc in their code, and it fails to launch if those packages aren't running, then unless somebody patches out that behavior or makes it conditional then udev/systemd would need to be listed as dependencies. It isn't like simply not listing them would fix the issue anyway, it would just cause X to fail to launch for some users. When software just runs without some features without another package installed, then there is no requirement to list it as a dependency (generally speaking). Maybe during the install it might suggest installing some other packages for full functionality. In the end though, if xorg requires systemd as shipped upstream, that is an upstream issue. I realize you'll get a lot less sympathy with many upstream projects than you'll get around here because goals/philosophies differ. And as upstream projects go further down that road, it will in practice become more difficult for a distro like Gentoo to maintain larger and larger patches to alter their behavior. Gentoo as a distro will probably never force a developer to give up, but at some point you're talking about maintaining a fork and not a patch. Now, you can look at eudev and see that there is ultimately no limit on how long that can go on, but it depends on people willing to do the work. Ultimately Gentoo is a place where we all come together to try to support our ability to maintain a diverse configuration space. Still, that diversity largely depends on the interests of those who put in the work to maintain it. And it often comes at a cost of less vertical integration and automation. At a distro level we try to remove barriers to individual contribution, not force individuals to contribute in a manner that we would prefer them to. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Wed, Dec 21, 2016 at 7:36 AM, Tanstaafl wrote: > On 12/20/2016 9:33 PM, Rich Freeman wrote: >> On Tue, Dec 20, 2016 at 5:51 PM, Alan Mackenzie wrote: >>> systemd is primarily a political project, not a technical one. > >> What political benefit do I gain from using and maintaining systemd? > > Interesting that you snipped the rest of his comment - or more his main > point - that followed. > I don't really consider it political, but I think it was largely correct insofar as one of the goals of systemd is to standardize the core system dependencies/etc so that packages can rely on them being present and vertically integrate. I don't agree that you are "forced" to use systemd. Maybe you might be forced to use a different browser or fork your browser or patch it or stick with an old version and backport security fixes if you want to use it without systemd some day. But, if the entire Firefox developer community quit and decided to do something else (a la Thunderbird) you'd be in a similar boat. Sometimes you get what you pay for. I get that people who want to avoid systemd are frustrated by this, but honestly it feels like spitting against the wind at this point. I was frustrated back when everybody stopped taking care of kde-3.5 and kde-4 wasn't really ready and was a resource hog on older systems. I switched to xfce for a while, because ultimately I can't demand that the kde project cater to my whims. The moment you choose to run code that you didn't write yourself, then you become dependent on them. With FOSS it gives you a lot more options as anybody can potentially fork it and take it in a new direction. That doesn't change the reality that developing FOSS takes work, and if 1% of the community wants to take it in a substantially different direction they're going to have a much harder time of it than the 99%. In general though, nobody is required to engage in debates/arguments/etc here, or even read your posts. People choose to participate in list discussions just as they choose what software they want to maintain. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Tue, Dec 20, 2016 at 10:49 PM, Daniel Campbell wrote: > On 12/20/2016 06:33 PM, Rich Freeman wrote: >> We don't have some >> committee on high pick a winner and tell all the maintainers that they >> all have to move from supporting x to supporting y. > > Fair points across the board but this stood out to me. We *do* have > groups that, on some subset of the tree, exert what they feel to be > winners. QA, the KDE team, and GNOME team have all made formal > recommendations or requirements that they expect to see in ebuilds going > forward. QA is blessed by council of course, so they have a bit more > sway. But we're lying if we say we don't have committees making > decisions on packaging guidelines. > > That's not the same as choosing a single package and telling every one > to scram, but we're not hands-off, either. > Anybody wishing to add stuff to the main repository does not get a choice in following QA policy (though these matters can be appealed to the Council). However, their policies for the most part are fairly sensible and concern stuff like listing things as a dependency if you link to them and so on. KDE and GNOME developers work as a team, but these teams do not have any exclusive control over anything in the tree. If a Gentoo developer doesn't like what they've done with kmail they can add a kmail2 or kmail-rich0 or whatever that works they way they want it to. Heck, if a bunch of devs wanted to do their own thing they could start a kde-improved team if they wanted to. In general this doesn't happen, because the developers interested in maintaining these packages tend to agree on how they want to maintain them, or at least they don't care enough to bother with forking them. How do you think we ended up with eudev? -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Tue, Dec 20, 2016 at 5:51 PM, Alan Mackenzie wrote: > > As a reference point, just before I start, I'm a contributor to Emacs, > both new stuff and bug fixing, in both C and Lisp, and (occasionally) I > write documentation. ;-) > Great. I don't use any of that stuff. How would you feel if I told you to just quit doing those things (which you presumably enjoy) to maintain something else that you don't care for, like systemd? That would clearly be wrong of me. People work on the stuff they're interested in. People who are interested in using openrc are going to work on openrc. People who are interested in systemd are going to work on systemd. It is nice if you run into a situation where you work on software I like and I work on software you like. However, that isn't the same as pointing out that you contribute to something that you like, and therefore I should also contribute to something that you like. > On Tue, Dec 20, 2016 at 12:57:02PM -0500, Rich Freeman wrote: >> On Tue, Dec 20, 2016 at 12:44 PM, Heiko Baums wrote: >> > Am 20.12.2016 um 17:47 schrieb Rich Freeman: > >> Anybody can run openrc on Arch linux. They just have to set it up >> themselves, or form a group to share the work. > > There's no "just" to it. It would be a long, time consuming project; > unless, of course you were already intimately familiar with both openrc > and Arch Linux. Sure, and that is how we end up with stuff in the community-based FOSS world. People freely spend their time on long time-consuming projects, so that others can benefit in turn, and probably so that they can personally benefit in some way. If something doesn't work on a particular distro, it is because nobody cared enough to spend a lot of time on it. > > systemd is primarily a political project, not a technical one. What political benefit do I gain from using and maintaining systemd? I don't use any Redhat-originated distros at home or at work. I don't get paid in any way by them, or by anybody who actually profits from FOSS much at all. I'm certainly not going to gain votes on the Gentoo Council by saying I use systemd, since Gentoo has become a bit of a refuge for people who seem to despise it, and far more Gentoo developers prefer openrc to systemd. I use systemd because I personally find it useful, and the reasons for that are largely technical in my judgment. > > Sadly, there are not enough people in the free software world who were > politically aware enough, and energetic enough, to fight this purloining > of our software by Red Hat. Sometimes when people make different decisions than you do, it isn't because they don't know something that you know, or because they're not as smart as you. Sometimes they just have different priorities. I don't consider Red Hat taking over the world a serious threat. Heaven forbid they donate more free software that I can choose to use or not if I wish. > >> > That's true for Gentoo, Slackware, Devuan, and maybe still Debian, but >> > not for the other Distros like Ubuntu and its derivatives, Arch Linux, >> > Redhat, Fedora etc. > > >> Anybody can maintain openrc on any distro. > > No they can't. Or at least, not unless they make it their main spare > time occupation, and already are competent hackers. They could also hire somebody to maintain it for them, or barter what they have in some way. Maybe I could be persuaded to do a little openrc work for you on Arch if you spent some time improving vim. :) > >> Maybe they can't put it in the official repository, that would be up to >> the people who control those repositories. However, as everybody is >> quick to point out the dependency list for sysvinit+openrc is >> incredibly light, which makes it fairly easy to run on any distro. You >> could probably get sysvinit running on arch in 15min. > > Sorry, but that's so far out of kilter with reality I have to object. If > you are intimately familiar with openrc, the Linux booting system, > administrative things (like where to find the source code), technical > things (how to build it, how to link it into Linux), you just _might_ > manage it in a few hours. Somebody starting from scratch is not going to > get sysvinit running on a different distro in 15 hours, never mind 15 > minutes. You don't need to know anything at all about openrc to get sysvinit working. Sysvinit doesn't depend on openrc in any way. sysvinit consists of one 60-line configuration file (most of which is comments), 8 binaries, and 5 symlinks. Oh, and some manpages and docs and stuff. It isn't very hard to set up. And that is how you go about things like this, one step at a time. > > I thoroughly dislike a
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Tue, Dec 20, 2016 at 4:53 PM, Neil Bothwick wrote: > > Yes, the predictable names are pointless on a single-NIC system, which is > why there exist simple methods to switch back to the old way. > Either that, or just use a wildcard. I just stick e* in my network configuration so that it doesn't matter on single-NIC systems. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Tue, Dec 20, 2016 at 12:44 PM, Heiko Baums wrote: > Am 20.12.2016 um 17:47 schrieb Rich Freeman: >> Clearly nobody forced you to run it, because you aren't running it >> now. > > That's again one of those silly arguments. I'm just not running it > because I'm using Gentoo again. On Arch Linux they forced systemd onto > the users. Because the Arch Linux users don't have any choice if they > want to use Arch Linux, because they e.g. don't want to compile anything > and still want to have bleeding edge software. Anybody can run openrc on Arch linux. They just have to set it up themselves, or form a group to share the work. > >> Nobody is going to waste their time trying to convince you that >> systemd is better than anything else, because in the end your opinion >> doesn't actually affect us. > > Because of your ignorant attitude. Fortunately it's not only my opinion. > Unfortunately the Poettering fanboys are just the loudest but not the > majority. No, your opinion doesn't affect me because the only thing you've been contributing is noise. I don't need your help to run systemd, or anything else, and you aren't offering it besides. If anything it works the other way around. There seem to be a lot more Gentoo devs who run systemd who are actively contributing openrc scripts than Gentoo devs who run openrc who are actively contributing systemd units. I haven't actually done a poll but I see a lot more people asking the systemd team to help them write systemd units than people asking the openrc team to help them write init.d scripts. >> People who prefer systemd will maintain >> it, and people who prefer openrc will maintain that, and we can all be >> happy. > > That's true for Gentoo, Slackware, Devuan, and maybe still Debian, but > not for the other Distros like Ubuntu and its derivatives, Arch Linux, > Redhat, Fedora etc. > Anybody can maintain openrc on any distro. Maybe they can't put it in the official repository, that would be up to the people who control those repositories. However, as everybody is quick to point out the dependency list for sysvinit+openrc is incredibly light, which makes it fairly easy to run on any distro. You could probably get sysvinit running on arch in 15min. Openrc would take longer, mainly because you'd have to adapt the scripts for any services you care about. But, it isn't THAT hard to do. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Tue, Dec 20, 2016 at 11:33 AM, Heiko Baums wrote:
> Am 19.12.2016 um 15:52 schrieb Marc Joliet:
>> That is incorrect, systemd allows for overriding files in
>> /etc/systemd/system/${unit_name}.d/*.conf.
>
> Then this is very new.
>
They've been supported for quite a while (Mar 2013):
https://lwn.net/Articles/542609/
Before then the most straightforward solution was to override the
entire unit, which was hardly difficult. There is a systemd utility
for helping you see what files might be able to removed from /etc in
favor of distro-supplied ones as they become available.
>> Furthermore, service units can
>> read environment variables from a file via EnvironmentFile.
>
> Initscripts can do the same.
Obviously. The claim was made that systemd units can't take
configuration from an outside file and had to be directly modified.
The point was just that this was incorrect.
>
>> I'm not convinced that you actually understand systemd particularly well. It
>> seems to me that if you want to develop an informed opinion about it, you
>> should:
>
> You don't need to be convinced. It's sufficient that I know systemd
> pretty well from the beginning when the Poettering fanboys of Arch Linux
> forced this crap onto the Arch Linux users, while they regularly were
> telling that they don't force it onto their users, that it will be only
> optional.
Clearly nobody forced you to run it, because you aren't running it
now. And if you wanted to run openrc on Arch you certainly could.
Nobody will help you do it, but it certainly can be done. I'm not
sure what the point of that would be, since the whole point of a
distribution is to share the workload of doing stuff like that with
people who are like-minded, and since you clearly disagree with the
Arch developers on this issue then it probably makes more sense to do
your own thing.
The beauty of FOSS is that you have the source, so you can make it
into whatever you want to be. How do you think we got openrc working
on Gentoo in the first place?
Nobody is going to waste their time trying to convince you that
systemd is better than anything else, because in the end your opinion
doesn't actually affect us. People who prefer systemd will maintain
it, and people who prefer openrc will maintain that, and we can all be
happy.
--
Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Mon, Dec 19, 2016 at 10:19 AM, Alan McKinnon wrote: > The truth is, as designs > go, sysvinit is a /terrible/ design. It only lasted 30 years because it > forces all the tricky bits to be someone else's problem > I'm not sure I'd go as far as saying "terrible" - it does what it does reasonably well. I just doesn't do much. When people compare "systemd vs sysvinit" they're usually comparing systemd vs some other service manager, since all sysvinit does on 99% of installations is spawn some gettys and run the service manager. One of the things that is obviously missing from sysvinit is the ability to make non-persistent runtime changes. You can tell it to re-read inittab, but you can't say "please spawn 1 more getty, but don't do that next boot." The closest you could get to that is modifying inittab, refreshing init, then restoring inittab and not refreshing init. Systemd makes gettys just an instanced service, and you can of course start/stop those at will. I believe you can also feed systemd a unit without actually putting it on disk anywhere, though I'd need to double-check that. Since it uses D-Bus there is a lot you can do with it via IPC, and in fact that is how the various helper programs actually work. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Sun, Dec 18, 2016 at 3:23 AM, Daniel Campbell wrote: > > Thankfully the kernel seems to have sane management; as long as Linus is > around, anyway. Just recently AMD had some of their code rejected, so > with a vigilant-enough team, you can effectively protect your project > from monied interests (be it poor code or an attempt to manipulate). Now > picture what might have happened if AMD was employing Linus or had some > other sort of contract. (For the record, I use an AMD CPU and like it; > they just happened to be the most recent corporation who's rejected code > popped on my radar. No bias intended.) > I think this is an oversimplification of the issues involved in the AMD situation, which as with so many of these things people just jumped on picking sides. And I think what has gotten lost is an issue that actually comes up somewhat often in FOSS. Let's step back and look at the reality in the gaming on Linux domain: there are basically two GPU manufacturers in the game (AMD/NVidia), and neither one has their best GPU drivers in the mainline kernel. Both of them contribute to drivers which ARE merged into the kernel, but in both cases these lack features found in the out-of-mainline module. AMD has been attempting to merge their better driver into the mainline kernel. As far as I'm aware (I could be wrong) Nvidia hasn't really tried to do this for the most part and are content to just keep shipping a blob. AMD's reasons are certainly at least somewhat selfish, as maintaining all that code out-of-tree is expensive since linux doesn't have a stable API for drivers. Ok, AMD wants to add a more capable driver to the kernel, and obviously Linux users would prefer a more capable driver in the kernel, so what is the problem? And this is where we come to an issue that happens from time to time in FOSS: the needs of the kernel maintainers are not aligned with the needs of the AMD driver maintainers. The AMD and NVidia out-of-mainline drivers both use an abstraction layer to map the kernel APIs to an internal set of APIs used by the driver, because their drivers are multi-platform. I'm not sure exactly how their internal APIs work in both cases. They might internally target the Windows APIs, or they might even target a virtual API and use a translation layer on every platform. This allows them to use one set of code for their core logic across all platforms, at the cost of overhead on Linux (and possibly on other platforms as well). On most platforms this is no big deal because the APIs on those platforms are stable. On Linux this is not the case, and the maintainers prefer to have the freedom to modify their internal APIs and not maintain their own translation layers for backwards compatibility. IMO both sides are basically "right" in their designs, because they have different priorities. The AMD driver code isn't "poor code" - it just isn't natively written for Linux and so it has a lot of code that is theoretically unnecessary (in a world where all devices run Linux). And that is of course more code for the Linux maintainers to deal with if they accept the driver into mainline. On the other hand, writing a driver that purely targets Linux means having to change the core part of the driver anytime the Linux APIs change, which then means changing the translation layers on every OTHER platform out there, when those platforms otherwise feature stable APIs, or having a 3-layer solution (Linux to single virtual API to various stable platform APIs). Now, if the Linux maintainers wanted to have a stable API but wanted to refactor their code internally, then you could actually have a multiple-layer situation as well. You could have Linux internal APIs to Linux stable API to AMD virtual API translation going on (which I suspect is what happens on Windows). As far as I'm aware Microsoft doesn't care if vendors use translation layers, because they don't touch those modules other than testing them (which they get paid to do anyway). Both sides of this debate can legitimately cite maintainability as a reason to not give in. The Linux guys don't to have to maintain a de-facto stable API (which is what the translation layer turns into). The AMD (and NVidia) guys don't want to write a different driver on every platform. Keep in mind that besides Windows and Linux, they may have multiple test harnesses that they need to map into their drivers, and probably other OSes as well. There is also a huge benefit to having the same bug list on every platform for the most part. And Linux users benefit when the "Optimized for " work done for Windows automatically hits Linux as well, which gives the publisher more incentive to spend the extra few bucks to release a Linux version of the game. So, saying that this is about moneyed interests trying to somehow corrupt the "purity" of FOSS isn't really right here. Ultimately issues like this become a bit of a tragedy for all. And mind you, I'm not trying to say
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Sat, Dec 17, 2016 at 1:20 PM, Heiko Baums wrote: > > And the next silly argument which always comes from these Poettering > fanboys. As if everybody is a programmer, and as if everybody who uses a > computer and/or Linux has to be a programmer. > Well, beggars can't be choosers. That's just life. If you want somebody else to solve your problems for you, and you have nothing to offer in trade, then you probably should at least try being nice. Yeah, I get that it is frustrating when nobody else wants to do it your way. It happens to all of us. You'll get further in life if you learn to work within these constraints than if you merely yell at people when it happens. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Sat, Dec 17, 2016 at 9:35 AM, Heiko Baums wrote: > Am 17.12.2016 um 14:17 schrieb Neil Bothwick: > >>> So tell me how I >>> get a full refund for systemd and how to switch to something usable. >> >> I've answered the latter, your refund is attached :) > > No, you didn't. Well, how much did you pay for systemd, and who did you pay it to? And as far as how to switch to something usable goes, the last time I checked sysvinit was still open source. > > The solution can't be to just install a totally outdated version of a > distro from times before they started forcing systemd onto their users. > This has to be possible with recent versions, too. > > So tell me, how to get rid of systemd on Arch Linux, Debian, Raspbian, > XBian, Ubuntu, Fedora etc. in their most recent releases. > Are you willing to: 1. Do the work yourself? or 2. Pay somebody else to do the work for you? This really comes across as whining because a bunch of volunteers decided to volunteer their time building things the way they would prefer to build it, instead of the way you preferred that they build it. If you don't like the options out there, then make your own. If you don't think the guides on how to install Gentoo on a Pi are good enough, then play around with it until you figure it out, and then post an article on the Wiki. Look around Gentoo, or Arch, or Debian. Everything you see is the result of somebody sacrificing their time to create something and make it free for everybody. If something seems to be missing, it is because somebody didn't sacrifice their time to create it. If you care strongly about something, then at some point you need to get your hands dirty and create the future you want to see. Complaining on a mailing list isn't going to motivate somebody to help you. -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Fri, Dec 16, 2016 at 11:51 AM, Miroslav Rovis wrote: > On 161216-08:35-0500, Rich Freeman wrote: >> >> I'm not sure I understand what distinction you're making. I can't say >> I'm intimately familiar with the security model around Pulseaudio (at >> a glance it seems similar to X11 with its use of cookies, though >> obviously if you tell it to broadcast unencrypted multicast RTP on >> your LAN you'll get the obvious effects) but X11 has a couple of >> glaring security weaknesses. The most obvious is the fact that any >> random X11 client can read the keyboard input of any other client on >> the same server unless you jump through a bunch of hoops that I don't >> think anybody actually jumps through (though I do believe some of the >> X11 PIN entry programs may use them at least). Anything you type into >> an xterm could be read by your browser, and in turn by any code able >> to execute outside any sandbox that browser might have (root privs not >> needed for this). > > I don't claim it can not, but I doubt anyone can do it in my > grsecurity-hardened based Gentoo machine. As far as I'm aware grsecurity provides no protection against X11 client evesdropping. This is an X11 "feature" and not an exploit per-se. Here is one overview of the possibilities: https://pipefish.me/2012/08/28/spying-on-screens-and-keystrokes-the-dangers-of-open-x11/ Any program that has access to your X11 cookie and which can connect to your X server (which includes anything actually displaying a window on your screen), can generally grab any of the keyboard input bound for any window on your screen. There are ways for programs to block this, but they're not super-practical. Amusingly enough I stumbled upon this blog: https://blog.separateconcerns.com/2014-10-24-cli-passwords.html This page "helpfully" suggests that you can secure your system by using a console pinentry program instead of an X11-based one, with the underlying assumption being that console software is more secure for this sort of thing. While the basic assumption is probably true, in this particular case it is definitely not. Entering a password on an actual virtual console or over ssh is in fact secure. However, entering it into an xterm (which is presumably what you're using if you would otherwise be using an x11 pinentry program) is absolutely not secure. The x11 pinentry program probably uses XGrabKeyboard to ensure that other clients can't evesdrop, while the console-based version doesn't know anything about x11. Some xterm implementations have a secure mode buried in the menus which turns on this mode which you can use to safely enter passwords, but almost nobody knows about this. There are a lot of "cargo cult" tips out there which are based on a lack of understanding of how software like X11 actually work. Of course, X11 is so convoluted that almost nobody actually understands everything about how it works, which is why Wayland has always been right around the corner. In general, though, it largely dates back to an era where people had rsh listening on all their hosts. > >> And I wouldn't be surprised if a lot of X servers still run as root >> for modesetting/etc. > > What user is that? It you want, tell me how to check it, and let's see > how spyware-prone my system is. If you don't have USE=-suid on your xorg-server package, then X is probably running suid root. In order to not have it run this way you need support for kernel modesetting. I was surprised when I found out that X11 even worked that way (we're talking late 90s here). It seems a bit like running pppd as root so that it can directly talk to a UART because you have an aversion to using /dev/ttyS*. In any case the kernel devs have generally been making the move to kernel modesetting so that your device drivers actually are in the kernel and not in random userspace programs (I'm all for microkernels, but not like this). If you don't have kernel modesetting enabled then X11 won't be able to run with -suid set. Google for gentoo kernel modesetting for a guide on how to enable it on most modern hardware. > > It's been discussed over and over again. Lots of people are firm in > their understanding that Lennart is an actor by and for the big > business. Me too. Well, he is a Red Hat employee. Nobody really debates that. > > Whatever would anybody try to claim Pulseaudio code is, but to make up > for what was missing in some FOSS GNU Linux boxen for the missing > functionality that the big players couldn't otherwise get for their > Total Surveillance... > Uh, if the NSA wanted to spy on your box I doubt they'd do it by trying to sneak something into the open-source pulseaudio code
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Fri, Dec 16, 2016 at 8:13 AM, Miroslav Rovis wrote: > On 161216-07:16-0500, Rich Freeman wrote: >> On Fri, Dec 16, 2016 at 5:19 AM, Miroslav Rovis >> wrote: >> > >> > In my stron opinion, and opinions are allowed in Gentoo, just not >> > imposing your opinion onto others (and that I am not doing, feel free >> > to disagree!), pulseadio is spyware, read more here: >> > >> > Re: [Alsa-user] sans-pulseaudio Firefox? was: a strange thing >> > https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg31928.html >> > >> >> What exactly about Pulseaudio do you think makes it "spyware?" The > You're right actually. Or might be. It is likely not spyware in itself, > but it surely is spyware enabler. Like dbus and all of poetterware. > > And about xorg. Everybody uses it, I do too. Minimalistically. Just > enough to have, say Firefox and Wireshark, and a good *nix programs that > need gui. But I'd think the possibilities for spying-required remote > connections with xorg are nowhere near to what poetterware and > associates offer. > I'm not sure I understand what distinction you're making. I can't say I'm intimately familiar with the security model around Pulseaudio (at a glance it seems similar to X11 with its use of cookies, though obviously if you tell it to broadcast unencrypted multicast RTP on your LAN you'll get the obvious effects) but X11 has a couple of glaring security weaknesses. The most obvious is the fact that any random X11 client can read the keyboard input of any other client on the same server unless you jump through a bunch of hoops that I don't think anybody actually jumps through (though I do believe some of the X11 PIN entry programs may use them at least). Anything you type into an xterm could be read by your browser, and in turn by any code able to execute outside any sandbox that browser might have (root privs not needed for this). And I wouldn't be surprised if a lot of X servers still run as root for modesetting/etc. > That's why they came into existance, after all. Uh, somehow I doubt that Lennart wrote Pulseaudio just to simplify the task of getting audio off of a local host so that somebody can spy on you. Maybe it had something to do with the fact that before it came along just doing something like plugging a USB headset into a Linux desktop was a bit of a chore? Well, if you prefer not to use Pulse, that's of course up to you. I wasn't running it for ages, and I probably still wouldn't be running it if I didn't have issues with running multiple desktop sessions as separate users (one of those things that stuff like pulse+policykit and so on was designed to help fix). -- Rich
Re: [gentoo-user] from Firefox52: NO pure ALSA?, WAS: Firefox 49.0 & Youtube... Audio: No
On Fri, Dec 16, 2016 at 5:19 AM, Miroslav Rovis wrote: > > In my stron opinion, and opinions are allowed in Gentoo, just not > imposing your opinion onto others (and that I am not doing, feel free > to disagree!), pulseadio is spyware, read more here: > > Re: [Alsa-user] sans-pulseaudio Firefox? was: a strange thing > https://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg31928.html > What exactly about Pulseaudio do you think makes it "spyware?" The fact that it supports remote connections? I hope you're not using X11... Obviously you do need to use a secure configuration so that random hosts aren't tapping your microphone, but it would be news to me if this was allowed in the default configuration (and certainly a bug that should be fixed on Gentoo). I never bothered to migrate to pulseaudio for years, but started having random issues when logging into multiple X11 sessions from multiple users (probably a console permissions thing). Moving to pulse fixed that, and was surprisingly simple. While many probably don't need its features it makes a lot of sense to me... -- Rich
Re: [gentoo-user] Gentoo-sources-4.9.0
On Tue, Dec 13, 2016 at 12:09 PM, Peter Humphrey wrote: > Hello list, > > Has anyone stumbled over a display problem with this kernel? Copying the > .config from 4.8.14, tweaking with oldconfig and compiling left me with a > blank display and no booting activity. > > The display card is an AMD/ATI Tonga Radeon R9 380X and I load the latest > microcode during kernel compilation. I have VIDEO_CARDS="amdgpu radeonsi" in > make.conf. Fine with earlier kernel versions but not with 4.9.0. > I haven't really had time to investigate but I've had an issue like this with my radeon card (using KMS) for a few weeks now. I'm on the 4.4 upstream kernel. sddm and X11 in general work just fine, but if I try to switch to another virtual console the mouse cursor disappears but the X11 display otherwise remains in place. I suspect some kind of regression for radeon ended up in the stable queue. I'll have to take a closer look at my kernel config to see if perhaps it is now using a newer driver, but that seems unlikely as usually there aren't configuration changes in the middle of a stable series (and I've been on 4.4 for months now). -- Rich
Re: [gentoo-user] Umasking media-tv/mythtv-0.28?
On Tue, Dec 6, 2016 at 1:48 AM, Mick wrote: > On Monday 05 Dec 2016 21:58:55 Rich Freeman wrote: >> On Mon, Dec 5, 2016 at 4:33 PM, Paul B. Henson wrote: >> >> From: Rich Freeman >> >> Sent: Thursday, December 01, 2016 12:14 PM >> >> >> >> The other issue is that my mythtv front-end died shortly after I got >> >> it into the tree, and I've ended up moving off of mythtv. >> > >> > Bummer; out of curiosity, how are you satiating your media needs now? >> >> I ended up on Plex (after being sufficiently annoyed with a brief >> trial of Kodi). It was something I had been contemplating in any case >> as my cable provider was starting to cut off non-encrypted cablecard >> access to more and more channels (used to be just the premiums which I >> didn't get anyway, but when I couldn't record something on the >> National Geographic channel I felt they had crossed a line).The >> hardware issue just pushed me over the line. That, and trying to get >> mythtv working on a pi3 was turning into a bit of a project and I had >> a dropping WAF at the time. > > Out of interest, what annoyed you on Kodi? > It has been a little while. I think the UI in general was a little annoying (not a lot of TV-based UIs that worked well from across a living room, especially for somebody with poor vision). However, the biggest pain was the media scanning. I found that Kodi had a lot of trouble matching stuff without NFO files, and Plex seems to get it right on the first shot 98% of the time. That is a major help. -- Rich
Re: [gentoo-user] Umasking media-tv/mythtv-0.28?
On Mon, Dec 5, 2016 at 4:33 PM, Paul B. Henson wrote: >> From: Rich Freeman >> Sent: Thursday, December 01, 2016 12:14 PM >> >> The other issue is that my mythtv front-end died shortly after I got >> it into the tree, and I've ended up moving off of mythtv. > > Bummer; out of curiosity, how are you satiating your media needs now? > I ended up on Plex (after being sufficiently annoyed with a brief trial of Kodi). It was something I had been contemplating in any case as my cable provider was starting to cut off non-encrypted cablecard access to more and more channels (used to be just the premiums which I didn't get anyway, but when I couldn't record something on the National Geographic channel I felt they had crossed a line).The hardware issue just pushed me over the line. That, and trying to get mythtv working on a pi3 was turning into a bit of a project and I had a dropping WAF at the time. -- Rich
Re: [gentoo-user] Bash script: make a convenient /mnt/gentoo tree for a new install or development
On Sun, Dec 4, 2016 at 12:59 PM, Gregory Woodbury wrote: > The Gentoo Handbook provides detailed instructions for preparing a > /mnt/gentoo > file system tree for new installations. After having to dig through the > Handbook a > few times of doing new or re-installs of Gentoo using an existing Gentoo > install > as the base system, I wrote this script as a shortcut way to handle the > process > of doing the mounting of /mnt/gentoo either the first time or again after a > re-boot. IMO it would be a lot easier if we just had an install CD that included nspawn. :) For whatever reason there seems to be a lack of systemd-based rescue CDs out there. While I'm placing orders I'd like ZFS on Linux support on it as well. :) -- Rich
Re: [gentoo-user] Umasking media-tv/mythtv-0.28?
On Wed, Nov 30, 2016 at 9:55 PM, Paul B. Henson wrote: > Any dev thoughts on unmasking media-tv/mythtv-0.28? I don't generally > have issues with keywording unstable packages for testing and deploying > ahead of the curve, but I usually try to avoid things that are package > masked, particularly on relatively production stuff like my daily dose > of TV :). > > It looks like there are three open bugs on 0.28 that might need to be > addressed before it gets unmasked: > > https://bugs.gentoo.org/show_bug.cgi?id=582218 > > https://bugs.gentoo.org/show_bug.cgi?id=582608 > > https://bugs.gentoo.org/show_bug.cgi?id=591006 > > > It also seems the current ebuild forces the logserver on if you're not > using systemd? The logserver is deprecated and upstream recommends > against using it, I'm currently using a local 0.27 ebuild with it > disabled using openrc, any particular reason the 0.28 ebuild forces it > on if you're using openrc? It should be largely fine to use, with the sorts of caveats you've already noted. The fact that this was still pending for openrc was one of the reasons it is still masked. The other issue is that my mythtv front-end died shortly after I got it into the tree, and I've ended up moving off of mythtv. I don't believe Cardoe is actively using it at the moment so it is in a bit of limbo. However, it almost certainly works and tweaks to improve it are certainly welcome. I'm sure cardoe would commit them but if not I can try to help out with that. I just have no way to test anything at the moment so I don't want to fiddle with it without testing feedback from an active user. -- Rich
Re: [gentoo-user] Re: vm still grinding away at compiling webkitgtk-2.14.2
On Sun, Nov 20, 2016 at 11:00 AM, Alec Ten Harmsel wrote: > On Sun, Nov 20, 2016 at 10:32:25AM -0500, Harry Putnam wrote: >> Rich Freeman writes: >> >> > Are you building in a tmpfs? That would perform better than an ssd >> > and would be much less wear on your flash besides. Of course, some >> > packages do take a while to build. I don't notice as much now that I >> > do most of my building from cron, but it can be painful when you have >> > dependency chains or soname changes. >> >> I hope this isn't more low grade density on my part but you do mean a >> tmpfs on the vm right? >> > > I'm not Rich but I'm sure that's what he means. I have an SSD, and using > a tmpfs for building speeds up builds significantly - probably 10-15%. > > This will mean that you'll need a significant amount of memory allocated > to the VM. Mounting a tmpfs defaults to half of the memory available to > the machine, which seems like a decent rule of thumb. If you give the VM > 8GB of memory, the tmpfs will have 4GB of space. > Well, I was directing it more to John who brought up building on an ssd (which should make fairly little difference if you're doing the build in a tmpfs, though I'm sure it would speed up the install/clean, and it probably would make a difference for very short package builds; once the build is running the stuff on your ssd should be rapidly cached anyway). But, yes, I would DEFINITELY use a tmpfs in a VM if you can manage the RAM. A VM disk will perform even worse than a regular drive and there is no need to go writing all those object files only to delete them at the end. You can control the space allocated to a tmpfs via a mount option. Of course you need to reserve RAM for the build itself, you could very well want more than half of your RAM going to the tmpfs. Memory for tmpfs is only consumed when it is in use, so allowing more space use isn't a problem as long as you don't have things that will just dump files in the tmpfs and leave them lying around. Your other option would be something like zram if you're really desperate, but that takes a bit more work and I think its allocation is fixed. -- Rich
Re: [gentoo-user] Re: vm still grinding away at compiling webkitgtk-2.14.2
On Sun, Nov 20, 2016 at 9:48 AM, John Covici wrote: > On Sun, 20 Nov 2016 09:25:58 -0500, > Harry Putnam wrote: >> >> Rich Freeman writes: >> >> > IMO over-committing CPU isn't actually THAT bad. The CPU obviously >> > gets divided n ways, but that's as far as it goes. There isn't that >> > much overhead switching between VMs (though there certainly is some). >> >> [...] >> >> Thanks for the fuller picture and putting in the time to write it. >> >> > > > On my i7 machine with 16g of ram, webkit-gtk has got to take 4/5 hours > to compile. This is using an ssd. > Are you building in a tmpfs? That would perform better than an ssd and would be much less wear on your flash besides. Of course, some packages do take a while to build. I don't notice as much now that I do most of my building from cron, but it can be painful when you have dependency chains or soname changes. -- Rich
Re: [gentoo-user] Re: vm still grinding away at compiling webkitgtk-2.14.2
On Sun, Nov 20, 2016 at 8:45 AM, Harry Putnam wrote: > "J. Roeleveld" writes: > >> Also, overcommitting CPUs has a bad influence on performance, >> especially if the host wants to use all cores as well. > > That is what I asked advice about. What do you call > `overcommitting'. For example with only 1 Vbox vm started and no > serious work being done by the windwos-10 os. On an HP xw8600 with > older 2x Xeon 5.60 3.00Ghz with 32 GB ram > IMO over-committing CPU isn't actually THAT bad. The CPU obviously gets divided n ways, but that's as far as it goes. There isn't that much overhead switching between VMs (though there certainly is some). Over-committing RAM on the other hand can definitely cause more serious issues, because then you're dealing with swap. Dividing 1 CPU 3 ways gives you 1/3rd of a CPU (but collectively the 3 VMs are putting out close to a full CPU's worth of work). If you're over-committing RAM and you go into swap, then the performance of all your hosts might drop considerably, adding up to WAY less than the total your box is capable of. If your host is windows then this isn't an option for you (seriously, you should re-consider that), but if you could use a linux host another solution is containers. In general they are FAR more flexible around RAM use and of course RAM tends to be the most precious commodity when you're running guests of any kind. With a container you don't have to pre-allocate the RAM, so if Gentoo needs 8GB of RAM right now it isn't as big a deal because in 15min when you're done building it will go back down to 100MB or whatever it actually needs to run. In general Gentoo doesn't need a lot of RAM to operate, it is a fairly minimal distro in general. Now, obviously if you're running webkit then you're running it as more of a desktop and that is going to consume a lot more RAM than a console-based system, on any distro. If anything you could still tweak USE flags and CFLAGS to reduce your RAM footprint compared to most distros (whether this is worthwhile is another matter). However, the one exception to this is when you're building things. Ideally when you're building you want to use lots of cores, which means more gcc instances using more RAM each, and you want to be doing all of this on a tmpfs that uses even more RAM. Back when I was running Gentoo VMs I would typically set the RAM use to something fairly minimal (think ~1GB or less). Then when I was doing updates I'd up the setting to basically all the free RAM on my host and allocate multiple CPU cores to it, then mount a tmpfs on /var/tmp. When I was done building I'd shrink it back down to a normal config. And I wouldn't be doing builds on multiple hosts at once. These days with containers I just run emerge on a few at a time and I don't worry about it (still with /var/tmp on a tmpfs in each). Now, I wouldn't go building chromium and libreoffice in multiple containers at once that way, but for typical server-like guests very few packages use THAT much RAM. -- Rich
Re: [gentoo-user] sans-dbus was: gnome intrusion?
On Sat, Nov 19, 2016 at 4:59 PM, Tom H wrote: > On Wed, Nov 16, 2016 at 7:47 AM, Miroslav Rovis > wrote: >> >> Ah, I almost forgot. Gentoo is as default (OpenRC) without dbus! Have a >> look: >> >> https://wiki.gentoo.org/wiki/Comparison_of_init_systems >> >> There is no D-Bus under "Main dependencies" for OpenRC (I really like >> OpenRC...) > > There's no reason that the fact that OpenRC doesn't depend on dbus > should imply that something higher up the stack cannot depend on dbus! > I'd also comment that utilizing dbus and spawning random processes that you don't understand are orthogonal issues. Dbus is just an IPC mechanism. -- Rich
