On Monday 03 May 2010 12:10:24 Boyd Stephen Smith Jr. wrote: > On Monday 26 April 2010 16:34:38 Boyd Stephen Smith Jr. wrote: > > It doesn't appear to be a file system issue, but rather a problem with > > the initramfs scripts. It could also be rooted in my configuration. I > > know that my "root=" kernel parameter has to differ from the device name > > in my /etc/fstab in order to get the initramfs to correctly initialize > > LVM. > > I wanted to report that I was able to diagnose and solve this. The problem > was that /lib/udev/vol_id in my initramfs could not identify a btrfs file > system, which caused the scripts to try and mount the root file system > using '-t unknown' as part of the command-line arguments. > > I upgraded initramfs-tools and udev to the Sid versions. This should cause > a initramfs rebuild as part of the postinst, but if it doesn't do so on > your system, be sure to run (update-initramfs -k all -u). Now my system > boots unattended with a btrfs '/'. > > So, at this time, btrfs can be used for non-'/' file systems with the tools > from lenny-backports. However, newer udev/initramfs-tools are required to > boot with a btrfs '/'. I hope they are included in the Squeeze release. I > have not, and probably will not test a btrfs '/boot'. > > I have also been encountering issues with suspend and resume on this new > install. I don't currently believe these are btrfs-related, either, but > fair warning. They were, again, not btrfs related. Initially mouse and keyboard were mostly dying on resume from RAM. (Alt+SysRq continued to work.) Upgrading acpid to lenny-backports resolved this issue for the most part. After that, the framebuffer was corrupted on resume from RAM. If I restarted X through Alt+SysRq+K (I use kdm), I could continue to use X, but all the other virtual consoles were unusable. I believed this to be an issue with xserver-xorg-video-intel, so I upgraded it to testing. At this point, normal booting would hang the GPU when starting kdm; no chance to address suspend/resume. Some troubleshooting indicated that if the vbesave init script from acpi-support were run prior to the kdm init script, that would cause the hang. If the vbesave init script was not run, the system operated normally. I purged acpi-support, since it was not a strong dependency of anything installed on the system. Boot worked normally. Suspend to RAM / resume works. Suspend to disk / resume works. Suspend to both (manually running /usr/sbin/s2both) and resume (from RAM) works. As you might guess, there were a number of unclean reboots during this time. btrfs never had issues that prevented booting. The journal replay / recovery is a bit less verbose that reiserfs and ext3, but it did occur and had to make some of the same corrections ("unlinking 27 orphans"). At one point, I did slightly suspect btrfs, so I ran a btrfsck while the file system was mounted. It could also benefit from being slightly more verbose, but it completed fairly quickly and reported no errors. I also did an on-line defragment of the whole file system around the same time. It took longer than I would like, since it gave no progress indication; again, more verbosity (or at least an *option*) would be appreciated. -- Boyd Stephen Smith Jr. ,= ,-_-. =. email@example.com ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Description: This is a digitally signed message part.