Operating systems - 10

Earlier I wrote about getting a Linux-based NAS-box to host Apple Time Machine backups.

I was reviewing my settings on the Mac and realized the text in the Time Machine:

Well... I have lots of disk space there. Not all of it is can be taken by my Mac's backups, so ... Something needed to be done.

I mounted the AFP-share and confirmed the max size of my sparsebundle:

hdiutil imageinfo Mac\ mini.sparsebundle/

It said (unsurprisingly):

Size Information:
 Total Bytes: 8855484092416

That is 8+ TiB!! Oh my! There is no way that I can afford to have that much of Apple backups. Luckily there is a way to reduce the size:

hdiutil resize -size 500g -shrinkonly Mac\ mini.sparsebundle/

Now checking the size will yield something reasonable (500 GiB):

Size Information:
 Total Bytes: 537214885888

That is something, that I can easily accept.

The information came from:

• http://untoro.wordpress.com/2011/06/07/how-to-limit-space-used-by-time-machine/
• http://nikhilhaas.com/blog/limit-size-of-time-machine-backup-on-wd-my-book-live/

Also I did this to limit the size. I have no idea if it actually does anything.

defaults write /Library/Preferences/com.apple.TimeMachine MaxSize 405600

Perhaps somebody can comment this.

Earlier I wrote about Hyper-V crashing with BSOD. The entire project was doomed from the beginning. After I managed get the Windows not to crash, all I managed to do is get the Linux installer to hang whenever it attempted to anything major on the hard drive. I configured Hyper-V to provide the hard drive from a .vhdx-file, so I initially suspected that old .vhd-file might help, but no, nothing helped. Any minor operations succeeded, but any sort of normal usage made the Linux to hang.

Symptoms include:

• Console message: "INFO: task jbd2/sda blocked for more than 120 seconds" and instruction to deactivate the warning with:
  echo 0 > /proc/sys/kernel/hung_task_timeout_secs
  Example:
  • http://helpinlinux.com/tag/echo-0-proc-sys-kernel-hung_task_timeout_secs/
• Repeated "Sense Key" -messages in dmesg, example:
  • http://forums.gentoo.org/viewtopic-t-734696-view-next.html?sid=64f39476a9b96703e2a2c998023729b9
• No change in /sys/block/sda/stat:
  • Kernel documentation about block-device stat says that columns 3 and 6 contain the number of sectors read and written.
  • In my hung box, the values don't increase.

I was puzzled about this for a very long time. It took me several hours to bump into Linux-SCSI mailing list's discussion about the issue. There Mr. Olaf Hering describes an issue "storvsc loops with No Sense messages".

Luckily Mr. Hering realized what's going on and made a patch to fix the problem. Unfortunately the fix is not yet pushed into mainstream Linux kernel.

Since I was about to install ArchLinux, I took the trouble of compiling the necessary kernel module of hv_storvsc.ko into following kernel versions:

• 3.8.4, used in installation ISO-image:
  • SHA-1 sum: 74d2a5de73a4c7d963b649eb34b171eba86a268c
• 3.8.6, the version that got installed when I got my install done:
  • SHA-1 sum: 57a4216fc6749085820703d47cd87dcce47b1739
• 3.8.7, the version that it upgraded into when I did a system update:
  • SHA-1 sum: 3f8757ab69c97a6389c7c83a8ef57f16e9caa85d

All of the packages are available for you to download at http://opensource.hqcodeshop.com/ArchLinux/2013.04.01/. Your only trick is to get them replaced into initial RAM-disk -image. I just replaced the original file at /usr/lib/modules and re-ran the mkinitrd-command.

There was an update to my Fedora 17 Linux and among others, I got a new kernel. I didn't notice it at the time, but the reboot ate one of my Ethernet interfaces. There are two NICs on the motherboard, but on top of those, I have an Intel multi-port NIC. So in the end, there are more than your usual dose of ports.

Traffic to one particular LAN didn't function and I started to investigate:

# ifconfig -a
...
rename5: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 90:e2:ba:1d:33:f1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfe7e0000-fe800000

Well... I don't remember which one of my Ethernet-ports was rename5 after installation. Typically they are something like eth0, eth1 and so forth. Modern Linuxes tend to add more complexity with names like p2p2 or so, but I've never seen rename5-type naming.

From that I concluded that udev goofed up something. Fedora 17 does not create the /etc/udev/rules.d/70-persistent-net.rules-file which would solve my problem. Lot of Googling later, I found this page, it contains very useful Perl-script to dig enough system information and report it in udev-compatible format, in my case it yields:

# perl /root/bin/write_udev
...
# Added by 'write_udev' for detected device 'rename5'.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:e2:ba:1d:33:f1", NAME="rename5"

I created the persistent rule -file and added above into it. I just edited the NAME-part and renamed the interface properly.

Getting the rules to take effect was bit tricky. None of these worked:

udevadm trigger
udevadm control --reload-rules
udevadm trigger --attr-match=address='90:e2:ba:1d:33:f1'
udevadm trigger --sysname rename5

The trick was to get the full path with udevadm trigger --verbose --sysname rename5 -command and use the test-command with the full path:

udevadm test --action=add /sys/devices/pci0000:00/0000:00:06.0/0000:02:00.1/net/rename5

Then I got my new rule to take effect immediately and my interface up and working.

Since most modern Intel CPUs have VT-x in them and Windows 8 Pro has Hyper-V in it, I had to make use of the combo on my old laptop. It has a i5 mobile CPU which makes it on the less powerful end of CPUs. But the simple existence of a possibility of running a Linux on top of a Windows laptop makes me want to try it.

I added the Hyper-V feature into my Windows. I started the Hyper-V Management Console, added a virtual network switch and created a new virtual machine. It booted into Linux installer and the entire Windows crashed with a blue-screen-of-death. WTF?!

After a number of attempts with tweaking the Hyper-V settings, no avail. Every attempt to actually do anything reasonable in the guest system yielded a BSOD. Couple more futile attempts on command-line indicated that it had to have something to do with networking.

Next day I managed to Google into one discussion thread on Microsoft's social forums. There another unfortunate user is experiencing the same symptoms than me. Unlike his Windows 7, on my Windows 8 BSOD there isn't much of a stack trace or any usable information. But I had to try something, so I took an Ethernet-cable and plugged it into my laptop and reconfigured the Hyper-V virtual switch not to use the Intel Centrino 6200 WLAN, but a 1 Gbit/s Realtek port. That did the trick! Apparently some network drivers are not Hyper-V compatible. I don't know how to tell the difference between functioning or not functioning driver, but it is there.

There seems to be some sort of issue with hard drive, but that's an another story ...

Update 30th Dec 2013:
Anything I say below is subject to debate. This issue is not clear, see the new article about Mac Mini HDMI Dolby Digital audio output.

My mini is mainly for entertainment purposes and I chose to use it at living room. That should be an easy setup, right? Just plug the HDMi-output of the mini into my Yamaha amp which is connected to my Sony TV and everything will work out just fine. No.

Video-signal passes through the amp and TV displays it as supposed in correct resolution and frame rate. No glitches there. But the audio-signal has issues, there were only disappointing two channels. I was expecting to see 5.1 channels as my Yamaha amp has been set up already.

First I confirmed that my Mac Mini supported multichannel output (2 channels as stereo is not multi). There is no adapter in my setup (About Mini DisplayPort to HDMI adapters @ Apple support), so initially I had to assume that HDMi-port supports multichannel audio since my model is newer than mid 2010 and newer than early 2009 with adapter. To my understanding 2009 is the point where multichannel audio was possible without 3rd party add-ons. Anyway, I'm way above that line and should have the support.

Apple support forums have vast number of discussion threads about getting 5.1 sound. It is apparent, that for some reason, this is a problematic issue. I'm saying that the reason is: it does not work out-of-the-box as most Apple fans are used to doing everything in the Apple-land.

After numerous failing attempts I finally managed to get my setup working. At one point I realized that my mini is displaying audio status based on my TV, which obviously can produce only stereo sound. There is the amp in the HDMi-chain, and mini should detect audio by that. When I enable multichannel output from OS X:

... my amp does not reflect the change. It still displays the input signal as stereo. This is not typical behaviour. My amp correctly detects the type of the audio signal on all of my other devices. The fact that I missed was, that I can force the amp to do 7-channel signal:

... then 5.1 sound works perfectly.

Testing that everything works ok is very simple: In the MIDI-sound app there is the test-button. When each channel produces sound correctly, I downloaded a couple of movie trailes from http://trailers.apple.com/ and verified that all was as it was supposed to be.

Hope this helps somebody struggling with multi-channel issues.

The short version is: it does not work.

Having a SSD is feasible in the long run only if there is possibility of operating system informing the drive that an entire drive block (typically 16 KiB) can be erased. openSUSE wiki has following quote in it: "There are three terms often used to interchangeably describe this same basic functionality: Discard, UNMAP, and TRIM." This discard is possible only when there are no operating system sectors (typically 512 bytes) in the drive block.

Here is what I tried to do: I installed two Intel® Solid-State Drive 520 Series drives into my server and tried to see if RedHat-based CentOS 6.4 has enough backported bits & pieces to support RAID-1 /w TRIM.

The drives are fine and kernel TRIM-support is there:

hdparm -I /dev/sda | fgrep -i trim
           *    Data Set Management TRIM supported
           *    Deterministic read after TRIM

My initial attempt had GPT-partition table with a single RAID-partition on it. The command I used is:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1

I created EXT-4 on top of md0:

mkfs.ext4 /dev/md0

and mounted it:

mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime

The discard-support is in the kernel ok:

mount | fgrep md0
/dev/md0 on /mnt/tmp type ext4 (rw,noatime,nodiratime,discard)

The next thing I tried to do is confirm if TRIM does work either automatically or as a batch job. I followed instructions from this blog entry and tried to run hdparm --fibmap on a newly created file. It failed with a segfault. Apparently that is a known issue, so I ended up packaging the latest version myself. My own RPM-package is available at http://opensource.hqcodeshop.com/CentOS/6%20x86_64/hdparm-9.43-1.el6.x86_64.rpm.

With latest hdparm 9.43 I could verify that FIEMAP (file extent map)  ioctl() does not return correct results on a soft-RAID-1 device. The LBA-sector given by hdparm does not seem to contain the file's data.

My next attempt was to tear down the existing md0 and re-build it using entire drive as RAID-device.

mdadm --stop /dev/md0
mdadm --zero-superblock /dev/sda1
mdadm --zero-superblock /dev/sdb1
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdb
mkfs.ext4 /dev/md0
mount /dev/md0 /mnt/tmp/ -o discard,noatime,nodiratime

I ran the same test, but this time hdparm --fibmap informed it failed to determine the drive geometry correctly. A short peek into the source code revealed that current version of hdparm works only with partitions. It tries to load the RAID-partition start LBA even if it is not located on a partition. I made a quick fix for that, it turned out that /sys/block/md0/md/rd0/block has DEVTYPE=disk or DEVTYPE=partition to indicate the base drive type.

Nevertheless, it did not help. fibmap does not return the correct LBA-sector. I loaded a Bash-script to do the manual TRIMming of a SSD-RAID-1, but it only confirmed what I already knew. The LBA-mapping does not work enough to see if discard works or not.

Currently I don't have anything on my RAID-1, I'll have to see if it is possible to get the discard working somehow. A newer Linux might do the trick.

Couple of weeks ago openSUSE-project released their latest desktop-Linux. That is the distro The Man himself, Linus Torvalds had a dispute about security policy of needing a root access to add a new wireless network. He actually said that openSUSE-people are morons. A year ago, they were very defensive and insisted that Mr. Man had it wrong. In reality: no other operating system requires demi-god permissions to do such a trivial task. In 12.3 the morons finally got it, connecting to a new wireless LAN does not require any special permissions.

My hardware for running a desktop-Linux is a very old Apple MacBook. The Mac OS X system info says, that this is a 1,1 hardware, making it pretty much one of the first ever Intel Macs there exists. It has two gigs of RAM and enough hard disk to run pretty much any modern disto. Being a Mac, it also has enough Intel chips in it to fulfill any requirements that modern distros have for 2D or 3D graphics, sound or display. It definitely lacks the I/O or CPU power that any not-6-years-old laptop might have, but it is very suitable for running a desktop-Linux. Mr. Torvalds prefers Apple Airs, but I didn't want to spend that much money on an used computer.

openSUSE install just keeps on improving. I always back up the old computer and do a fresh install, I sure haven't met a working operating system upgrade ever. During installation, all the settings are there if you need the, but the defaults are very good making the entire process flow smoothly. This time there was a glitch when the Atheros WLAN-chip was not auto-detected during install. I had to manually go configure network devices and add a wireless device. At that point the ath5k driver was detected and I got the box connected to The Net for the rest of the install. No other special things there.

After install the first thing I got was the pommed-package. It makes the Apple-keys work in Linux and is definitely needed. My keyboard layout is Finnish, so I also had to compile keyfuzz to get rid of those useless Apple-keys which are called Meta-keys in Linux. I need my alts, and do the following mappings:

 # Map Alt to Meta
458978 125
# Map Meta to Alt
458979 56
# Map Right Meta to Right Alt
458983 100

The final thing to do is to get the iSight-camera working. All it requires is the Apple-copyrighted firmware and it is ready to go. What I did, was to restore my previous file from a backup, but if you need to get one for yourself, there is ift-package or iSight Firmware Tools. With that you can extract the needed bits from Mac OS X device driver and place the resulting file into your Linux. There already is a Linux kernel-module isight_firmware waiting for the file to appear. As a result a brand new Video4Linux-device should appear and you can test it with MPlayer (that breaks couple of dozen copyrights and you need to get from The Net):

mplayer tv:// -tv driver=v4l2:width=320:height=240:device=/dev/video0 -fps 30

The 12.3 runs clearly much faster than 12.2. I have all the KDE4-desktop effects enabled and 12.2 really couldn't manage the 3D-graphics. 12.3 seems to be able to get more juice out of the Intel's 945 GPU. With all the modern software and latest Linux kernel the open-source -guys are finally getting there (with support from Novell, of course). This is actually a very usable desktop for a geek like me.

openSUSE 12.3 get's my seal-of-approval with a bonus thumbs up.

This is a really weird one. On 64-bit Windows, a regular USB bar code scanner is not detected as a HID-keyboard. Actually it falls into smthing really weird -category in the USB-devices. And needless to say, but the scanner effectively does not work. Windows simply states that "driver not found" and adds that "device may not function properly". I tried upgrading the driver from Device Manager, but no dice there.

Couple of users are complaining the same thing, but one actually has a solution. The idea is to first connect a real keyboard into USB-port and after that the barcode scanner. WTF?! It actually works! Windows gets fooled enough by the actual keyboard, that barcode scanner works even if the real keyboard is unplugged. It's just that an actual keyboard needs to be present during the driver detection.

I had couple of Zebex scanners and tried to make them work with my Windows 7, but all I got was frustration and no tangible results (beside the keyboard trick). I had a the-cheapest-there-is -model and a proper one, but there was no real difference in how Windows saw them. Based on the reports available in the Net, this is not a single manufacturer issue, its more like a Windows HID-keyboard issue. Then I was doing something else for a while, enough for the laptop power saver to kick in. When I got back to the computer and slapped it up from the sleep, then miraculously Windows detected the already plugged in barcode scanner as a HID-keyboard!! WTF?! #2

Ever since, both scanners have been functioning ok. Also, I'm pretty sure that now my laptop has been "tainted" and I cannot continue my tests with it anymore. I'd probably should re-install entire operating system just to confirm the results. But I'd rather not.

If anybody can explain what happened there, please drop a comment.

That happened to me with March 2013 updates. The machine was stuck with "Operations are in progress" -message for 12 hours. At that point I deduced that it is unlikely for the machine to actually be doing anything.

The real question is: What to do?

1. Force the thing into reboot cycle?
2. Wait a while longer?

I chose 1. and was ready for the smelly thing to hit the fan. Nothing happened. Windows finalized the updates during boot, which is pretty much normal in the circumstances. After that I logged in and everything worked fine.

I bumped into couple of issues earlier. Article about missing Integration Services and Networking Status: degraded.

RedHat managed to package the Integration Service drivers into RHEL 6.4 which essentially is the base of CentOS 6.4. So, from now on the much required drivers are bundled in the installation source.

There are no major changes in the drivers, though. Network status is still degraded and a hint of upgrading the drivers is there. It seems to be a mystery to everybody how to do the upgrade.

The list of integration services is unchanged:

• Operating system shutdown
• Time synchronization
• Data Exchange
• Heartbeat
• Backup (volume snapshot)

This article in Microsoft's social network describes the changes. Looks like Dynamic Memory (ballooning) is the only new feature. That wasn't even in the RHEL 6.4 beta, but they pushed it into final release.

Earlier I wrote about running CentOS 6.3 with Windows 8 Hyper-V.

One day I realized that the status of my network says: Degraded (Integration Services upgrade required). Well... I dunno what that means. Everything seems to work, but if there are any issues I'm not noticing them.

According this conversation at Microsoft's social network, somebody else is having this issue too. They are not noticing anything wrong either. Except the fact that status is degraded. I did try fiddling around with virtual network settings, but no avail.

I guess it is fully working after all.

Windows 8 Pro comes with Microsoft's Hyper-V virtualization platform. If you have new and beefy PC, it is likely that the CPU supports Hyper-V (Celeron owners, don't bother). Everybody needs couple of Linuxes running inside your Windows, right? At least I do.

Getting the newly installed CentOS 6.3 to support networking is a bitch. After the CentOS installation finishes you're left on a virtual console screen with little possibilities of getting to outside world from your sandbox. The Wikipedia article about the subject reveals, that Microsoft had to submit their code into Linux kernel to comply with GPL license requirements. But still, CentOS 6.3 has kernel 2.6.32, but the much needed Hyper-V kernel modules are not available. Darn!

It took me an hour of Googling around, before I ended on Microsoft web page titled Linux Integration Services Version 3.4 for Hyper-V. I got the .ISO image, mounted it into my virtual Linux and run the install script. Yesh! The script managed to get my NIC to appear as eth0. After that it was just a breeze to get it configured with DHCP-client. It's a pity that nobody clearly documents this part of the installation process. People could save hours of work if somebody said to go get them.

Apparently new Linux distros come with Hyper-V drivers built in. In my case I need to run the same OS than my production server does.