Archive for the ‘Linux’ Category
-
Getting Cleartype to Work with WINE and Winetricks
If you’re anything like me, you’re probably frustrated that the usual hints and tricks to enable sub-pixel hinting, i.e. “cleartype” in Redmond terms, under WINE is usually futile.
The problem often is that the default Windows XP font is Tahoma, and this font isn’t included with WINE. So even if you have enabled cleartype, Tahoma will render using some fallback system font without subpixel hinting.
Solution? Just install tahoma. Example, installing uTorrent with winetricks:
env WINEPREFIX=~/.wine-utorrent winetricks utorrent fontfix fontsmooth-rgb tahoma
There ya go
-
Changing GRUB2 Boot Order the Right Way
UPDATE: I may be wrong here, as Peter Nau points out. I’m tempted to swear that I’m not and that last I tried a grub update left me with a vanilla /etc/default/grub sans my changes, so I’m leaving the post as-is, but you may want to just try editing /etc/default/grub before going this route. Thanks Peter!
Okay, so there’s quite a number of posts out there giving advise to edit /etc/default/grub and change GRUB_DEFAULT=0 to whatever index number in the GRUB menu your desired default OS is placed at in order to set the boot order to your desire.
The problem with this approach, is that you can’t be sure that your desired OS is always at the same index. The default behavior of most Linux distros, like Kubuntu and Ubuntu, when updating your system with a fresh kernel is to add it to the top of the list in the GRUB menu, pushing every other item down by two indices (one entry is added for booting regularly, one for booting in failsafe mode).
So, if you’ve updated /etc/default/grub to default boot the index of your other OS, be it Solaris, Windows, Mac OS X or something entirely else, you’re now fresh out of luck, as that index no longer matches what you want.
The answer is to change the order of which types of OSes are placed first, moving Linux farther down the list, so that kernel updates won’t mess with indices above it. The order of the types of things that go into the GRUB menu is determined by the order of the files in /etc/grub.d/. Try this and see:
you@yourhost:~$ ls -l /etc/grub.d/ total 52 -rwxr-xr-x 1 root root 6831 2010-10-06 14:22 00_header -rwxr-xr-x 1 root root 1481 2010-10-06 14:04 05_debian_theme -rwxr-xr-x 1 root root 4757 2010-10-06 14:22 10_linux -rwxr-xr-x 1 root root 5028 2010-10-06 14:22 20_linux_xen -rwxr-xr-x 1 root root 1588 2010-09-24 20:16 20_memtest86+ -rwxr-xr-x 1 root root 6933 2010-10-06 14:22 30_os-prober -rwxr-xr-x 1 root root 214 2010-10-06 14:22 40_custom -rwxr-xr-x 1 root root 95 2010-10-06 14:22 41_custom -rw-r--r-- 1 root root 483 2010-10-06 14:22 README
Notice how each item is numbered, first some header setup, then theme setup, then items on the menu: Linux kernels first, Xen hypervisor systems, the memtest entry, and finally the “probed” OSes, that is all other OSes that update-grub will recognize are available when it is run. We want these to come before the Linux kernels in the list. The solution is simple: rename 30_os-prober so that it appears before 10_linux, but after 05_debian_theme.
Not exactly difficult, let’s try this:
you@yourhost:~$ sudo mv /etc/grub.d/30_os-prober /etc/grub.d/07_os-prober you@yourhost:~$ sudo update-grub
That’s it. Reboot, and your other OS is at the top.
Now, there’s just one catch. Note how I said, “your other OS”, as in singular? Do you have more than one other OS and the first one found by update-grub isn’t the one you’d like to boot by default?
Then it’s time to edit /etc/default/grub and change the GRUB_DEFAULT value so that it matches the OS you want. Because you’ve already shifted the Linux items to the bottom of the GRUB list, your boot loader will still launch the desired OS after a kernel update. The only thing that can throw it off and require you to go back and set up GRUB once again, is if you install more OSes or in some cases of juggling disks around. But that hopefully happens far less frequently than updating your kernel does
-
Fixing Rubber Stamp and Clone Tools in Photoshop Under WINE
Annoying as hell. The default behavior in Linux when holding down Alt and clicking a window is to start a drag movement. This conflicts with certain tools in Photoshop when running under WINE.
Quick fix is to change the movement combo key that Linux acts on for moving windows from Alt to the Win, or Meta, key.
In KDE: System Settings > Window Behavior > Window Behavior > Window Actions > Modifier key dropdown.
-
Setting up Postfix to Use GMail’s SMTP Server for Sending Mail
Update @ 2011-05-17: So I’ve been doing this again, and wanted to add a simpler step-by-step guide to this post. Seems others got the same idea, I used this quick guide, which had me up and running in five minutes. Don’t forget to read my comment on that page, as a couple of steps are missing from the guide.
Ah!
Just found this great guide on setting up Postfix to use the GMail SMTP server for sending out mail from your system. Postfix is pretty useless unless your box is actually set up as one mother of a server with a proper hostname, DNS/MX records and whatnot. Trying to send anything anywhere will most likely just yield a bunch of “bounced” messages in /var/log/mail.log, because no sane server out there would accept emails from some computer presenting itself as “localhost”, “kickassbox”, “bigdaddy” or whatever you’ve dubbed your sweet machine. Which kinda sucks if you’d like to set up monitoring of your system’s health, e.g. fan speeds, hard drive and storage status via smartd/smartctl, mdadm, zfs stuffs or something like that.
Luckily, for those of use having a GMail account, and being able to read the guide I just linked to, in no time we’ll have a fully working Postfix setup. Just don’t forget to read the replies from other users at the bottom of the page. The guy saying he needed to remove brackets around smtp.gmail.com, I don’t know, I didn’t have to. But the one pointing out needed paths to sasl stuff in main.cf, listen to him. Also, don’t forget to match your hostname in main.cf with the hostname you put in your certificate file. You don’t have to change your hostname system-wide, just the Postfix configuration (mine’s still lnxsrv internally).
Thanks to Mark Sanborn!
-
Fixing Missing Network Management in Kubuntu
This thing was driving me crazy. I actually thought I had broken my laptop. Thing is, my laptop had been asleep, and going to bed, I thought I’d just check my mail and stuff before turning in, so I grabbed my lappie and took it with me under the covers.
Opening it and pressing space to wake it, I somehow managed to bang it pretty hard with my knee at the same time. The laptop didn’t wake up, but rather ended in some kind of limbo state between sleeping and waking up. I waited for abit to see if it was just the harddrive safe-locking due to the bump, but it never came back up, and I couldn’t go to a regular TTY either.
I ended up having to hard-reboot it, but when it entered KDE, there was no network anymore. Knetworkmanager just said, when hovered, “Network management disabled”, and clicking it, I just got a small context-like menu with “Unmanaged” written in it. Opening a konsole window, and doing ifconfig showed no eth0 device nor any wlan0 device.
This got me abit nervous, because I hadn’t done any updates or configuration either, so there was no reason to think that this was a configuration issue. I started worrying if the bump had either dislodged some wire or my cards from their socket(s) so that I no longer had physical access to the cards. Doing an lspci did however show both my wired and wireless cards present.
Puzzled, I tried modprobing pretty much any module that seemed to fit, but to no avail. I then tried booting up a live cd, and lo and behold, both cards where there and network connectivity was doing fine.
I then scoured Google, tried dumping the udev fixed “routes” for the cards which just resulted in them reappearing just as before, but still nothing in ifconfig, and still nothing in knetworkmanager. I eventually figured out what had happened, after reading a suggestion from someone that the network manager had been left in some garbled state preventing it from coming back up. The suggested fix was to
rm /var/lib/NetworkManager/NetworkManager.state
and reboot.
This didn’t help, but reading on, it seemed that the way the network manager handles the computer being suspended, is to enter exactly such a state where the network management daemon is suspended, and then eventually resumed and returned to active once the computer is resumed again. Seeing as how my laptop never resumed after being suspended, this pretty much fit the bill.
The trick is to send a wake command to the network manager daemon:
dbus-send --system --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.wake
It’s not very cool that not waking from sleep results in this bug, and I don’t understand the logic behind keeping this state over a reboot in the first place. Being suspended and never coming back up is hardly something that happens very rarely (think battery running out).
But good to know what the deal is, so that it can be fixed accordingly
-
Kubuntu Still not Playing Nice with Fakeraids at 10.10
I was shocked tonight to find that the Ubiquity installer in Ubuntu is still unable to properly install to fakeraid software RAID setups, such as my own Intel ICH10-based rig. Not that the alternate CDs do any better, they just completely fail to see the array.
I wanted to install Linux on my second desktop computer, and I’ve been pretty happy about Linux Mint, so at first I thought about dropping that one on it. Earlier this month I re-installed my server/HTPC box, and opted for Mint, as here, too, Ubuntu wouldn’t install properly. Which I find rather weird, considering the fact that Mint is pretty much Ubuntu with sugar on top.
But then I started thinking that it had been awhile since the Lynx appeared, and that it was about time for a new release, the Maverick one, scheduled for the 10th this month. So I found the beta 2 of Kubuntu Lynx and popped it in. Wouldn’t boot to the desktop, just restarted the machine. Found a daily build instead and tried with that. Same thing. Frustrated, I went about other business.
This night I thought I might try installing again, using 10.04 as base and doing a distribution upgrade to 10.10 beta afterwards. The 10.04 live CD manages to boot properly, and it does detect my ICH10R array, though I’ve not had any success in the past actually getting it to install to it properly. I thought maybe if I’d succeed in doing the upgrade inside the live environment, and then install afterwards, I might get 10.10 installed from the get-go. Maybe this is just a wholly retarded idea in the first place, but in any case, the upgrade process would hang shortly after having downloaded half a gig of packages, and so it was a failed attempt.
I decided instead to give 10.04 yet another try at installing on my fakeraid. The first issue you’re facing here, is that Ubiquity crashes when it tries to format your partitions. It’s quite sad, and amazing to see that even after having updated the packages first (which would include Ubiquity), six months since the release this issue has not been fixed. Of course, if you know your way around the console, you can quickly format your partitions yourself, but you can’t tell Ubiquity not to mkswap your swap partition, so it’ll still crash unless you choose to have no swap partition.
After doing that, you do get to see your drives being filled with Linux goodness, but sadly, the installer will still crash in the end, being unable to install grub on /dev/sda. Three things wrong here: First, it shouldn’t go on /dev/sda, it should go on the raid array, /dev/mapper/isw_something. Second, the default in Ubiquity is /dev/sda, even though there is not /dev/sda targeted, and this default is hidden under the “Advanced options” button just before starting the installation. Third, I had pressed this button and explicitly selected my raid device instead, but apparently that had been ignored. Sigh.
So, faced with failure once more, I then went looking for 10.10 progress again, and lo and behold, the release candidate was ready for download. Burned it, and booted it. The all too familiar reboot. Damn! I thought maybe if I could just get it to boot in some kind of safemode, I’d be set for an install which might prove more stable than this. I F6′ed at the boot splash and disabled acpi, apic, and lapic, and was finally able to boot the darn thing. As it turns out, it seems there’s a regression in the 2.6.35-rc3 kernel concerning ACPI, so hopefully this will be fixed soon.
One thing that was immediately apparent in the 10.10 live installer, is that it has another issue that 10.04 had also. The network isn’t brought up automatically. I have to sudo dhclient eth0 it up myself. Anyway, again I have a Ubiquity that recognizes my array. This time, however, it didn’t crash when formatting. And the placement of the boot loader is no longer hidden under advanced settings, though it still wrongfully suggests installing it on sda rather than the array. And what do you know? It actually manages to install grub!
I actually got all cheerful for a moment there, until I actually rebooted the thing. Sure, I got a GRUB menu, but first of all: where’s the entry for Windows in that list? Gone. Second of all: once you boot, you’ll just get a blinking cursor for awhile until it barfs with an “ALERT! /dev/mapper/isw_something does not exist” greeting.
Thanks. So apparently it takes six months to get halfway there. To where we get a boot loader and a grub menu. Next up, in 11.04 must be that Ubiquity actually manages to update initramfs with the proper modules, so that we can actually boot the damn thing. For any of you wondering what to do next, you simply have open up a console when the installer finishes and before rebooting, and do the obligatory:
sudo chroot /target
sudo echo dm-raid4-5 >> /etc/initramfs-tools/modules
sudo echo dm-raid4-5 >> /etc/modules
sudo update-initramfs -uThat’s all there is to it. I cannot believe we’re at this state, 9 days before release. Scratch that, I actually can, because I felt the exact same way just before 10.04 was to be released. I mean, even the kernel is a release candidate, and it will panic on certain ACPI setups. Version 10.10 on the 10th. No way in hell that date is going to be changed, and then we have RTM and pressed copies of the installation CDs with these showstopping bugs.
I’m all for cutting-edge software, but seriously, I think the Mint guys are on to something good with their new Debian rolling upgrades project. These fixed releases haven’t been good for awhile, and even if KDE4 has been progressively stabilizing, there’s still way too much beta tester feeling going on here. All feature development should be halted until the major bugs have been ironed out. Just for the sake of it, consider apps like Amarok and Kontact which are pretty much too buggy to use. And in Kontact’s case, even dangerous to use. I mean, bugs that cause IMAP mail to be re-dated to [NOW] when managed, or contact books to be deleted when clicking Cancel in a properties sheet? Those are okay on nightly developer builds, but not in production software that is at the same time receiving feature updates.
Recent Posts
- Creating Missing Keyboard Shortcuts in Applications on Mac OS X
- Get Back /var/log/messages in (K)ubuntu 11.04
- Boosting Windows 7 File Move Performance by Up to 10,000%
- Leaked Screenshot of Windows Server 9 Login Screen, In-UI Annotations new Design Strategy
- Linux Users More Generous than their Paying Mac and Windows Counterparts?
