Zugschlusbeobachtungen (Entries tagged as debian)

Heute mal wieder Debian

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 18 Jun 2012 18:53:44 +0200

In den letzten 24 Stunden habe ich endlich mal wieder was für Debian gemacht: dnstop und sipcalc vom bisherigen Maintainer übernommen, auf Vordermann gebracht und uploaded, und immerhin einen Alibi-Upload von pdns-recursor, damit auch der recursor mit der neuen Maintainer-Mailingliste im Maintainerfeld und dem korrekten Alioth-Vcs-Link im debian/control nach Wheezy kommt.

Next PowerDNS version for Debian ready for testing

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 17 Jun 2012 17:34:00 +0200

I have published PowerDNS version 3.1-1.0 on https://ivanova.notwork.de/~mh/debian/pdns/

This is a preliminary package and a release candidate to be 3.1-2 in Debian. If you’re interested in PowerDNS on Debian, please test this package.

I plan to upload next week. This package will vanish from the web server once the package is visible in Debian.

atop in unstable

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 31 May 2012 09:13:06 +0200

Eight days ago, I uploaded atop 1.26-1 to DELAYED/8, listing me as new maintainer. This means that the package has in the mean time appeared in unstable, and I hope that it’ll swiftly migrate to testing.

What are interface labels for

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 11 Mar 2011 19:28:55 +0100

Dear Lazyweb, for a long time I have been using iproute2’s label feature to assign arbitrary labels to IP addresses configured on Interfaces:

40: int152@dotqa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:25:b3:01:e5:6c brd ff:ff:ff:ff:ff:ff
inet 10.1.152.254/24 brd 10.1.152.255 scope global int152:98fe8

Recently, this has shown to at least confuse both isc-dhcp-relay (#617258) and dhcp-helper (#617264).

As I have never seen interfaces labels used outside my firewalls (which happen to use ifupdown-scripts-zg2 (Debian PTS)) and ifupdown’s rather twisted handling of multiple IP addresses per interface (using Alias Interfaces), I’d like to know whether my usage is a legitimate one and whether there are other uses for interface labels.

At the moment, I’m tempted to remove label support from ifupdown-scripts-zg2 in the next release, or to make it optional. Please comment if you have an opinion.

How much added complexity in packages to cater for apt's shortcomings?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 23 Jan 2010 12:08:00 +0100

It is well known that apt has an issue when it comes to resolving circular dependencies. Therefore, Debian bug reporters have set out to eradicate circular dependencies from the archive. This does, however, add significant bloat to the actual packages, and I am questioning why this is really necessary.

For example, aide. aide has an aide-common package, depending on aide | aide-binary. aide-binary is a virtual package by aide, aide-dynamic, and aide-xen. All three providers of aide-binary depend on aide-common again, which is a circular dependency.

If I now follow the request posed in #545852 and remove aide-common’s dependency on aide | aide-binary, I’ll have to cater for the case of the aide-binary bein absent in each and every helper script included in aide-common, which would drive the script’s complexity up to a new level. I really hate that idea.

Is it really necessary to work around apt’s shortcomings by eliminating the case that apt doesn’t handle well from the archive, and driving up other packages’ complexity (and the possibility of bugs in this added complexity)?

Booting from a large hard disk II

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 25 Oct 2009 01:03:00 +0200

Four days before my wedding, I spent some time researching booting a PC from a large hard disk, where large means “larger than two Terabytes”. These days, single disks are approaching this size, so we are near the state where this issue pops up for your run-of-the-mill computer rather than the data store RAID. Today, the per-gigabyte price is however still significantly cheaper if you go for a 1 T or an 1.5 T disk.

The old blog article shows that I spent considerable time in finding out today’s limitations below the 2 T limit by using conventional partitioning schemes to boot a 2 T disk. Since I don’t have this much storage available at the moment, I had to use virtualization and to take advantage of nearly empty virtual disks taking up much less space than their raw capacity suggests. This works fine as long as you don’t start actually using the disk.

Back then, the only combination that worked for a raw disk larger than 2 T (only using the first 2 T) was Virtualbox and grub 0 (now grub-legacy). I regret to admit that the results of my experiments from June are not any more reproducible (most probably due to changes in Virtualbox since then) and that I was not able to boot any disk larger than 2 T any more, even if the partitions were well below the 2 T limit. I chose to ignore these results and to finally start the GPT research.

Four months later, I have again found the time to finish the research on the GPT. But first a little flashback to June outlining why the classic PC-style partition table has finally reached its end. Its 32 bit sector numbers preclude us from having partitions that reach beyond the 2 TB barrier.

The GUID partition table (GPT), has been invented to cope with disks that are larger than 2 TB. Unfortunately, legacy PCs (nearly every box sold today) cannot boot a “pure GPT”, since they lack the EFI firmware which can be used to boot from a pure GPT. EFI firmware has been developed to ultimately replace the PC BIOS and is already in use on Apple hardware. But most PCs sold today still have a “classic BIOS” and therefore need a workaround to boot from a disk partitioned with GPT.

On Linux, the tool to create a GPT and to partition the disk within the GPT is GNU parted. It is available with a text console front end which reminds of the classic Linux fdisk found in util-linux, and with a GTK and a QT front end. A curses-like front end as we know from util-linux’ cfdisk is unfortunately missing, which makes parted somewhat awkward to use at installation time when one doesn’t have a GUI yet (or did never plan to actually install a GUI on the machine). This article gives a nice introduction about how to use parted to create a GPT.

A disk having a GPT looks to a classic partitioning tool like this:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      267350  2147483647+  ee  GPT

this is a big primary partition of 2 TB size with partition ID 0xee. util-linux’ fdisk will also print prominent warnings that it won’t be able to partition that disk. Other partitioning tools probably won’t.

You need to cater for two caveats before the system can actually boot: grub 2 strongly suggests that you use a "BIOS Boot Partition " for grub 2’s later stages. That partition needs to be at last 32 KB large. Additionally, I wasn’t able to boot from a partition filling the entire 5.7 TB disk, so I suspect that the boot file system needs to be inside the first two TB. This is how my test disk was finally partitioned:

# parted /dev/sda print
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 5243GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name       Flags
 1      17.4kB  1000kB  983kB                bios_grub  bios_grub
 2      1000kB  1000GB  1000GB  ext3         boot
 3      1000GB  5243GB  4243GB  ext3         data

#

It is kind of a challenge to coax parted into creating partitions that are directly adjacent to each other. I didn’t find a way to do this short of setting parted’s unit to sectors and manually typing the exact sector number.

After the disk was partitioned, I created the ext3 file systems on the two big partitions. mke2fs takes quite some memory (256 MB memory were not enough for the virtual machine, resulting into a not very helpful “killed” message on mke2fs) and time (like two hours for the larger of the two file systems), but generates the file systems just fine. They are mounted just as any other file system:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             917G  317M  870G   1% /mnt/sda2
/dev/sda3             3.8T  195M  3.7T   1% /mnt/sda3
#

and grub 2 can be installed just fine by using grub-install /dev/sda after temporarily mounting /dev/sda2 as /boot.

This setup boots grml just fine, and I suspect that any Linux OS can be booted like this as well. I guess that it will be kind of a challenge do dual-boot a disk this large with any other OS.

Samba Help Needed

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 10 Aug 2009 11:49:43 +0200

Dear Lazyweb, sorry to bother you again, but I have tried to get this question answered on IRC, on Usenet and on the Samba Mailing List, and was not able to get an answer (not even a remotely clueless one) there. Can you help?

I currently have an “interesting” task to accomplish: An IT environment with about 90 % Windows and 10 % Linux machines would like to unify backup. Currently, the Windows world backs itself up to tape using Backup Exec; the Linux world has Amanda backing up to a big disk RAID.

This RAID is acting up and is scheduled to disappear. The current plan is to back up the Linux world with Amanda to a Samba share which is then backed up to tape by the Backup Exec installation running in the Windows world.

The Linux systems are in a diffent network, and the firewall people would like to keep the ports being open between the two networks to the bare minimum. I don’t want to see NETBIOS Broadcasts inside the Linux world, I don’t want to see this server in any network neighborhood, and the system acting as the Samba server for the backup should have as few open ports as possible. Of course, the share should be read only and to be as secure as possible.

The following configuration for Samba 3.4.0 from Debian unstable seems to do what is intended (and only needs port tcp/445):

[global]
   workgroup = linuxworld
   server string = %h server
   dns proxy = no
   name resolve order = lmhosts host wins bcast
   interfaces = 192.168.8.26
   bind interfaces only = yes
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   security = user
   encrypt passwords = true
   passdb backend = tdbsam

   obey pam restrictions = yes
   unix password sync = no
   pam password change = no
   socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
   access based share enum = yes
   allow trusted domains = no
   disable netbios = yes
   load printers = no
   local master = no
   lock directory = /var/run/samba/locks
   pid directory = /var/run/samba
   max smbd processes = 10
   min protocol = NT1
   name resolve order = host
   preferred master = no
   server schannel = yes
   smb ports = 445

#======================= Share Definitions =======================

[amanda]
  comment = amanda backup
  writeable = no
  read only = yes
  locking = no
  path = /mnt/backup/srv/amanda
  public = no
  guest ok = no
  browseable = no
  hosts allow = 192.168.8.23
  max connections = 5
  valid users = amanda

Is this “secure enough” or is there potential for improvement? Which files do I need to copy to /mnt/backup/srv/amanda to run the smbd chrooted? Does it make sense to chroot the smbd in this environment?

Is this configuration going to work with Samba 3.0 (Debian etch) and/or Samba 3.2 (Debian lenny) as well?

Any hints will be appreciated.

How to have socat open a listening socket in the file system?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 07 Aug 2009 12:10:40 +0200

Dear Lazyweb, can anybody with some advanced socat-foo tell me the command line needed to have socat create a socket in the local file system and to listen on it, so that I can have Virtualbox connect a virtual serial console to it?

The material available on socat on the web is sparse, and virtualbox-related docs usually contain “tick the create pipe option”, which is not helpful here since I would like to see the first output the virtual machine prints to its serial port. It would be vastly more useful to have the socket already created with socat listening so that I can immediately see what is being printed to the socket.

Unified Kernel for etch, lenny and sid

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 06 Aug 2009 10:44:00 +0200

Traditionally, the Linux kernel is software that I compile myself from pristine upstream sources for various reasons. I have three major kernel flavours that get built (server, desktop and notebook), and I am pretty current in running a bleeding edge kernel. This is not really necessary any more nowadays, but it’s a tradition that works pretty well.

My kernels get built on sid and are packaged up with kernel-package, and equivs builds a dependency helper package which pulls in the kernel’s dependencies such as initramfs-tools and takes care of cross-version updates like going from 2.6.29 to 2.6.30. Up to now, I was always able to run a kernel built this way on all my systems which can range from oldstable to unstable.

This has recently become a bit harder when unstable’s udev started to complain that the sysfs layout was deprecated and that I should unset CONFIG_DEPRECATED_SYSFS in my kernel configuration or lose some of udev’s functionality, since a kernel compiled without CONFIG_DEPRECATED_SYSFS doesn’t properly boot on etch.

Since I wanted to avoid building even more kernel flavours, I decided to investigate which package I need to backport to etch to get kernels without CONFIG_DEPRECATED_SYSFS to work on etch. To my surprise, the cause for not booting on etch was not udev, but lvm2. With lvm2 2.02.39 (and the corresponding libdevmapper, 1.02.27-4) ported back from lenny to etch, my etch systems boot fine with CONFIG_DEPRECATED_SYSFS unset. udev can happily stay at etch’s version, 0.105-4etch1.

From etch to lenny to squeeze, the lvm2 package has evolved quite a bit. Since there is only one LVM flavour left, the lvm-common package vanished in the transition from etch to lenny, and libdevmapper still has its own source package in lenny, but is built from lvm2’s source package itself in squeeze. So, as a heads-up, there needs to be special handling for lvm-common when installing the backport on etch.

I decided to backport lvm2 from lenny to etch to allow this particular derivation from the distributions’s versions to vanish in reasonably short time when my last etch boxes get finally updated to lenny. And my dependency helper has been extended to now pull in the backported version of lvm2 to avoid nasty reboot surprises.

Bye bye KDE?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 05 Jul 2009 13:10:31 +0200

I have been using current KDE since most of my Linux time (having converted over from WindowMaker to KDE 2 back in 2002). But currently, I am seriously pondering to ditch KDE since KDE upstream seems to be wildly decided to kill KDE.

I have accidentally upgraded my desktop box to KDE4 because I missed putting KDE on hold before doing a major sid update after a couple of months. KDE4’s first regression immediately showed itself - the right display doesn’t get any attention from KDE. It just shows up in a grey checkerboard background, it doesn’t have a panel, it doesn’t have a menu, right click doesn’t work. It looks like the only thing one can do with it is dragging windows onto it.

With help of #debian-kde, I quickly found out about this bug in Upstream Bugzilla, which is referred from #529487 and which was marked as Duplicate of this bug in upstream bugzilla, which is one and a half years old and was marked as “severity wishlist”.

Despite the splendid job that the Debian KDE team has done to sort out the KDE4 mess, it looks like KDE upstream has managed to break Dual Head Setups for one and a half years and doesn’t seem to be too interested in providing KDE4 in a way that it can be compared with past versions. This is very sad and will have me shopping for a new desktop environment soon, I am afraid.

Maybe it was not a so good idea to take away KDE 3 so soon and it might have been better to keep KDE 3 in Debian. Maybe it’s time to re-introduce KDE 3 as co-installable packages? I would be willing to participate in this effort as a team member.

Which other Desktop Environments and/or Window Managers should I be shopping for? I’d like to have:

Dual-Head support (preferably with the possibility to switch desktops only on one display, but that’s something that even KDE 3 cannot do yet)
Shortcuts like “gg:search words” or “wp:search words” to immediately open google, wikipedia, the BTS or the PTS
Overlapping windows that are not automatically resized
A terminal like konsole which allows me to have different session in tabs and to send my input to all tabs
A clipboard handler that will automatically pop up a window asking me whether I want to open the URL that I just marked in a browser
Integration with the Debian menu system

Booting from a large hard disk

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 06 Jun 2009 22:38:13 +0200

I recently had to install Openfiler on a HP server with ten 750 GB hard disks on a cciss RAID controller, which proved to be a major nuisance. Since the customer wanted the box in service fast, I finally settled on wasting two of the disks as a 750 GB RAID 1 for the actual system (with like 10 GB actually used) while RAIDing the remaining disks together to a RAID 6 with spare disk for productive data.

During this task, I noticed a severe lack of current knowledge about modern PC architecture and how to boot from a big hard disk and decided to do some research into this direction. This article shows the first “results” that I have achived in the last few days.

Since the mid-eighties, we have been using basically the same PC-style partition table which has been extended a few times: The CHS (cylinder, head, sector) addressing has been changed to LBA (logical block addressing), and the “extended partition” has allowed us to use more than four partitions inside the four partition slots that the classical partition table allows. But all these changes have been backwards compatible, so we were never forced to adapt to something completely new. Big hard disks have recently started to hit a hard 2 TB limit, which cannot be overcome without incompatible changes. The classical PC-style partition table has only 32 bit sector numbers which precludes us from having partitions that reach beyond the 2 TB barrier.

So, an “incompatible” partitioning scheme, the GUID partition table (GPT) has been invented. Unfortunately, if one uses a pure GPT, one cannot boot from this disk with a normal PC BIOS as most vendors have not yet implemented GPT booting yet. Pure doctrine says that a new kind of PC firmware, called EFI firmware, can be used to boot from a GPT disk. However, EFI has not yet found significant market share beyond Apple hardware, so there is a backwards compatibility hack that allows a legacy PC (nearly every box sold today) to boot from a GPT disk. This backwards compatibility hack was what I originally sought to explore, but I had to spend significant time way earlier.

To try booting from a disk that is larger than 2 TB, one first needs a disk that is actually larger than 2 TB. Since the largest single disk available on the market today is just 2 TB big (and very expensive, measured by the Gigabyte per Euro benchmark), I would need to buy at least two disks (preferably the 1.5 TB class which currently delivers the most Gigabytes per Euro) and a method to RAID them together to a RAID 0 which is presented to the host as a single device even at boot time. I would have to shell out about 300 Euros for this, so I reckoned that I might get away with a virtual disk that grows as it is used and thus takes less disk space when it only holds a partition, and a nearly empty file system.

Unfortunately, my favorite virtualization solution, virtualbox, refuses to create a virtual hard disk larger than 2 TB via its GUI which I misinterpreted as a hard limit itself, so I had to resort to qemu which actually can handle a 4 TB virtual disk, which does take very little space if the dynamically-growing qcow2 format is being used.

Unfortunately, I wasn’t able to boot qemu from a virtual disk this big. grub 0 refused to install in the first place, and grub 2 could be installed, but it looks like the qemu BIOS refused to even look at the MBR since it just complained that it couldn’t read the boot medium. To rule out cylinder number issues, I tried first with a 1000 cylinder partition and later with a 1 cylinder partition, to no avail. Reducing the disk size to less than 2 TB solved all issues, grub 0 and grub 2 worked as advertised.

A day later, I found out that one can create Virtualbox .vdi disks with > 2 TB via the VBoxManage command line tool. After creating a 4 TB .vdi disk, creating a single 1000 cylinder partition and installing grub 2, it agreed to show me its menu just fine, but misbehaved in two interesting ways when I actually tried to boot (see #532202)

Then I tried grub 0 just to be sure. Surprisingly, grub 0 didn’t stumble and booted just fine. Next try was using a 2 TB Partition on the 4 TB disk, which is the maximum one can have with a traditional partition table. Strangely, virtualbox’ .vdi files grow much more than qemu’s qcow2 format, and a 4 TB disk with a 2 TB ext3fs on it needs like 59 GB space on disk. grub 0 boots from this disk just fine, and grml runs fine as well.

So, after like three days of preparation, I am now ready to delve into the depths of a GUID partition table, which I will blog about in a different article.

Revisiting some four months (October 2009) later, I found out that the success I had with grub 0 is not reproducible any more. With current Virtualbox, the .vdi file holding the 4 TB disk with a 2 TB ext3fs is only like 30 GB large, but no grub variant actually boots from it via a normal partition table.

synaptics and unstable?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 04 Jun 2009 23:30:30 +0200

Dear Lazyweb, I have just found out that ksynaptics has stopped working against the X in unstable, and that ksynaptics is not even in lenny, let alone in current testing and/or unstable. This currently leaves me with an unconfigured touchpad, which is a major nuisance since I have gotten accustomed to tap-dragging and touchpad border scrolling.

xserver-xorg-input-synaptics’ README.Debian dates back to 2004, so I suspect that the information given there in does not any more apply to today’s configfile-less X.

So, dear lazyweb, how do I get my touchpad back into the more intelligent mode? Clickable configuration preferred.

The grub drama

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 30 May 2009 15:22:00 +0200

This is a rant. A rant which goes to the grub maintainers, and one that could go nearly identically to many people in the KDE environment or many other open source projects.

I really like grub. I really like grub 0.97 despite that it’s been unmaintained for years and not booting on two of my important machines. I should like grub 2 because its configuration looks more straightforward and for its better features - direct booting of .iso images, from LVM and RAID. But actually, I have learned to hate grub 2 since it is not finished and badly documented, and that its existence is already being used as an excuse for grub 0’s development having stopped years ago (and it being renamed to “grub-legacy” to clearly show that it’s the unloved child) - and things looks like this is not going to change any time soon.

grub 0.97 is the de facto standard in booting Linux, its most prevalent advantages probably being its capability of reading filesystems and its command shell, which allows booting kernels and other software that one wasn’t planning to boot when the system was shut down. There is a small fraction of people who still use lilo despite its disadvantages, for example on achitectures that are not supported by grub, if one wants to have the boot FS on LVM, if one just prefers lilo for non-technical reasons or on systems that grub doesn’t work on.

The last three systems, by the way, that I still run lilo on are Pyramid pizzaboxes with supermicro-made mainboards from 2002, which just refuse to boot if grub is used and the vendor just says that grub 0.97 is still beta and that they do not support grub on their systems: “Use Lilo.”

Grub’s last upstream release, 0.97, dates back to 2005, and upstream has stopped developing this grub release years ago. grub 2, the new way to go, had its first release in 2003, and the last “stable” release that people are supposed to use dates back to februar 2008. grub 2 is clearly a step in the right direction, but there are still bugs, and the most prevalent show stopper against grub 2 is the almost complete absence of any documentation. I have, for example, not yet found good documentation about the new config file format, which is a completely different deal from what we are used to with grub 0. The commands’ manual pages do little more than list the (obvious!) command line options without giving much more information about what the actually do, let alone usage examples. The documentation (which used to be really excellent for grub 0), has been “moved” to a wiki, which has some useful content but cannot keep up with the excellent documentation that grub 0 used to have.

Additionally, grub2 does not seem to have a grub shell which can be called from within the host system, which makes installing grub 2 in “exotic” situations much harder than it used to be with grub 0.

I am also quite disappointed that despite the grub upstream web pages claiming that grub 2 is under active development, the last release is more than fifteen months in the past while there are still so many shortcomings. The Debian maintainers of grub 2 are regularly packaging grub 2 subversion snapshots, which is a good idea in face of upstream’s release policy which is quite different from what’s being told in the wiki. I am, however, reluctant to rely on a development snapshot of a software to boot productive systems.

Guys, you cannot declare a widely used, well-documented software legacy when the replacement is still in a nearly unuseable shape and the docs are hidden in the helpful files named .c and .h. This is simply unacceptable. It’s a drama that the docs are still in such a pitiful shape fifteen months after your last release.

But, grub is not the only free software project that so blatantly scores developer fun over the needs of the end user. I know that it is a boring task to fix bugs and to work around design shortcomings in the existing version of software, and that it is much more fun to hack away on new designs and new code, but dropping old versions before the new version is up to par with the old one is annoying the users and driving people away to other software packages. This applies to grub, a quite low-level program, but also to larger and more complex projects like KDE who has recently pulled the same stunt by dropping development and support for KDE 3.5 while KDE 4 is still missing many many features and KDE 3.5’s stablity, thus driving people (back) to GNOME or alternative desktop environments. This “we give a damn about people who actually use our software, our compilers run without users as well” attitude is a show of disrespect for the user base and makes me very sad as this does indeed show that free software is in no way superior to its commercial counterparts.

Sadly, I do not have a solution for this issue since I know that free software developers are usually volunteers who do not have to report to anybody, and that they do not need to care for their user base. But I hope that people begin to reconsider their attitude and think about what kind of horrible damage is being done to the user base and to free software’s reputation.

help needed for ATM support in ifupdown-scripts-zg2

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 16 Apr 2009 22:49:28 +0200

I haven’t been using ATM on Linux for some six years now. I neither have access to an ATM network any more nor do I have ATM hardware any more. Therefore, I plan to remove ATM support from ifupdown-scripts-zg2 in the next release which will be done in the next few weeks.

If anybody does still use ATM on Linux in conjunction with my scripts, you might want to offer help with the package if you want to have continued ATM support in ifdown-scripts-zg2. I cannot test the code any more and therefore cannot maintain it in the future.

partition table gone, data still present

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 08 Apr 2009 22:58:32 +0200

I just wanted to make an USB stick bootable and wondered why mkdiskimage -4 /dev/sda 0 32 64 complained about the disk having too many cylinders. After a few moments, it ocurred to me that since libata, the system hard disk has become sda and that the stick was sdb or sdc. One ctrl-C later, fdisk confirmed both counts: That I accidentally started mkdiskimaging my main system hard disk and that the partition table was already gone.

A few hours later, the notebook is back in business without too much data loss. Lucky me.

My notebook has an “alibi” installation of Windows XP in its first primary partition sized 4 GB. Since I aborted the mkdiskimage process early enough, I hoped that only the windows installation was hosed. The Linux system is entirely in LVM (with crypted LVs), and LVM hadn’t noticed yet that its PV was gone. I reckoned that I still had a chance to rescue my data if I didn’t reboot.

So I hastily commandeered an USB hard disk (thanks, $CUSTOMER, for quickly supplying one), fdisked, pvcreated and vgextended it and started the pvmove. While this was happening, I theoretically was able to continue working, which I didn’t because I was afraid of losing. About half an hour into the copy process, the USB disk chose to deregister itself and the pvmove aborted. Rebooting the disk made it reappear as sde (it was sdd before), and miraculously, a new pvmove call just worked. However, a good fraction of actions on the shell resulted in a lot of input/output errors on the screen. I guessed that this was the first sign of my data finally dying, but I let the pvmove continue.

After the pvmove was finished (which was rather fast since the move of the “crypted LV” means that the crypted data is moved and not de- and recrypted), I had to recreate a /dev/sda2 partition with type 8e before the LVM tools allowed me to vgreduce the VG.

I then zeroed out the first 10 GB of the internal disk and spent a few hours reinstalling and patching XP from scratch before I finally went through the pvcreate, vgextend, pvmove routine in the other direction. Then the big moment arrived: fsck of all LVs.

I guess that the reason for the input/output errors was that /usr was completely hosed (no single file outside lost+found), but /home and all other file systems holding data where the way back to the (a week old) backup would have been quite painful were ok. I pulled /, /usr and /var from the backup to be consistent again, updated to current sid (avoiding KDE 4 for the time being) and could start working again.

The only real loss was a few hours of work that were stored in /usr/local which died along with /usr, so the result of my stupidity was not very catastrophic but still a good lesson. And I have learned that LVM is a robust and resilient beast. Good work. Now I’d like to know what happened to my /usr - I always had the impression that pvmove should not break data even when the target disk suddenly goes away...