Talk:QEMU

From Gentoo Wiki
Jump to: navigation, search
Note
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (~~~~). When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.

egrep -E

Talk status
This discussion is done.

Isn't it redundant to say "egrep -E"? "egrep" is supposed to just be a shorter/alternative way of saying "grep -E". -- Luiji 03:43, 31 December 2014 (UTC)

According to grep(1), "egrep is the same as grep -E" and direct egrep invocation is deprecated. So changed "egrep" to "grep" in the article. -- 0x6177 17:30, 31 December 2014 (UTC)
Feel free to make the article better, Luiji . :) --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

file capabilities

Talk status
This discussion is done.

Is there some documentation on USE="filecaps" actually needing DebugFS in kernel? I see DebugFS used for perf stats, but filecaps seems unrelated. Petteyg (talk) 19:16, 13 March 2015 (UTC)

Try: https://packages.gentoo.org/useflags/filecaps and: https://devmanual.gentoo.org/eclass-reference/fcaps.eclass/index.html --MiroR (talk) 19:52, 7 August 2016 (UTC)

I did more research, as: /usr/portage/profiles/use.desc:

caps - Use Linux capabilities library to control privilege

filecaps - Use Linux file capabilities to control privilege rather than set*id (this is orthogonal to USE=caps which uses capabilities at runtime e.g. libcap)

didn't tell me enough.

On Gentoo Wiki: https://wiki.gentoo.org/wiki/Hardened/Overview_of_POSIX_capabilities (and that link should be included in the article IMO) It's the same capabilities in both the flags, caps and filecaps, just in caps, they are applied on the fly (strace ( emerge strace if you don't have it installed ) the /bin/ping command and you'll see capget and capset called for the command, and /bin/ping is not suid and it does not have filecaps set, not in my machine) and the: /usr/libexec/qemu-bridge-helper from your qemu installation has those capabilities set in file attributes (if you set the filecaps on, still uncertain if that is the good way to go for a grsecurity-hardened, because it cost me the CONFIG_GRKERNSEC_KMEM (see: Use Tor browser on grsecurity-hardened system?))


The base address for understanding of file capabilities is the inventor's page: http://www.friedhoff.org/posixfilecaps.html#POSIX%20Capabilities%20-%20Capability%20Rules ( or http://www.friedhoff.org/posixfilecaps.html from top of page for those who have the time ) Also worth reading is the:
Archlinux Wiki Page on Capabilities ( but if you do the example at the top, replace /bin/ping with /usr/libexec/qemu-bridge-helper, remember /bin/ping is runtime caps, qemu-bridge-helper is filecaps in Gentoo, IIUC ) It is very good and important to know that capabilites can be very much abused: False Boundaries and Arbitrary Code Execution And also there's something wrongly named that has nothing to do with Linux Capabilites too: A concept wrongly named (capabilities were invented previous) --MiroR (talk) 12:55, 14 August 2016 (UTC)

The formatting for this discussion was not good so I cleaned it up a bit. :P Thanks for the info, though. --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

very frustrating

Talk status
This discussion is done.

I had a very frustrating time trying to get this working. I don't want to be all crappy criticism, so I'll come back after I have things working well. There are a lot of kernel options that are missing from this page. I found http://www.linux-kvm.org/page/Tuning_Kernel this little guide] that gave a lot more, but some of this seems to be outdated already. Also, this section needs to distinguish between the kernel config on the host & guest. I finally had to boot the livecd and carefully examine lspci, /proc/config.gz, etc. to figure out what it was doing 'right' and that my guest kernel was doing 'wrong'.

Further, I suspect that grub2 with --target=i386-qemu may be preferable (I haven't actually gotten it working yet), but I was baffled by the lack of documentation, OH MY FUCKING GOD! One of the reasons that I suspect that it may be preferable is that it will install on a device (or image file) that is not fdisk-ed, because you may just want to put a single file system on an image file. Grub2 does not like installing there, but it doesn't seem to mind if --target=i386-qemu. The flip side of this mystery I think I've figured out today -- when you start qemu, you can pass -bios xxx. But xxx isn't just "qemu", it wants a bios file! I had no fucking clue where that was, now I think it's /usr/share/qemu/bios.bin (ran qlist qemu|grep -i bios). I'll try this one out later. Daniel Santos (talk) 23:57, 27 January 2016 (UTC)

Daniel Santos (talk) 23:57, 27 January 2016 (UTC)

Thanks for the input. Feel free to improve the article if things are lacking/missing. Myself and others in the Gentoo community would appreciate it! I'll mark this dicussion as closed for now, since there's really no action myself or others can take on it. --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

/dev/kvm line to change more to the point

Talk status
This discussion is done.

This line:

If KVM support is available there should be a "kvm" device listed at /dev/kvm

should read:

If KVM support is available there should be a "kvm" device listed as /dev/kvm after you boot into the kvm enabled kernel.

It does not show before, as one might interpret the line as it currently is.--MiroR (talk) 20:06, 7 August 2016 (UTC)

Thanks for the input! I'll make the edit this time, but next time feel free to make the edit yourself. This is a publicly modifiable wiki. :) --Maffblaster (talk) 06:40, 31 December 2016 (UTC)

iptables NAT rules

Talk status
This discussion is done as of May 21, 2018.

Just wanted to confirm whether or not the masquerade rule in the article is correct. Under the Configuration section, one of the iptables rules says:

root #iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

Shouldn't that -o option be eth1, instead of br0, so that packets are rewritten with the ip address of eth1 (that way, external routers know where to deliver response packets)? --niteLite (talk) 01:30, 25 January 2017 (UTC)

I agree, eth1 should be masquaraded instead of br0. --Mlyszczek (talk) 18:24, 20 gru 2017 (UTC)

Since no action on this item has been take for many months, I'll apply the fix to this article and close the discussion. --Maffblaster (talk) 16:14, 21 May 2018 (UTC)

module loading

Talk status
This discussion is done.

Reading on another page of wiki, kernel module loading is different on OpenRC from systemd. Why describe only systemd configuration? I have added the OpenRC version but was deleted. --xdarma (talk) 09:24, 26 Feb 2019 (UTC)

xdarma , I removed the conf.d/modules file as OpenRC can now read the same file(s) as systemd does for modules and has been able to for quite a while. This makes explanations easier with just one method for everyone. --Grknight (talk) 14:07, 26 February 2019 (UTC)
Good for OpenRC, but if the default configuration of OpenRC is to read the old file, I think is correct to keep the original configuration. I think systemd users don't care about OpenRC, so why OpenRC users should take care of systemd? --xdarma (talk) 16:04, 01 Mar 2019 (UTC)
OpenRC reads both locations by default with no intervention of the user. If we describe a common location for everyone, then there is less chance of error and frustration. This is about ease of use for users not init1 vs init2. --Grknight (talk) 18:06, 1 March 2019 (UTC)
Only if you write information correctly: there's less chance of error and frustration. Just add that OpenRC can use systemd configuration, why hide something? I think the original configuration of OpenRC has to be write down. As for every piece of software. --xdarma (talk) 15:06, 05 Mar 2019 (UTC)