Bug 166375

Summary: dmesg > /var/log/dmesg hangs and breaks boot up on AMD64 notebook
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: rawhideCC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.12-1.1502_FC5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-21 20:08:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alexandre Oliva 2005-08-19 20:59:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b3) Gecko/20050818 Fedora/1.1-0.2.7.deerpark.alpha2.1 Firefox/1.0+

Description of problem:
Boot up would hang on my notebook as soon as I first tried kernel-2.6.12-1.1499_FC5, right after enabling swap partitions.  Further investigation has revealed that it was the rc.sysinit command `dmesg -s 131072 > /var/log/dmesg' that stopped the boot from making progress.

I forced an fsck of all filesystems on kernel-2.6.12-1.1492_FC5, that boots up just fine, to no avail.

I booted up 1499_FC5 with init=/bin/bash, remounted / rw and ran dmesg > /tmp/dmesg (same filesystem), and that worked.  dmesg > /var/log/dmesg, however, would still hang.  true > /var/log/dmesg wouldn't, and would successfully zero out the file.  Moving the existing /var/log/dmesg out of the way was no use either; dmesg > /var/log/dmesg would still hang.

strace /bin/dmesg completed successfully; strace /bin/dmesg > /tmp/dmesg did as well; writes were line-buffered in the first case, and in 4KiB blocks in the second, as expected.  strace /bin/dmesg > /var/log/dmesg would succeed in the first two 4KiB writes to stdout, but the third would never complete.

After the first failure, the system came back up with /dev/md8 in need of resync.  /dev/md8 is the raid 1 device holding the physical volume that contains (part of?) the logical volume containing the root filesystem.  In all other cases /dev/md8 was resyncing, and this didn't seem to affect the results.

I tried to make sure the problem was not related with sbp2 or usb-storage (I've got two external disks on which swap and raid devices are mounted), and either they're both broken, or the problem is unrelated with them.

Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1499_FC5

How reproducible:
Always

Steps to Reproduce:
1.Boot up an AMD64 notebook onto 1.1499_FC5
2.After it hangs, reboot with init=/bin/bash
3.Remount / rw, then run dmesg > /var/log/dmesg
  

Actual Results:  It hangs

Expected Results:  1.1492_FC5 doesn't, and that was good :-)

Additional info:

Comment 1 Alexandre Oliva 2005-08-21 20:08:46 UTC
1.1502_FC5 and 1.1504_FC5 work fine.