I recently almost died from a heart attack because after a really horrible crash (don't ask), Debian unstable on my laptop wouldn't boot anymore. The system hung at "Waiting for root filesystem...", and I was in panic mode as I feared I lost all my data (and as usual my backups were waaay too old).
At first I was suspecting that something actually got erased or mangled due to the crash, either at the dm-crypt layer, or the LVM layer, or the ext3 filesystem on top of those. After various hours of messing with live CDs, cryptsetup, lvm commands (such as pvscan, pvs, vgchange, vgs, vgck) and finally fsck I still had not managed to successfully boot my laptop.
I finally was able to boot by changing the initrd from initrd.img-2.6.30-2-686 to initrd.img-2.6.30-2-686.bak in the GRUB2 menu (at boot-time), at which point it was clear that something was wrong with my current initrd. A bit of debugging and some initrd comparisons revealed the cause:
Both, the cryptsetup and lvm2 packages were no longer installed on my laptop, which made all update-initramfs invokations (e.g. upon kernel package updates) create initrds which did not contain the proper dm-crypt and lvm functionality support. Hence, no booting for me. I only noticed because of the crash, as I usually do not reboot the laptop very often (two or three times per year maybe).
Now, as to why those packages were removed I have absolutely no idea. I did not remove them knowingly, so I suspect some dist-upgrade did it and I didn't notice (but I do carefully check which packages dist-upgrade tries to remove, usually)...
To quote from the website:
Qi Hardware, founded on the belief in open hardware, produces mass market quality hardware applying free software principles to consumer electronics. The three fundamental elements in our development are copyleft hardware, upstream kernels and community driven software.
They have put up a timeline for upcoming products, where the 本 NanoNote™ (Ben NanoNote™) — a fully open multifunction ultra small form factor computing device — is the first entry product that is supposed to ship in fall 2009.
The Ben NanoNote is based on an Ingenic SoC (336 MHz XBurst Jz4720 MIPS-compatible CPU) with 3.0” color TFT (320x240), 2GB NAND flash, 32 MB SDRAM, SDHC microSD, micro-USB 2.0. The whole device, including the 850mAh Li-ion battery, weighs only 126g. Detailed specs are available.
Their currently planned setup includes a Linux kernel, u-boot, and OpenWRT as software basis. Personally, I'd like to see a stock Debian running on the hardware sooner or later, of course. The 2GB of flash and 32MB of RAM should be fine for a small Debian system (for instance, my NSLU2 runs off a 1GB thumb drive and has 32MB RAM, and is still very useful).
The code is all GPL'd and available from various git repos, hardware will be CC-BY-SA 3.0 licensed, and they try to use Free Software design and development tools also, including KiCAD for schematics and PCB layout, and probably HeeksCAD as CAD tool for mechanical stuff.
I'm really tired of seeing more and more self-proclaimed "Open Hardware" projects that often don't even mention any license for their schematics and PCBs, or use crappy, self-invented "open" licenses that are not even remotely open in any way. Probably even worse, many hardware related projects use closed-source, proprietary electronic design tools such as EAGLE or OrCAD, thereby ruining the whole project from the beginning by forcing everyone who likes to contribute or adapt the hardware to use non-free software. That's why I was really happy to see the Qi people thrive to use open tools from the beginning! I hope to see more hardware projects use KiCAD or gEDA/PCB for their designs in future...
If you recently upgraded your kernel to the 2.6.29 Debian package, you might have noticed some (e.g. graphics) drivers stopped working or are working slower. In my case, this was the radeon driver, which inexplicably seemed to cause lots of slowdowns in some applications and games. A quick look into dmesg revealed the reason:
[drm] Initialized radeon 1.29.0 20080528 on minor 0 agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode pci 0000:01:00.0: putting AGP V2 device into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin radeon_cp: Failed to load firmware "radeon/R200_cp.bin" [drm:radeon_do_init_cp] *ERROR* Failed to load firmware!
As noted in the changelog file, the radeon firmware R200_cp.bin has been removed from the kernel, and is now available in the separate firmware-linux Debian package. So the simple fix for this issues is:
$ apt-get install firmware-linux $ dpkg -L firmware-linux | grep R200_cp.bin /lib/firmware/radeon/R200_cp.bin
After restarting X, the dmesg output looks more sane again:
agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode pci 0000:01:00.0: putting AGP V2 device into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin [drm] writeback test succeeded in 2 usecs
The coreboot project (previously known as LinuxBIOS) is taking part in the Google Summer of Code™ 2008 program. This year, the project has been assigned two slots/students who will work on the following projects:
This project aims to integrate into the coreboot BIOS a payload consisting of a minimalist KVM-aware Linux kernel along with an initrd image that contains the tools needed for creating and starting guest virtual machines installed on top of it. The resulting system could host any x86(or x86-64) OS that can run over KVM (almost any major OS does), and there is a great challenge to make it as small as possible, so that it can fit in a 2MB flash image.
Currently coreboot can not boot from an arbitrary SCSI controller. There are two solutions for the problem: (1) Use Linux and Kexec. This requires to keep the SCSI driver in the flash chip. (2) Use x86emu/vm86/ADLO and the int13 method. This would allow to use the PCI option rom available on all modern SCSI controllers. So we obviously need a solution based on the latter. This could as well be implemented as a Linux program, as an intermediate payload, or as a shared library. At this point of time, I would like to implemente it as a daemon program. The program needs to catch the int13 interrupt vector that the SCSI option rom installs and make it available to arbitrary (firmware/payload) code trying to load something from disk.
This should make for an interesting summer with nice improvements for coreboot.
I've bought a new hard drive for my laptop recently, because I finally got fed up with my constantly-full disk. Having to browse around in $HOME looking for stuff which can be safely deleted just because I want to run
fetchmail (and that would fill up my disk) just sucks. So, after getting a cheapo 160 GB 2.5" disk (the old one was 80 GB), I had to move all my data to the new disk.
As I didn't want to re-install from scratch I started with
dd'ing the whole disk over to the new one (using a live CD and an external USB hard-drive enclosure). This took pretty long, but went fine otherwise.
The new disk then contained all my partitions (hda1-hda3) and also GRUB in the MBR etc., as expected, but was still only 80 GB in size, of course. So the first step is to enlarge the hda3 partition, which is a dm-crypt volume that contains various LVM logical volumes (for /home, /usr, /var, swap, etc.), each of them using the ext3 filesystem (except for the swap volume, of course).
0. Perform backups, boot from a live CD
Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!
First off, you should boot from a live CD which has all the tools you'll need, including cryptsetup, LVM tools, resize2fs, etc. You can use the nice grml live CD for instance.
1. Resize partition
This sounds scary (and it is!), but the way I enlarged the encrypted hda3 partition was by first deleting it via
fdisk. First, issue the "p" command in fdisk, write down the exact start cylinder of hda3. Then delete hda3. Now create a new hda3 partition which starts at exactly the same cylinder as the old hda3 but is larger, i.e. in my case it has ca. 80 GB additional space.
Your data will still be there if you don't screw up, and the partition is bigger now. Using something like gparted will likely not work as expected, as the partition is encrypted!
2. Resize dm-crypt volume
Nothing to be done, it seems dm-crypt automatically adapts and notices that the partition is bigger. Just "open" the encrypted volume using
$ cryptsetup luksOpen /dev/hda3 foo
3. Resize LVM physical volume
Next step is to tell LVM about the new space. We first resize the LVM physical volume on the
foo "partition" to use up all newly-available space.
$ pvresize /dev/mapper/foo
4. Resize LVM logical volume
Now we can pump the new space into any of the logical volumes (or into multiple ones). I only increased one logical volume, my /home:
$ lvresize -L +74 GB /dev/vg-whole/lv-home
5. Resize ext3 filesystem
The final step is to resize the ext3 filesystem on the
lv-home logical volume (after running the obligatory fsck -n). I first used ext2resize, but that failed horribly:
$ fsck -n /dev/vg-whole/lv-home $ ext2resize /dev/vg-whole/lv-home error: Invalid argument: seeking to 3258921205760
This seems to be a known bug, ext2resize apparently cannot handle large disks or something, and as I found out a few minutes later it's pretty much deprecated anyway. The better solution is to use resize2fs:
$ fsck -n /dev/vg-whole/lv-home $ resize2fs /dev/vg-whole/lv-home
That's it. We can now reboot the system from disk and enjoy ca. 80 GB of additional hard drive space. Yay!