User Mode Linux (UML)

User Mode Linux (UML) is one of the earliest virtualisation solutions for Linux (the other one is lguest, which is only available for 32-bit kernel).

It has been largely superseded by KVM and of only academic interest these days, but it still has life left in it. For example it can be used to provide relatively easy and safe, secure sandboxing of untrusted applications.

Since 620beta1, Fatdog comes with UML support, all you need to do is install "linux_uml" and "uml_utilities" packages from the repositories and you're good to go. Open terminal, and type "start-uml.sh" and off you go: the script will automatically create a "throwaway" VM with 256M of memory. Shut the VM down by shutting it down from the desktop, or just close the Xephyr window. It is "throwaway" in the sense that as soon as you stopped the session, all is gone - no traces of it is ever saved in your machine, at all.

If you want to be able to save your UML session, create a blank directory somewhere to save your "savefile". Then start UML like this: "start-uml.sh /path/to/your/session/directory". It is important to note that this directory must already exist, otherwise it is ignored and you'll end up with a throwaway session again.
Once UML has run for the first time in this way, it will create a "config" file in that your session directory; which you can edit later. A 128MB savefile is also automatically created for you; if you need anything bigger, just delete that savefile and edit the config to specify a larger value. The options in the config file should be self-explanatory but in case it is not, you can look at /usr/lib64/uml/start-uml.sh --- the top of that file contains default settings of these config options as well as their explanation.

Mini-FAQ

1. Q: Why UML, why not KVM or even VirtualBox?
A: UML uses your existing Fatdog setup - no need for separate ISO etc. UML consumes lesser resources (memory and CPU) than a full virtualisation system like KVM or VirtualBox, and I believe it is much easier to setup.

2. Q: Fatdog already has sandbox, so what is this UML for?
A: Fatdog's sandbox isn't meant for security. It was originally devised for testing foreign packages, so while it can be used for other purposes, there is information leakages to/from the sandbox; and this is intentional - otherwise you'll face problems when testing. For example sandbox and the host shares the same "/tmp" directory. Fatdog's UML however, doesn't suffer from such problem - host and UML guest is completely separate.
E.g. If you choose "shutdown" from sandbox's desktop, you will shutdown your entire system (not only the sandbox). Not so with UML. Choosing "shutdown" from UML's desktop will just shutdown UML VM.

3. Q: What can the UML VM do?
A: Almost everything the host system can do. Browse internet, run network applications (servers), etc. Probably not good enough to watch videos, though - there is no video acceleration in UML.

4. Q: I understand that the UML is isolated, but is there a way to pass data to/from the the UML? Otherwise how can I ever do anything worthwhile with UML?
A: Of course there is. The point is, these data sharing is completely under your control.

A1. You can setup a "savefile", which can be opened while the VM is offline; from there you can copy data to/from it.

A2. You can copy data using the network (e.g. using samba rox app / yassm, netcat, ssh, rsync, etc).

A3. You can create additional disk images which can be mounted both by the host and by the UML (using ubdxxx parameter - see below). You can open these disk images from host when they are not mounted from UML VM; and when done you can mount them and access the data from the inside the VM.

5. Q: UML only loads Fatdog's base sfs. Is there a way to load additional SFS too?
A: Yes. Specify additional SFS like this (assuming you want to use a throwaway session):
start-uml.sh "" ubd1rc=/path/to/your/sfs ubd2rc=/path/to/your/sfs

etc. "udb1rc" will show up as "/dev/udbb", "udb2rc" will show up as "/dev/udbc", and so on.
To load these SFS, once you're inside the UML VM, open terminal and type:
load_sfs.sh /dev/udbb

load_sfs.sh /dev/udbc

and so on. If you're using persistence then replace "" with path to your session directory.

6. Q: UML desktop doesn't show any drive icons.
A: Yes, on purpose. Drive icons needs "udev daemon" and daemons takes up additional resources, so they are not run unless they are absolutely necessary. If you need drive icons do this from terminal; type this in terminal inside the UML VM:
udevd --daemon; udevadm trigger --action=add 


7. Q: Does running UML require root access?
A: No. You can run UML even if you're not root. Inside UML, you're still root :)

8. Q: The UML VM starts with a desktop. I don't need no stinking desktop, give me the console!
A: If you use saved session, edit your config file and empty out the START_CMD option. If you use throwaway session, do it like this:
start-uml.sh "" START_CMD=
You still still get an empty Xephyr window (so that you can type "xwin" later and start a desktop if you wish), if you don't need it just close that Xephyr window.

9. Q: OK, now that I can use console only stuff, I need more consoles. How do I get that?
A: Many ways. The easiest way would be to run:
getty 38400 tty1 &
Replace "tty1" with tty2, tty3 etc as many as you need. A bit of warning: Do not close the xterm windows that are opened automatically, otherwise your UML VM may hang. They will be closed automatically when you close the UML VM.

10. Q: UML is slow!
A: Unlike other virtualisation solutions, UML does not create demand to your CPU - it will simply use whatever idle power which is give to it. The default CPU frequency scaling governor in Fatdog is "ondemand", which means that the CPU power will be raised only when it detects that there is a "demand" / need for it. UML does not create this demand (even though in reality it is running slow), so the governor does not think it necessary to make the CPU go faster. To fix this, temporarily change the default CPU frequency scaling governor from the default "ondemand" to "performance" (which means run the CPU at full power) while running UML. There is a commented script of how to do so in /etc/rc.d/rc.local.

11. Q: Why this information is not in Fatdog's FAQ?
A: It will, sooner or later. Be patient

12: Q: I need further information!
A1: Visit UML's web page here: http://user-mode-linux.sourceforge.net/old/

A2: See what kernel options are available by opening terminal and running this (from host!):
/usr/lib64/uml/vmlinux --help

A3: See what other script options and how Fatdog's UML works by looking at the scripts in /usr/lib64/uml



Posted on 17 Apr 2013, 6:47 - Categories: Fatdog64
Comments - Edit - Delete


Fatdog turns 5 today

It has been a long journey. Nobody took count of time, and we went where the wind blew. The road was long, the days were filled with weariness and sweats and joy. We saw happy faces, we met frowning grimaces. The sails kept falling down, the wheels kept breaking down; but we fixed them and we toiled and we went along.

It has been five years.

Nobody knows what happens next. Prediction is a difficult business, especially when it is about the future. But we know one for sure - the desire is still strong, the hands are still steady, and Fatdog will continue to plod along.

Read more of Fatdog's history here.



Posted on 12 Apr 2013, 5:42 - Categories: Fatdog64
Comments - Edit - Delete


Fatdog64 620beta3 is released

I'm running out of time, so I will short and sweet. Fatdog 620beta3 has been released with a lot of improvements. Check it out!

Announcement: http://murga-linux.com/puppy/viewtopic.php?t=85530
Release Notes: http://distro.ibiblio.org/fatdog/web/620beta3.html

Posted on 9 Apr 2013, 15:57 - Categories: Fatdog64
Comments - Edit - Delete


Updates to the Radeon saga

This is the continuation to my previous post of the radeon problems. Earlier we thought the newer kernels will fix it. They didn't. We've tried to upgrade Xorg to the latest one. It didn't fix it. We tried to disable all the advanced KMS acceleration features. It didn't fix it.

Our latest attempt, upgrading to kernel 3.8.5 also doesn't fix it.

But there is a light at the end of the tunnel. As mentioned before, JustGreg found out that problem didn't happen if one use "coldplug", or even "loadmodules". I found out yesterday that the problem also doesn't happen if I blacklist radeon, then boot to console, wait a little until the dust settles, and then load the module myself manually using modprobe (followed by starting the desktop, of course).

Previously my guess was that the radeon module needs to be loaded early, and indeed loading it early with "loadmodules" and "coldplug" makes it work. But yesterday results told me that loading it late also works. What gives?

I noticed this: the way "coldplug" and "udev" works is different. "Coldplug" load modules serially (ie, one at at time), while "udev" load modules in parallel (many at a time) - and in fact that's one of udev's benefits --- parallel loading makes boot process a lot faster.

So my guess is this: somehow loading modules in parallel makes things brittle for radeon module - it may work one one time but not on the other time. There may be some race conditions, or perhaps locking / synchronisation issues when multiple modules are being loaded at the same time, that only happens in the recent kernels, in a very specific conditions. Now I'm not sure what the conditions are, but it definitely happens on radeon. It may happens in other modules too (perhaps nvidia?), but so far we haven't noticed anything else.

Assuming that the hypothesis above is correct, then the workaround is simple: load radeon module by itself. Don't load it under udev. And that simple idea seems to work, so that would be the fix we're going to apply.

Of course, the best is to fix whatever the real underlying issues in the kernel or radeon module itself, but neither myself or kirk are kernel developers , so we leave that to the experts

Posted on 6 Apr 2013, 5:52 - Categories: Fatdog64
Comments - Edit - Delete


Radeon problems

There is some problems brewing with Radeon card owners when using radeon open source drivers on the latest Fatdog beta (620beta2). The problem is: it simply doesn't work - there will be image corruption and Xorg server crash, sometimes to the point of locking up the computer requiring hard power-cycle. Not good.

Upon further investigation, it seems that the problem is caused by GPU lockup when using that driver.

As far as I'm aware, this happens only on UEFI machines and only on relatively new machines. My test machine can boot either in UEFI or BIOS mode (CSM = Compatibility Support Module), the problem only happens when I boot using UEFI - same machine, same version of Fatdog64, but different outcome.

Some possible workarounds (from forum member JustGreg - thank you!):
- Boot using BIOS mode
- Use the "coldplug" boot parameter
- Use "loadmodules=radeon" boot parameter
- Use Catalyst proprietary driver.

The 2nd and 3rd workaround forces radeon module to be loaded earlier than other modules. For some unknown reasons, this would prevent the problem from happening .

Anyway, kirk has just compiled a newer kernel - 3.8.3 and in our (limited) experiment it seems that the problem is now gone (although 3.8.3 brings a problem of its own ). So there is hope that the workarounds are no longer necessary for the next release of Fatdog.

Posted on 19 Mar 2013, 20:26 - Categories: Fatdog64
Comments - Edit - Delete


Two new apps for Fatdog

Along with bluetooth support, I created two new applications for Fatdog (briefly mentioned in the bluetooth thread).

First is a new Fatdog Default Soundcard wizard. This wizard replaces kirk's venerable Multiple-Sound-Card-Wizard (MSCW). The new wizard extends support for bluetooth audio streaming; as well as ALSA plugin controls (currently "plug" plugin, "dmix" plugin and "equaliser" plugin are supported).

Second is the new Fatdog Dialer, replacing venerable PupDial (Puppy Dialer). Fatdog Dialer provides (hopefully) better user interface, supports unlimited number of profiles (vs two in pupdial) as well as some options to support GPRS/3G dial-up more transparently, including automatic module loading etc (mainly targeted towards blackberry-modem users).



Posted on 8 Mar 2013, 18:27 - Categories: Fatdog64
Comments - Edit - Delete


Bluetooth support merged to Fatdog64

I merged bluetooth support to Fatdog64 today. The bluetooth support consist of cut-down versions of bluez and gnome-bluetooth, as well as a few support scripts not in those package.

Fatdog64's bluetooth support consists of the following:

a) supports bluetooth HID devices (mouse tested, keyboard may work too). You only need to pair them and they should work immediately.

b) supports audio-streaming (bluetooth speakers). After you pair them you need to enable them using Fatdog Default Soundcard settings available in Sound section of Fatdog Control Panel. Note that I have not tried two-way audio using a bluetooth headset.

c) supports dial-up 3G/GPRS bluetooth modems. To get this to work, first you need to pair them; then you need to detect the modem using Setup Bluetooth Modem in Network section of Fatdog Control Panel. After your modem has been set-up, you can use the Fatdog Dialer to make your call.

This is just a subset of the bluetooth stuff I figured out in here:

a) I decided to take out obexd (for sending and retrieving files from bluetooth devices), because currently it is only half-working (only sending works, while the more useful feature - receiving (e.g. pictures etc) - currently doesn't work).

b) I have also decided not to incorporate bluetooth PAN functionality as I don't have devices that supports doing that automatically (My trusted Nokia N900 can do that, but it needs manual configuration). Anyway, what is required for PAN to work as a client is just "pand --connect bluetooth-address" followed by "dhcpcd bnep0" - if the other end supports it. Setting up the other end to be the PAN master (PAN AP or PAN GN) is more complicated.



Posted on 8 Mar 2013, 18:18 - Categories: Fatdog64
Comments - Edit - Delete


Another release of Slackbone64

Slackbone64 is a "barebone" version of Fatdog, based on Slackware binaries. "Barebone" as in it contains only a "minimal" set of packages. It is intended for distro builders, or those who wants to custom-build an OS for specific purpose, or tinkerers.

Slackbone64 is released as "Slackbones64" with the hope that it will have many descendants.

Slackbone64 is co-maintained by myself and Q5sys - I maintain the base ISO and devx, Q5sys maintains the repositories (a much harder job than doing the base ISO!), the release, and the public-facing website. Being a derivative of Fatdog, Slackbone64 also gets substantial contribution from kirk - for example, in the latest release, it uses the same kernel as Fatdog 620beta1 kernel (Linux 3.7.7) - which is compiled by kirk; and that is only one example among many others.

You can get a taste of slackbone from http://slackbones.org/.


Posted on 4 Mar 2013, 14:35 - Categories: Fatdog64
Comments - Edit - Delete


Fatdog64 620beta2 is released

Fatdog64 620beta2 was released a couple of days ago. Many thanks who helped to test beta1 and reported issues.

Aside from the package-manager update, kirk did most of the work as I was busy with personal matters.

Highlight of this release would be Linux 3.7.10 kernel - which is supposed to fix the problem with bricking of samsung laptops; fixes with autochown on non Linux filesystems; and inclusion of the fix-usb.sh script I mentioned earlier here.

Posted on 8 Mar 2013, 18:03 - Categories: Fatdog64
Comments - Edit - Delete


Re-claim USB flash drive space

Fatdog64 ISO image is an isohybrid. It can be burned into a CD or DVD, but it can also be "imaged" or "flashed" (or just dd-ed) to a USB flash drive like this:


dd if=fatdog.iso of=/dev/sdb bs=4M

Replace /dev/sdb above with your actual USB flash drive device name, and make sure it is pointing to your USB flash drive and NOT YOUR HARDDISK (otherwise irrecoverable data lost will happen). If you're not sure, don't do this - and you can ignore the rest of this post.

The problem is, due to the UEFI isohybrid structure, after you do this, the rest of the USB flash drive becomes unusable, because there is not partition table entry that provides access to this space. Easy, just create one, right? Yes, but the most common tool to do so, gparted, won't work (it won't recognise the hybrid MBR/GPT partition tables in the flash drive). fdisk will work, but it is too scary for most people.

I have created a simple script that will automate this process - behind the scene it will use sfdisk to create the partition (=partition 3). After using the script, you still need to make a filesystem on it, but after that you're good to go.

The script does some checking to ensure that you only target a USB flash drive (=making sure it is not removable, making sure it is connected through USB port, making sure that partition 3 on the target device isn't already exist.

Future version of Fatdog64 will have this script included in the ISO image (so you can run it from the USB flash drive you have just dd-ed), but for now, it is available here: fix-usb.sh


Posted on 20 Feb 2013, 22:33 - Categories: Fatdog64
Comments - Edit - Delete


Pages: ... [7] [8] [9]