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. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.