Run through the install as you'd normally would. Towards the end the installer will likely complain it can't figure out how to install a bootloader, which is fine. Just before ending the install/reboot, switch to the shell and copy the /boot/vmlinuz and /boot/initrd.img from the target system to the host in some fashion (e.g. chroot into /target and use scp from the installed system). This is required as the installer doesn't support 9p, but to boot the system an initramfs will be needed with the modules needed to mount the root fs, which is provided by the installed initramfs :). Once that's all moved around, the installer can be finished. Next, booting the installed system. For that adjust the libvirt config (e.g. using virsh edit and tuning the xml) to use the kernel and initramfs copied from the installer rather then the installer ones. Spool up the VM again and it should happily boot into a freshly installed Debian system. To finalize on the guest side /boot should be moved onto the shared 9pfs, the fstab entry for the new /boot should look something like:
virt-install --name armhf-vm --arch armv7l --memory 512 \ --disk /srv/armhf-vm.img,bus=virtio --filesystem /srv/armhf-vm-boot,virtio-boot,mode=mapped \ --boot=kernel=/tmp/vmlinuz,initrd=/tmp/initrd.gz,kernel_args="console=ttyAMA0,root=/dev/vda1"
With that setup, it's just a matter of shuffling the files in /boot around to the new filesystem and the guest is done (make sure vmlinuz/initrd.img stay symlinks). Kernel upgrades will work as normal and visible to the host. Now on the host side there is one extra hoop to jump through, as the guest uses the 9p mapped security model symlinks in the guest will be normal files on the host containing the symlink target. To resolve that one, we've used libvirt's qemu hook support to setup a proper symlink before the guest is started. Below is the script we ended up using as an example (/etc/libvirt/hooks/qemu):
virtio-boot /boot 9p trans=virtio,version=9p2000.L,x-systemd.automount 0 0
With that in place, we can simply point the libvirt definition to use /srv/$ vm -boot/virtio- vmlinuz,initrd.img as the kernel/initramfs for the machine and it'll automatically get the latest kernel/initramfs as installed by the guest when the VM is started. Just one final rough edge remains, when doing reboot from the VM libvirt leaves qemu to handle that rather than restarting qemu. This unfortunately means a reboot won't pick up a new kernel if any, for now we've solved this by configuring libvirt to stop the VM on reboot instead. As we typically only reboot VMs on kernel (security) upgrades, while a bit tedious, this avoid rebooting with an older kernel/initramfs than intended.
vm=$1 action=$2 bootdir=/srv/$ vm -boot if [ $ action != "prepare" ] ; then exit 0 fi if [ ! -d $ bootdir ] ; then exit 0 fi ln -sf $(basename $(cat $ bootdir /vmlinuz)) $ bootdir /virtio-vmlinuz ln -sf $(basename $(cat $ bootdir /initrd.img)) $ bootdir /virtio-initrd.img
Before the 2.6 series, there was a stable branch (2.4) where only relatively minor and safe changes were merged, and an unstable branch (2.5), where bigger changes and cleanups were allowed. Both of these branches had been maintained by the same set of people, led by Torvalds. This meant that users would always have a well-tested 2.4 version with the latest security and bug fixes to use, though they would have to wait for the features which went into the 2.5 branch. The downside of this was that the stable kernel ended up so far behind that it no longer supported recent hardware and lacked needed features. In the late 2.5 kernel series, some maintainers elected to try backporting of their changes to the stable kernel series, which resulted in bugs being introduced into the 2.4 kernel series. The 2.5 branch was then eventually declared stable and renamed to 2.6. But instead of opening an unstable 2.7 branch, the kernel developers decided to continue putting major changes into the 2.6 branch, which would then be released at a pace faster than 2.4.x but slower than 2.5.x. This had the desirable effect of making new features more quickly available and getting more testing of the new code, which was added in smaller batches and easier to test. Then, in the Ruby community. In 2007, Ruby 1.8.6 was the stable version of Ruby. Ruby 1.9.0 was released on 2007-12-26, without being declared stable, as a snapshot from Ruby s trunk branch, and most of the development s attention moved to 1.9.x. On 2009-01-31, Ruby 1.9.1 was the first release of the 1.9 branch to be declared stable. But at the same time, the disruptive changes introduced in Ruby 1.9 made users stay with Ruby 1.8, as many libraries (gems) remained incompatible with Ruby 1.9.x. Debian provided packages for both branches of Ruby in Squeeze (2011) but only changed the default to 1.9 in 2012 (in a stable release with Wheezy 2013). Finally, in the Python community. Similarly to what happened with Ruby 1.9, Python 3.0 was released in December 2008. Releases from the 3.x branch have been shipped in Debian Squeeze (3.1), Wheezy (3.2), Jessie (3.4). But the python command still points to 2.7 (I don t think that there are plans to make it point to 3.x, making python 3.x essentially a different language), and there are talks about really getting rid of Python 2.7 in Buster (Stretch+1, Jessie+2). In retrospect, and looking at what those projects have been doing in recent years, it is probably a better idea to break early, break often, and fix a constant stream of breakages, on a regular basis, even if that means temporarily exposing breakage to users, and spending more time seeking strategies to limit the damage caused by introducing breakage. What also changed since the time those branches were introduced is the increased popularity of automated testing and continuous integration, which makes it easier to measure breakage caused by disruptive changes. Distributions are in a good position to help here, by being able to provide early feedback to upstream projects about potentially disruptive changes. And distributions also have good motivations to help here, because it is usually not a great solution to ship two incompatible branches of the same project. (I wonder if there are other occurrences of the same pattern?) Update: There s a discussion about this post on HN
% time ./bin/eierskap-dotty 958033540 > dagbladet.dot real 0m2.841s user 0m0.184s sys 0m0.036s %The script accept several organisation numbers on the command line, allowing a cluster of companies to be graphed in the same image. The resulting dot file for the example above look like this. The edges are labeled with the ownership percentage, and the nodes uses the organisation number as their name and the name as the label:
digraph ownership rankdir = LR; "Aller Holding A/s" -> "910119877" [label="100%"] "910119877" -> "998689015" [label="100%"] "998689015" -> "958033540" [label="99%"] "974530600" -> "958033540" [label="1%"] "958033540" [label="AS DAGBLADET"] "998689015" [label="Berner Media Holding AS"] "974530600" [label="Dagbladets Stiftelse"] "910119877" [label="Aller Media AS"]To view the ownership graph, run "dotty dagbladet.dot" or convert it to a PNG using "dot -T png dagbladet.dot > dagbladet.png". The result can be seen below: Note that I suspect the "Aller Holding A/S" entry to be incorrect data in the official ownership register, as that name is not registered in the official company register for Norway. The ownership register is sensitive to typos and there seem to be no strict checking of the ownership links. Let me know if you improve the script or find better data sources. The code is licensed according to GPL 2 or newer. Update 2015-06-15: Since the initial post I've been told that "Aller Holding A/S" is a Danish company, which explain why it did not have a Norwegian organisation number. I've also been told that there is a web services API available from Br nn ysundsregistrene, for those willing to accept the terms or pay the price.
How often at night when the heavens are brightThere s something about a beautiful landscape out the window to remind a person of all the blessings in life. This has been a quite busy weekend actually, a busy month but despite the fact I have a relative that is sick in the midst of it all, I am so blessed in so many ways. I finish off the bread, adding some yeast, and I remember my great uncle thanking me so much for visiting him yesterday. He commented that a lot of younger people have no use for visiting an old geezer like me. I told him, I ve never been like that. I am so glad I could come and visit you today. The best gifts are those that give in both directions, and this surely is that. Then I clean up the kitchen. I wipe down the counters from all the bits of cabbage that went flying. I put away all the herbs and spices I used, and finally go to sit down and reflect. From the kitchen, the smells of borscht and bread start to seep out, sweeping up the rest of the house. It takes at least 4 hours for the borscht to cook, and several hours for the bread, so this will be an afternoon of waiting with delicious smells. Soon my family will be home from all their activities of the day, and I will be able to greet them with a warm house and the same smells I stepped into when I was a boy. I remember this other verse from Home On the Range:
With the light from the glittering stars
Have I stood here amazed and asked as I gazed
If their glory exceeds that of ours.
Where the air is so pure, the zephyrs so free,Today s breeze is an icy blast from the north maybe not balmy in the conventional sense. But it is the breeze of home, the breeze of belonging. Even today, as I gaze out at the frozen landscape, I realize how balmy it really is, for I know I wouldn t exchange my life on the range for anything.
The breezes so balmy and light,
That I would not exchange my home on the range
For all of the cities so bright.
orff.debian.org, which is an aging blade in Greece, to a VM on one of our ganeti clusters. In the process, I rediscovered a lot about our DNS infrastructure. In this post, I will describe the many sources of information and how they all come together.
debian.net. The rest is made up of
debiandomains in various other top level domains and reverse zones, which are utilized in IP address to hostname mappings.
static.debian.orgor specifies the servers responsible for accepting mail to
@debian.orgaddresses. It also is where all the
ftp.CC.debian.orgentries are kept and maintained together with the mirror team.
debian.orghosts, such as
master, is maintained in Debian's userdir LDAP, queryable using LDAP1.
mXRecordLDAP attribute, DNS
HINFOrecord, mainly because we can and we are old-school.
dnsZoneEntryattributes to their user2.
TLSArecords that enable clients to securely authenticate certificates used for mail and HTTPS, similar to how
SSHFPworks for authenticating ssh host keys.
bugsshould always work. These services are, thus, provided by more than one machine on the Internet. However, HTTP did not specify a requirement for clients to re-try a different server if one of those in a set is unavailable. This means for us that when a host goes down, it needs to be removed from the corresponding DNS entry. Ideally, the world wouldn't have to wait for one of us to notice and react before they can have their service in a working manner. Our solution for this is our auto-dns setup. We maintain a list of hosts that are providing a service. We monitor them closely. Whenever a server goes away or comes back we automatically rebuild the zone that contains the element. This setup also lets us reboot servers cleanly since one of the things we monitor is "is there a shutdown running", we can, simply by issuing a
shutdown -r 30 kernel-update, de-rotate the machine in question from DNS. Once the host is back it'll automatically get re-added to the round-robin zone entry. The auto-dns system produces two kinds of output:
$INCLUDEdirective. Services that work like this include
static(service definition for static).
rsyncto our GEO-IP enabled nameservers. This enables us to give users a list of
securitymirrors closer to them and thus hopefully faster for them.
write_zonefilescripts from our dns-helpers repository take over the job of building complete zonefiles and a bind configuration snippet. Bind then loads the zones and notifies its secondaries. For geozones, the zonefiles are already produced by auto-dns'
build-zonesand those are pulled from the geo nameservers via rsync over ssh, after an ssh trigger.
dnssec-signzoneway before shipping them. The secure delegation status (DS set in parent matches DNSKEY in child) is monitored by a set of nagios tests, from both [dsa-nagios] and dns-helpers. Of these,
manage-dnssec-keyshas a dual job: not only will it warn us if an expiring key is still in the DSset, it can also prevent it from getting expired by issuing timly updates of the keys metadata.
|Series:||Sarah Beauhall #2|
Process: android.process.acore Flags: 0x883e45 Package: com.android.providers.applications v18 (4.3.1-f963020e38) Package: com.android.providers.contacts v18 (4.3.1-f963020e38) Package: com.android.providers.userdictionary v18 (4.3.1-f963020e38) Build: samsung/apexqtmo/apexqtmo:4.1.2/JZO54K/T699UVBMC5:user/release-keys android.database.sqlite.SQLiteException: no such column: phonebook_label (code 1): , while compiling: UPDATE raw_contacts SET display_name_source=?,display_name=?,display_name_alt=?,phonetic_name=?,phonetic_name_style=?,sort_key=?,phonebook_label=?,phonebook_bucket=?,sort_key_alt=?,phonebook_label_alt=?,phonebook_bucket_alt=? WHERE _id=? ... at com.android.providers.contacts.ContactsDatabaseHelper.updateRawContactDisplayName(ContactsDatabaseHelper.java:5344) at com.android.providers.contacts.ContactsDatabaseHelper.upgradeToVersion504(ContactsDatabaseHelper.java:3580) at com.android.providers.contacts.ContactsDatabaseHelper.onUpgrade(ContactsDatabaseHelper.java:2261) ...Clock fails somewhat similarly though it apparently didn't try to upgrade:
Process: com.android.deskclock Flags: 0xc8be45 Package: com.android.deskclock v203 (2.0.3) Build: samsung/apexqtmo/apexqtmo:4.1.2/JZO54K/T699UVBMC5:user/release-keys android.database.sqlite.SQLiteException: no such column: incvol (code 1): , while compiling: SELECT _id, hour, minutes, daysofweek, alarmtime, enabled, vibrate, message, alert, incvol, profile FROM alarms WHERE (enabled=1) ... at com.android.deskclock.AlarmProvider.query(AlarmProvider.java:73) at android.content.ContentProvider.query(ContentProvider.java:744) at android.content.ContentProvider$Transport.query(ContentProvider.java:199) at android.content.ContentResolver.query(ContentResolver.java:414) at android.content.ContentResolver.query(ContentResolver.java:357) at com.android.deskclock.Alarms.getFilteredAlarmsCursor(Alarms.java:165) at com.android.deskclock.Alarms.calculateNextAlert(Alarms.java:344) at com.android.deskclock.Alarms.setNextAlert(Alarms.java:417) at com.android.deskclock.Alarms.saveSnoozeAlert(Alarms.java:510) at com.android.deskclock.AlarmInitReceiver$1.run(AlarmInitReceiver.java:49) ...The media player fails with a NullPointerException:
Process: com.andrew.apollo:main Flags: 0x98be65 Package: com.andrew.apollo v2 (1.1) Build: samsung/apexqtmo/apexqtmo:4.1.2/JZO54K/T699UVBMC5:user/release-keys java.lang.NullPointerException at com.andrew.apollo.MusicPlaybackService.stop(MusicPlaybackService.java:878) at com.andrew.apollo.MusicPlaybackService.openCurrentAndMaybeNext(MusicPlaybackService.java:1048) at com.andrew.apollo.MusicPlaybackService.openCurrentAndNext(MusicPlaybackService.java:1031) at com.andrew.apollo.MusicPlaybackService.access$1500(MusicPlaybackService.java:74) at com.andrew.apollo.MusicPlaybackService$MusicPlayerHandler.handleMessage(MusicPlaybackService.java:2337) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:137) at android.os.HandlerThread.run(HandlerThread.java:61)Fixing the problem Maybe I could have worked out how to upgrade the relevant databases myself, but I went for simpler solutions. The clock settings are easy to re-enter and most of the media player state is regenerated by scanning files on the SD card. So I just deleted those on the Relay:
rm -rf /data/data/com.android.deskclock rm -rf /data/data/com.android.providers.mediaThe contacts were what I really cared about, and there are actually specific menu items in Contacts to export and import those (using VCF format), side-stepping the database upgrade. So I did: