boot - Fix boot probe ordering
authorMatthew Dillon <dillon@apollo.backplane.com>
Sun, 12 Aug 2012 00:09:11 +0000 (17:09 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Sun, 12 Aug 2012 00:09:11 +0000 (17:09 -0700)
* When boot loader support is compiled w/ UFS and HAMMER together, which
  is the default (note: HAMMER booting's never worked well)... the probe
  order was to check for the hammer volume header first and UFS second.

* Change the probe order to check for UFS first and HAMMER second.  The
  reason is that a 'newfs' (for UFS) doesn't wipe the hammer volume header
  because the ufs's newfs tries to 'skip' the partition reserved area of
  the disk.

  This is a huge throwback to the original BSD fdisk/disklabel which put
  the boot code INSIDE the 'a' partition.

* The DragonFly disklabel64 (which is now the default) does not have this
  problem so we could probably at some point adjust the UFS 'newfs' code to
  wipe the old 'reserve' area to really put a cap on the problem.

Reported-by: tuxillo
sys/boot/pc32/boot2/boot2.c

index c6de59a..5d0df04 100644 (file)
@@ -603,10 +603,10 @@ dskprobe(void)
      * Probe filesystem
      */
 #if defined(UFS) && defined(HAMMERFS)
-    if (boot2_hammer_api.fsinit() == 0) {
-       fsapi = &boot2_hammer_api;
-    } else if (boot2_ufs_api.fsinit() == 0) {
+    if (boot2_ufs_api.fsinit() == 0) {
        fsapi = &boot2_ufs_api;
+    } else if (boot2_hammer_api.fsinit() == 0) {
+       fsapi = &boot2_hammer_api;
     } else {
        printf("fs probe failed\n");
        fsapi = &boot2_ufs_api;