[Bug 557429] Re: booting out of sync RAID1 array fails with ext3 (comes up as already in sync)

[Jamie Strandboge]

>From irc:
13:18 < psusi> jdstrand: when you boot with one disk, you get the warning abut 
               being degraded and are given 15 seconds to abort activating 
               degraded or not, right?
13:19 < jdstrand> psusi: I don't see a warning cause of plymouth, but there is 
                  a pause yes
13:23 < psusi> jdstrand: can you boot with nosplash and noquiet boot options to 
               disable that?  after plugging both disks back in, the udev 
               script tries to do an incremental build when it detects each 
               disk.  That should fail for both disks, then eventually after a 
               timeout, the fallback script should try to do the degraded 
               activate... at that point only one disk should be activated and 
               the other ignored
13:31 < jdstrand> psusi: I didn't get to grub in time, but after a long pause 
                  it flashed a screen at me very clearly stating I am booting 
                  in degraded mode (each time with disk1 and disk2 removed)
13:34 < psusi> jdstrand: did you still get that timeout and message about 
               degraded when you reconnect the second disk?  or does it just 
               plod along happily like nothing is wrong at all?
13:34 < psusi> until the fsck fails of course
13:34 < jdstrand> I don't think I got the timeout, let me check
13:36 < jdstrand> psusi: no pause. straight to file system errors


** Description changed:

  Using the latest beta-2 server ISO and following
  http://testcases.qa.ubuntu.com/Install/ServerRAID1, booting out of sync
  RAID1 array fails with ext3 (comes up as syncd).
  
  Steps to reproduce:
  
  1. in a kvm virtual machine, using 2 virtio qcow2 disks each 1768M in size, 768M ram and 2 VCPUs, in the installer I create the md devices:
  /dev/md0: 1.5G, ext3, /
  /dev/md1: ~350M, swap
  
  Choose to boot in degraded mode. All other installer options are
  defaults
  
  2. reboot into Lucid install and check /proc/mdstat: ok, both disks show
  up and are in sync
  
  3. shutdown VM. remove 2nd disk, power on the VM and check /proc/mdstat:
  ok, boots degraded and mdstat shows the disk
  
  4. shutdown VM. reconnect 2nd disk and remove 1st disk, power on the VM
  and check /proc/mdstat: ok, boots degraded and mdstat shows the disk
  
  5. shutdown VM. reconnect 1st disk (so now both disks are connected, but
  out of sync), power on the VM
  
  Expected results:
  At this point it should boot degraded with /proc/mdstat showing it is syncing (recovering). This is how it works with ext4. Note that in the past one would have to 'sudo mdadm -a /dev/md0 /dev/MISSING-DEVICE' before syncing would occur. This no longer seems to be required.
  
  Actual results:
- Array comes up with both disks in the array and in sync. fsck notices this and complains a *lot*:
+ Array comes up with both disks in the array and in sync.
+ 
+ Sometimes the are error messages saying that there are disk errors, and
+ the boot continues to login, but root is mounted readonly and
+ /proc/mdstat shows we are in sync.
+ 
+ Sometimes fsck notices this and complains a *lot*:
  /dev/md0 contains a filesystem with errors
  Duplicate or bad block in use
  Multiply-claimed block(s) in inode...
  ...
  /dev/md0: File /var/log/boot.log (inode #68710, mod time Wed Apr  7 11:35:59 2010) has multiply-claimed block(s), shared with 1 file(s):
   /dev/md0:     /var/log/udev (inode #69925, mod time Wed Apr  7 11:35:59 2010)
  /dev/md0:
  /dev/mdo0: UNEXPECTED CONSISTENCY; RUN fsk MANUALLY.
  
  The boot loops infinitely on this because the mountall reports that fsck
  terminated with stats 4, then reports that '/' is a filesystem with
  errors, then tries again (and again, and again).
  
  See:
  http://iso.qa.ubuntu.com/qatracker/result/3918/286
  
  I filed this against 'linux'; please adjust as necessary.

-- 
booting out of sync RAID1 array fails with ext3 (comes up as already in sync)
https://bugs.launchpad.net/bugs/557429
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to linux in ubuntu.