After having received my Raspberry Pi in November, I am finally using it. I have connected it to my television using raspbmc.Using XBMC Remote I can control it without the need for a mouse, keyboard or lirc based remote control and so far it works pretty good. Following are a few pictures with the new case I bought a few days ago:
With the recent approved review of the package crtools in Fedora I have made a feature proposal for checkpoint/restore.
To test checkpoint/restore on Fedora you need to run the current development version of Fedora and install crtools using yum (yum install crtools). Until it is decided if it actually will be a Fedora 19 feature and the necessary changes in the Fedora kernel packages have been implemented it is necessary to install a kernel which is not in the repository. I have built a kernel in Fedora’s buildsystem which enables the following config options: CHECKPOINT_RESTORE, NAMESPACES, EXPERT.
A kernel with these changes enabled is available from koji as a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4899525
After installing this kernel I am able to migrate a process from one Fedora system to another. For my test case I am migrating a UDP ping pong (udpp.c) program from one system to another while communicating with a third system.
udpp is running in server mode on 129.143.116.10 and on 134.108.34.90 udpp is started in client mode. After a short time I am migrating, with the help of crtools, the udpp client to 85.214.67.247. The following is part of the output on the udpp server:
-->
Received ping packet from 134.108.34.90:38374
Data: This is ping packet 6
Sending pong packet 6
--
-->
Received ping packet from 134.108.34.90:38374
Data: This is ping packet 7
Sending pong packet 7
--
-->
Received ping packet from 85.214.67.247:38374
Data: This is ping packet 8
Sending pong packet 8
--
-->
Received ping packet from 85.214.67.247:38374
Data: This is ping packet 9
Sending pong packet 9
--
So with only little changes to the kernel configuration it is possible to migrate a process by checkpointing and restoring a process with the help of crtools.
We have integrated new nodes into our cluster. All of the new nodes have a local SSD for fast temporary scratch data. In order to find which are the best options and IO scheduler I have written a script which tries a lot of combinations (80 to be precise) of file system options and IO schedulers. As the nodes have 64 GB of RAM the first run of the script took 40 hours as I tried to write always twice the size of the RAM for my benchmarks to avoid any caching effects. In order to reduce the amount of available memory I wrote a program called memhog which malloc()s the memory and then also mlock()s it. The usage is really simple
$ ./memhog Usage: memhog <size in GB>
I am now locking 56GB with memhog and I reduced the benchmark file size to 30GB.
So, if you have too much memory and want to waste it… Just use memhog.c.
After having successfully updated libcdio in rawhide to 0.90 and also introduced the split off libcdio-paranoia in Fedora’s development branch, I rebuilt most of on libcdio depending packages. Two packages were no longer building but their maintainers quickly fixed it. The only broken dependent package was kover. As I am still upstream of kover I had to change the code to use the new CD-Text API of libcdio 0.90.
With these changes I have released kover version 6 which is available at http://lisas.de/kover/kover-6.tar.bz2.
I have updated the scripts which are using the mirrored project status information in our database to display even more information about what is going on on our mirror server. In addition to the overall traffic of the last 14 days, 12 months and all the years since we started to collect this data, the overall traffic is now broken down to transferred HTTP, FTP, RSYNC and other data (blue=other, red=http, green=rsync, yellow=ftp). The most traffic is generated by HTTP, followed by RSYNC and last (but not surprising) is FTP.
In addition to breakdown by traffic type I added an overview of the mirror size (in bytes and number files) at the bottom of the status page of each mirrored project. Looking at the status page of our apache mirror it is now possible to see the growth of the mirror since 2005. It started with 7GB in 2005 and has now reached almost 50GB at the end of 2012.
Adding the new functionality to the PHP scripts I had to change code I have written many years ago and unfortunately I must confess that this is embarrassingly bad code and it already hurts looking at it. Adding new functionality to it was even worse, but despite my urge to rewrite it I just added the new functionality which makes the code now even more unreadable.
A few days ago I started to upgrade my PowerStation from Fedora 15 (running my own rebuild) to Fedora 18 Beta.
The update from the running Fedora 15 to Fedora 16 was the really hard part. It seems that the userspace moved from 32bit to 64bit and that was something that yum, understandably, could not handle. So after the first run of all packages updated to Fedora 16 (which required a lot of rpm -e --justdb --nodeps --noscripts) and a reboot the system was broken. systemd tried to start udev but that failed with:
[ 38.164191] systemd[1]: udev.service holdoff time over, scheduling restart.
[ 38.208255] systemd[1]: Job pending for unit, delaying automatic restart.
and systemd kept printing those lines forever. Luckily I still had the original Yellow Dog Linux installation on a second drive and could boot that. Unfortunately I could not chroot into the Fedora 16 installation because the Yellow Dog Linux kernel was too old, but I was able to mount it and disabled every occurrence of udev in systemd. Rebooting with systemd.unit=emergency.target on the kernel command-line I was able to get the network running and reinstalled with yum the udev and systemd ppc64 packages. After that (and some more fiddling around) it rebooted into Fedora 16.
I then just followed the recommendations on the Fedora wiki to upgrade using yum from F16->F17 and F17->F18. The only difference was that I installed the gpg key, which is used to sign the packages, from https://fedoraproject.org/keys using the keys for the secondary architectures.
Now I have a PowerStation with the latest 64bit Fedora 18 Beta packages up and running.
Finally, only 4 months after I ordered my Raspberry Pi it actually arrived today:
For our mirror server we now have a third RAID which is also used for the mirror data. The previous external RAIDs (12x1TB as RAID5 + hot spare) were reaching their limits and so additional 11x1TB as RAID6 in the remaining internal slots are a great help to reduce the load and usage of the existing disks. There are now roughly 30TB used for mirror data.
To create the filesystem on the new internal RAID I have used http://busybox.net/~aldot/mkfs_stride.html. With 11 disks, a RAID level of 6, RAID chunk size of 512 KiB and number of filesystem blocks of 4KiB I get the following command to create my ext4 filesystem:
mkfs.ext4 -b 4096 -E stride=128,stripe-width=1152
I am now moving all the data from one of the external RAIDs to the new internal RAID because the older external RAID still uses ext3 and I would like to recreate the filesystem using the same parameter calculation as above. Once the filesystem has been re-created I will distribute our data evenly across the three RAIDs (and maybe also mirror a new project).
Update: After moving the data from one of the external RAIDs to the internal RAID the filesystem has been re-created with:
mkfs.ext4 -b 4096 -E stride=128,stripe-width=1280
After updating our mirror server to Fedora 17 I saw the following lines in dmesg:
[ 62.816884] qla2xxx [0000:21:00.0]-0063:3: Failed to load firmware image (ql2400_fw.bin). [ 62.816889] qla2xxx [0000:21:00.0]-0090:3: Fimware image unavailable. [ 62.816891] qla2xxx [0000:21:00.0]-0091:3: Firmware images can be retrieved from: ftp://ftp.qlogic.com/outgoing/linux/firmware/. [ 63.526024] qla2xxx [0000:21:00.0]-00c2:3: Unable to initialize EFT (258).
and I opened following bug report: qla2xxx firmware not loaded
I thought that it probably is not optimal but as it was working like before I thought that I do not need to act immediately.
Yesterday I got a bug report that one file downloaded from our server was corrupt. This is nothing unusual and happens a few times per year. After checking that the checksums were correct I thought that it probably happened during the download and the user just needs to download the file again and everything is okay.
Unfortunately I got another bug report that evening that files had wrong checksums and they were changing with every try to download the file again: ports/168956: lang/gcc46 version 4.6.4.20120608 checksum mismatch
I was not able to reproduce this but as both files were on the same RAID connected with the same Fibre Channel controller I thought maybe the missing firmware is the problem. I blacklisted the modules in dracut so that they are not included in the ramdisk hoping that the firmware will be loaded if the modules are loaded from the disk instead of being loaded from the ramdisk. And it worked. The firmware is now loaded (at least the driver is no longer complaining about it) and until now I have no further error reports. Let’s see if this was the correct fix.
Update 1: So it seemed pretty unlikely that the firmware of a Fibre Channel controller is responsible for the data corruption. I am now trying something new. I downgraded the kernel from 3.4.0 to 3.3.4.
Yesterday I upgraded our mirror server to Fedora 17. After having neglected the system for some time it still ran Fedora 14. Fedora 14 was extremely stable and the uptime was almost 1 year. Such large uptimes are usually a sign of a lazy admin because with the frequency of kernel updates the system should have been rebooted much more often and Fedora 14 is now almost half a year EOL. The update to Fedora 17 is the first update I did not want make using yum because of the changes necessary for UsrMove. I burned the DVD (actually Martin did it) and even looked at the installation guide. In the installation guide it says:
Before upgrading to Fedora 17 you should first bring your current version up to date. However, it is not then necessary to upgrade to intermediate versions. For example, you can upgrade from Fedora 14 to Fedora 17 directly.
Great, I was already afraid I had to do two upgrades. After dumping the postgresql Database (I even thought about this) I rebooted using the DVD and it started to search for previous installations. It found a Fedora 14 installation and said that it cannot upgrade Fedora 14 to Fedora 17. Just as I expected it. Now Silvio was so nice to burn a Fedora 16 DVD and I started the Fedora 16 upgraded but this time the installer did not even offer the possibility to upgrade and the only possibility was a new installation. After using the shell the installer offers on another VT I found out that we have to many partitions. Not sure what the installer exactly does but it was not able to handle a separate partition for /var and /var/lib which we have been using. It was not able to find the RPM database and aborted the upgrade process. So I increased the size of the LV containing / and copied /var,/var/lib and /usr (because of UsrMove) to the / partition and finally the upgrade could start. After the upgrade finished I inserted the Fedora 17 DVD this upgraded finished without any problems.
After rebooting in the freshly upgraded Fedora 17 I saw that the upgraded to systemd did not went as smooth as is should have been. All service which were converted to systemd unit files were stopped and disabled. Only the jabber server was running (which is my package and has not been converted to systemd (but it will be for Fedora 18)). So I checked all the configuration files and started and enabled one service after another (has been a good systemd training).
After 6 hours most services were running again and the mirror server was happily serving files.
Today I also upgraded my notebook from Fedora 16 to Fedora 17. Using the Fedora 17 DVD from above it upgraded the system without any obvious problems. After rebooting into Fedora 17 I inserted my notebook back into the docking station (two external monitors connected via DVI) and was shocked that the monitors were no longer detected. The gnome-shell process was using 150% of the CPU and the CPU temperature was around 98°C (usually around 55°C). So at first I panicked and wanted Fedora 16 back but then I found at that all I needed was an updated xorg-x11-drv-intel. After a yum update --enablerepo=updates-testing xorg-x11-drv-intel-2.19.0-5.fc17 everything was back as good as Fedora 16 (and better of course).
End of 2008 I received following email:
Hello
My name is James and i will like to know whether you do sell Mirror .If you do sell them,reply me back with the brands and the prices of the ones that you do have so that i can let you know the brand and the quantity am interest in purchasing.Thanks and await to hear back from you .
Warm Regards
James
I am not sure if this was really meant seriously or just a joke.
Today I finally managed to release a new version of terminatorX, which had been broken for quite a while as some changes in either gtk+ or X.org broke the mouse grabbing code. Anyway, just recently I bought a new mouse as the left button of its predecessor was worn out. I decided to go for a high precision device, so I ended up with a Razer laser mouse (Lachesis).
At first I was stunned that the manufacturer actually labels the device as a “weapon of mass destruction”, but hey I use with a piece of software called “terminatorX” – so who am I to judge. Once you get used to the high resolution, the mouse really is a very precise input device – and it does help operating terminatorX quite a bit. The guys from Phoronix gave the mouse (or an earlier version of it) a test and liked it, too, however they were disappointed that Razer does not provide official Linux support. While this still holds true today, I have to say that my experience with the device under Linux has been excellent so far: you plug it in, it works perfectly an you can switch the resolution with the two buttons on top.
Some might be disappointed that there is no fancy user interface allowing you to tune and configure the device – I appreciate the fact that I don’t have to configure anything.
I’ve found a nice plugin for WP:
After the Deadline.
It might help to improve the text quality. At least mine.
Long ago I’ve spent a day in Frankfurt. Since I’ve never been there I went for the first parking I saw. And I got the following ticket with an interesting date.
In the evening I got an amount displayed on the machine that slightly exceeds the credit level of my credit card. (Sorry for the bad quality, but taking pictures of LCDs in direct sunlight is a challenge)
After waiting for a long time and talking to the service people the amount was reduced.
During the last week I’ve replaced the disks of my software RAID with larger ones as the capacity was exceeded. While this is theoretically an easy task, I had to learn a few things along the way:
fdisk silently fails to parse integer values larger than 2147483647.md superblock is located at the end of the partition/disk that you add to the RAID.md device instead of the last partition, blocking the use of other partitions for other md devices, resize the last partition to leave some (wasted) space at the end to ensure that the end of the last RAID partition differs from the end of the drive.
A few weeks ago I upgraded the hard disk in my notebook from 160GB to 250GB. I copied the whole hard disk using dd from the old drive to the new drive. I still had to change the partition layout to use the new space. So I downloaded the gparted live CD, booted it and discovered that I was not able to move an extended partition using gparted. I have the following partitions:
/dev/sda1 7 HPFS/NTFS /dev/sda2 7 HPFS/NTFS /dev/sda3 * 83 Linux /dev/sda4 5 Extended /dev/sda5 83 Linux
My plan was to increase the Windows partitions as well as the Linux partitions. To increase the size of /dev/sda2 I had to move /dev/sda3 and /dev/sda4. I was not able, however, using gparted, to move /dev/sda4. So I decided that I had to make a backup of /dev/sda5, then delete it (and /dev/sda4), move /dev/sda3 and increase the size of /dev/sda2.
Therefore I booted a Fedora installation DVD in the rescue mode and made a backup of /dev/sda5:
dd if=/dev/sda5 bs=65536 | ssh adrian@backup-server "dd of=sda5.img bs=65536"
Then I booted the gparted live CD and deleted /dev/sda5 and /dev/sda4, moved /dev/sda3 and increased the size of /dev/sda2. After that I created a new extended partition (/dev/sda4) and created /dev/sda5 using the remaining space. After gparted finished I booted the Fedora installation DVD again in the rescue mode and restored the backup:
ssh adrian@backup-server "dd if=sda5.img bs=65536" | dd of=/dev/sda5 bs=65536
At the end of the operation I booted my system and was happy that it still worked. Now I still had to resize the encrypted partition. This was pretty easy:
cryptsetup resize luks-<uuid> pvresize /dev/mapper/luks-<uuid>
Before doing the lvresize I checked the available extends with vgdisplay and used that number in the following lvresize command:
lvresize -l +16449 /dev/mapper/vg_dcbz-lv_root resize2fs /dev/mapper/vg_dcbz-lv_root
And that was already it. It took some time (maybe 4 hours), but everything finished without any problems. To make sure everything finished without any problems I forced a fsck (touch /forcefsck; reboot).
Before:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_dcbz-lv_root
74G 69G 1.4G 99% /
After:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_dcbz-lv_root
137G 69G 62G 53% /
|
luges
The Linux User Group Esslingen meets once a month at the luges Stammtisch.
Contact luges:
Feeds
Last update:
May 21, 2013 01:42 PM
All times are UTC.
Powered by:
Subscribe
