guess_fstype from busybox
guess_fstype is a small utility to - well, "guess" the "filesystem" that resides in a given block device. It is used extensively in Puppy Linux and its variants including Fatdog. Its job is so important that if you have a malfunctioning binary then most of desktop filesystem operations will cease to work correctly.guess_fstype was originally cobbled from guess_fstype_* functions from mount.c in util-linux (long before util-linux had blkid), it came from the same set of functions which powers "mount --guess-fstype" (which also gives the binary its name).
Over time, more and more filesystem type detections got added, and the code becomes more and more messier. It still works, and it still works beautifully, but it is not easy to maintain. So I began to search for a replacement.
klibc
klibc has an explicit standalone "fstype" binary, which is used to do exactly what guess_fstype does (but its output is different). It is small and fast and static - it's a good candidate. Unfortunately, its repertoire of filesystem detection is less than sterling - it lacks popular filesystems such as FAT and NTFS. While it can be patched to add those two, the point of my exercise is to try to *not* to maintain the detection code myself.
busybox
I turned on to busybox, which also has filesystem detection code. As it turns out, it is relatively easy to use them for a standalone application, and to my delight they are rather complete too. So I created a patch that will create a guess_fstype-equivalent from busybox.
To use the patch:
1. Extract vanilla busybox 1.21 source
2. Apply the patch (get it from here)
3. Go to the volume-id directory
4. Type "make"
5. You will end-up with a bb_guess_fstype which can be renamed to guess_fstype for proper use.
Busybox's guess_fstype recognises less than the original Puppy's busybox, but I don't think this is a problem as what it lacks are "exotic" filesystems anyway (everyone ever user xiafs recently? ) and would be very rarely used, if ever, indeed.
You can fine-tune the filesystem to detect by editing the fake_libbb.h (removing the defines) as well as the Makefile (removing the object code from being linked in).
When new version of busybox is released, all that I need to do is to update this patch. There will be no need to separately maintain the filesystem detection code anymore. As for now, I actually included the f2fs filesystem detection code in the patch, but as soon as this is supported by busybox natively, it will be dropped.
This new guess_fstype will be in the next version of Fatdog.
1 Comment - Edit - Delete
Fatdog64 621 is released
Belated announcement (my DSL was down), but anyway ...Forum Announcement: http://murga-linux.com/puppy/viewtopic.php?p=698707#698707
Release Notes: http://distro.ibiblio.org/fatdog/web/621.html
Get it from: http://distro.ibiblio.org/fatdog/iso
Fatdog64 621 fixes the most annoying bugs from 620 - the "eject problem". Mostly a problem when you use a desktop with an optical drive that can be commanded to close its tray, as well as enabling panning to work properly.
It also has a new on-shutdown filesystem cleanup code which in theory should work identically if not better than before.
Other than that it is identical to 620 release - same kernel, same browser, same devx.
2 Comments - Edit - Delete
Fatdog64 620 Final is released
I'm running out of time, so I will short and sweet. Fatdog 620 Final has been released with a lot of improvements. Check it out!Announcement: http://murga-linux.com/puppy/viewtopic.php?t=85684
Release Notes: http://distro.ibiblio.org/fatdog/web/620.html
Get it from: http://distro.ibiblio.org/fatdog/iso
No comments - Edit - Delete
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
1 Comment - 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.
No 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
No 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
No 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.
3 Comments - Edit - Delete
Blog software updated
While we aren't looking, sc0ttman (the author of SJPPLOG, the blog software used in this site) has been working quietly under the radar to update his excellent application.Scott has recently released version 1.3 of SJPPLOG with loads of enhancements, and I have finally upgraded this blog with his latest concoction.
See what has changed here: http://murga-linux.com/puppy/viewtopic.php?p=689184#689184
Thank you Scott !
No 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).
No comments - Edit - Delete