Hard disk partition pregap and grub2
A week or so back, I was at a customer to upgrade his server to wheezy. This server had originally been installed, not as squeeze but as something older, and was installed using an LVM-on-mdraid setup.
Booting off such a setup (without a /boot partition outside of the raid/LVM) is certainly possible with several boot loaders, including grub2; however, it was having issues in this particular instance, producing an error message along the likes of:
/sbin/grub2-setup: warn: Your embedding area is unusually small. core.img won't fit in it..
It took me a while to figure out what that meant, but the Internet to the rescue:
Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000b3c3b Device Boot Start End Blocks Id System /dev/sda1 * 2048 312580095 156289024 83 Linux
That partition starts at the 2048th block, resulting in a 1MiB gap before the first partition. The older default was to start on the 63rd block, for a pregap of just short of 32KiB.
Unfortunately, the only way to fix this issue without ugly hacks (such as the chainloading suggested in this fedora forum thread) is to repartition. Luckily, thanks to the magic of LVM, this isn't difficult (if a little involved). Steps:
pvmove -v /dev/md0 vgreduce -a mdadm -S /dev/md0 (...repartition the hard disks that make up /dev/md0...) mdadm -C /dev/md0 (... other options required to recreate /dev/md0 on the desired RAID level...) pvcreate /dev/md0 vgextend /dev/vg /dev/md0
... and then rinse, repeat for md1. At that point, installing grub will work as usual.
An alternative (since we were using RAID1) could have been to remove one disk from the RAID array, repartition it, create a new RAID1 array in degraded mode, pvmove over to that, destroy the original array, and add the second disk to the new array. This would probably be a better idea when you only have one RAID array, for instance, or when you have more than one array and have more data than fits on a single array. However, that wasn't the case here (at least not after a resize2fs -M call followed by an appropriate lvresize one), and so I thought that not reducing redundancy, even if only temporarily, was a better move.
Debconf13
So debcamp has been going on for just over five days now, and it's been a success and a failure at the same time.
A success, because the organization is wonderful, the food is good, the location is excellent, and the fun is everywhere.
A failure, because with all these nice things going on, I've done only 300 lines of code (or so) of the nbd-server rewrite that I'd planned to do.
Ah well. I suppose I'll have to either cram, or find another time to do so, then.
Bloody spammers
2013-08-13 14:51:38 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:51:44 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:51:51 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:51:58 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:52:04 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:52:11 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:52:18 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:52:25 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication! 2013-08-13 14:52:32 H=<censored>.hinet.net (ylmf-pc) [<also censored>] rejected AUTH LOGIN: Please use encryption for authentication!
Thank god for firewalls.
Debconf bid voor Mechelen
Gisteren heb ik besloten dat, als ik ooit die vage plannen om Debconf in België "ooit" te laten doorgaan realiteit wou laten worden, dat ik er dan maar beter iets aan deed. Dus had ik iets van "foert", en heb ik besloten om een bod te doen deze zaterdag hier op debconf13, om een debconf te organizeren in Mechelen in 2015.
Uiteraard is er veel planning nodig om Debconf te realizeren. Het is mogelijk dat ikzelf niet genoeg tijd ga hebben, maar ik ga het proberen. In elk geval heb ik zeker niet genoeg tijd om debconf helemaal alleen te organiseren.
Dus is dit een officiële roep om hulp. Als je in of dichtbij Mechelen woont (waarbij "dichtbij" verstaan moet worden als iets waarbij jij je gemakkelijk voelt voor het maken van een verplaatsing), en je zou graag bijdragen aan Debian op een niet-technische manier, dan is dit je kans. Als je graag zou willen meewerken om Debconf in Mechelen een realiteit te maken, en je hebt wel wat tijd gedurende de komende twee jaren ofzo, dan hoor ik graag van je. Zelfs als je niet zeker bent dat je genoeg vrije tijd hebt, dan nog zou ik graag van je horen—het zou wel kunnen dat we merken dat je genoeg tijd hebt (en niemand verwacht dat je hier voltijds mee bezig bent...)
Als je interesse hebt, stuur me dan een mailtje (emailadres onderaan mijn weblog), en dan zien we wel.
RIP userdevfs
... and good riddance
Just over 10 years ago now (it really has been that long), I had a first stab at adding some code to debian-installer to support m68k machines. As part of that, I invented userdevfs, a d-i module which would grep dmesg to figure out which hardware is detected, and would dynamically generate /dev entries based on that. It made it possible to use debian-installer without too much trouble on kernels that didn't support autoloading of modules (d-i expects the absense of a /dev entry to signal the absense of hardware), while our m68k kernel hadn't gone beyond 2.2 still; but it was always a bit of an ugly hack.
At the time, I saw it as a short-time necessary evil. When the m68k port had been kicked from Debian, I would probably have thrown it out. Had it never been kicked from Debian, all else being equal, I would probably still have kicked it given a chance, since 2.6 kernels can now be run on m68k machines. All that is not true, though, since in the mean time my ugly hack had been repurposed to also work on ports that did support 2.6 and more recent kernels, but did not support autodetecting hardware. As such, it's still in recent Debian releases.
Today, however, I noticed #717872, signalling that as the one port where it was still needed no longer did, my ugly hack has finally found its demise.
That is a good thing.
Snapshot.debian.org
E: Release file for http://snapshot.debian.org/archive/debian/20111207T220456Z/dists/unstable/InRelease is expired (invalid since 624d 17u 27min 15s). Updates for this repository will not be applied.
sigh.