Native multylib support on Slackware64

Alien Bob · 09-02-2013, 12:29 PM

Quote:

Originally Posted by Jeebizz

I'm kinda on the fence with multilib, I have no problem setting up multilib myself, but perhaps at one point during the installation there should be an option to add multilib to the system, or maybe the best option is to have have a multilib in /extra.

--edit.

Actually /extra might be the best option IMHO.

I hate to repeat myself. Please re-read my earlier post.

Eric

dugan · 09-02-2013, 12:44 PM

Quote:

Originally Posted by chemfire

What are others using 32-bit for at this point? Other than the obvious wine, steam, skype?

And RAM usage. If I'm going to set up a Slackware VM and give it 2GB of RAM, then there's not much point in making it 64-bit.

chemfire · 09-02-2013, 01:04 PM

TobiSGD, you can run X apps including games and the like as long as you completely trust the container. You need to pass a good deal of raw device access through to make it work.

Code:

lxc.arch = i686
lxc.utsname = macro86

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = vth0 
lxc.network.ipv4 = 0.0.0.0/24
lxc.network.name = vth0 

lxc.mount = /var/lib/lxc/macro86/rootfs/etc/fstab

lxc.tty = 2
lxc.pts = 1024
lxc.rootfs = /var/lib/lxc/macro86/rootfs

lxc.cgroup.devices.deny = a
#video
lxc.cgroup.devices.allow = c 226:* rwm
#input
lxc.cgroup.devices.allow = c 13:* rwm
#audo
lxc.cgroup.devices.allow = c 14:* rwm
lxc.cgroup.devices.allow = c 116:* rwm
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
#lxc.cgroup.devices.allow = c 4:1 rwm
#lxc.cgroup.devices.allow = c 4:2 rwm
lxc.cgroup.devices.allow = c 4:3 rwm
lxc.cgroup.devices.allow = c 4:4 rwm
lxc.cgroup.devices.allow = c 4:5 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm

# we don't trust root user in the container, better safe than sorry.
# comment out only if you know what you're doing.
lxc.cap.drop = sys_module mknod
lxc.cap.drop = mac_override  kill sys_time
lxc.cap.drop = setfcap setpcap sys_boot

# if you want to be even more restrictive with your container's root
# user comment the three lines above and uncomment the following one
# lxc.cap.drop=sys_admin

I also reduce the number of gettys running on the host in /etc/inittab on both the host and the contain filesystem, this way I can access the container on vttys 3 and 4.

And the fstab from the container so you can get an idea of what other file system parts are being shared.

Code:

lxcpts /var/lib/lxc/macro86/rootfs/dev/pts devpts defaults,newinstance 0 0
/proc  /var/lib/lxc/macro86/rootfs/proc    none   bind 			0 0
/sys   /var/lib/lxc/macro86/rootfs/sys     none   bind 			0 0
none   /dev/shm 			   tmpfs  defaults 		0 0

/etc/passwd  /var/lib/lxc/macro86/rootfs/etc/passwd  none bind,ro 0 0
/etc/group   /var/lib/lxc/macro86/rootfs/etc/group   none bind,ro 0 0
/etc/shadow  /var/lib/lxc/macro86/rootfs/etc/shadow  none bind,ro 0 0
/etc/shadow- /var/lib/lxc/macro86/rootfs/etc/shadow- none bind,ro 0 0
/etc/sudoers /var/lib/lxc/macro86/rootfs/etc/sudoers none bind,ro 0 0

/home	     /var/lib/lxc/macro86/rootfs/home	     none bind    0 0
/tmp	     /var/lib/lxc/macro86/rootfs/tmp	     none bind    0 0
/dev/input   /var/lib/lxc/macro86/rootfs/dev/input   none bind    0 0
/dev/dri     /var/lib/lxc/macro86/rootfs/dev/dri     none bind    0 0
/dev/snd     /var/lib/lxc/macro86/rootfs/dev/snd     none bind    0 0

Obviously with all this stuff shared the container does little to protect the host from misbehavior going on. You will need all the X libraries and whatnot on the container rootfs, and I have been unable to get things to work anything short of "xhost +" run on the host but if you start an X app as the same user inside the x86 container it will use the host's X server. I play a few games under WINE this way. The host is 64-bit no multilib.

I do get accelerated openGL, but I am using intel graphics you might have to pass other devices through to get AMD/NVIDIA video hardware to work full, can't say. I am also not sure how 'safe' this is in terms of stability all I can say is *I* haven't had any problems.

TobiSGD · 09-02-2013, 01:57 PM

I have no experience with LXC containers, so this looks rather complicated to me. Do you have a link to a good tutorial about LXC?
I think this might only be handy to run 32 bit games, but also to set up conatiners with older OSes for old games that won't run anymore on modern distros.

chemfire · 09-02-2013, 02:05 PM

TobiSGD,

Using containers to directly share X as I have done with this is kludgy at best. The easiest way to get started with LXC on Slackware is to grab Ponce's stuff and adapt it to your needs from there. He has put lots of work into it and it works well.

His blog is at http://slackware.ponce.cc/blog/

Keep in mind containers are not VMs, they basically create discrete name spaces within the kernel. So those "older OSs" will need to be A) Linux and B) new enough to run on whatever kernel your host is using. That can be older than you might at first guess though because you won't run udev and things like the modinit tools inside the container.

This site also has good info for getting started:
http://www.vislab.uq.edu.au/howto/lxc/lxc.html

TobiSGD · 09-02-2013, 02:44 PM

Thanks, chemfire, will have a look into that.

allend · 09-02-2013, 03:43 PM

Quote:

What are others using 32-bit for at this point?

I currently have Alien Bob's cups-compat32-1.5.4-x86_64-2.txz and glibc-solibs-2.17_multilib-x86_64-5alien.txz packages installed on my otherwise pure 64-bit system to support a printer with a 32-bit driver.

I have not used WINE in a long time, preferring to run Windows software either natively in a multiboot system or in a QEMU virtual machine.

yilez · 09-02-2013, 04:00 PM

Quote:

Originally Posted by guanx

Very likely your hardware is capable of running skype without noticable slowdown in a virtual machine.

I consider this from time to time. It seems a bit extreme though, all things considered. I then need VM and a full installation of another distribution (be it Slackware or something else) just to run something that only needed a few extra libraries. If Slackware64 wasn't multilib ready, I might have done it this way as it would need a fair bit more tinkering to set up.

kikinovak · 09-02-2013, 04:36 PM

Quote:

Originally Posted by Raveriux

I think would be better to have posibbility include slackpkg+ in installer under dialog " Do you want to enable third party repositories and multilib?"

Install Slackware.
Download and install slackpkg+.
Open /etc/slackpkg/slackpkgplus.conf with your favourite editor.
Uncomment/add third party repositories.

Keep It Simple Stupid.

GazL · 09-03-2013, 03:57 AM

Quote:

Originally Posted by chemfire

Is only available as a 32bit binary?

Two I've stumbled across recently are:

"Nero AAC codec" (reportedly better quality that faac)
Dwarf Fortress

...neither of which are essential, but if there had been a native version I would have liked to have played with them on Slackware64.

ruario · 09-03-2013, 05:22 AM

Quote:

Originally Posted by dugan

And RAM usage. If I'm going to set up a Slackware VM and give it 2GB of RAM, then there's not much point in making it 64-bit.

TobiSGD previously suggested that the performance benefits of 64-Bit actually start to take effect just below the 1Gb mark.

yilez · 09-03-2013, 05:38 AM

Quote:

Originally Posted by ruario

TobiSGD previously suggested that the performance benefits of 64-Bit actually start to take effect just below the 1Gb mark.

I often find people say "you only need 64bit processors to utilise more than 4GB of RAM". They don't seem to appreciate that 64bit processors can run 32bit code better.

guanx · 09-03-2013, 05:51 AM

Quote:

Originally Posted by ruario

TobiSGD previously suggested that the performance benefits of 64-Bit actually start to take effect just below the 1Gb mark.

I don't see him say so. Nor do I see any benchmark supporting this "1GB" threshold.

ruario · 09-03-2013, 06:35 AM

Well actually (to be more correct) TobiSGD linked to a comment from Hans Peter Anvin.

chrisretusn · 09-03-2013, 11:55 AM

Quote:

Originally Posted by notihnio

Hello slackers,

I believe that PV should seriously think about native multylib support on next Slackware64 releases. What's your opinion?

Thanks

Nope, we have Alien Bob's multilib for that. If I need it, I install it, else I run pure 64. I prefer it that way. I have several 64-bit installs, only one of them uses multilib, the rest are pure.