Skip to contentSkip to conversation

fix FreeBSD.vfs.root.mountfrom

PATCH In review Robert Millan 1 participant 3 messages Aug 4, 2009 – Aug 7, 2009

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 fix FreeBSD.vfs.root.mountfrom

FreeBSD.vfs.root.mountfrom expects an absolute path, not just device name.

Signature · 5 lines
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."
grub.d/10_freebsd.in +1 -3
Index: util/grub.d/10_freebsd.in
===================================================================
@@ -50,8 +50,6 @@ if [ "x$kfreebsd" != "x" ] ; then
     devices_rel_dirname=`make_system_path_relative_to_its_root $devices_dirname`
   fi
 
-  root_device=`basename ${GRUB_DEVICE}`
-
   # For "ufs" it's the same.  Do we care about the others?
   kfreebsd_fs=${GRUB_FS}
 
@@ -69,7 +67,7 @@ EOF
 EOF
   fi
   cat << EOF
-	set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${root_device}
+	set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${GRUB_DEVICE}
 }
 EOF
 fi
#1 lore raw
Quoted 2 lines · Robert Millan

FreeBSD.vfs.root.mountfrom expects an absolute path, not just device name.

Actually, both work, but the former is what their loader uses, and it's simpler for us to handle, so let's juse use that.

Also, the default setting on FreeBSD is to mount / as writable, for which we need vfs.root.mountfrom.options=rw.

See new patch.

Signature · 5 lines
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

2009-08-04 Robert Millan <[email protected]>

* util/grub.d/10_freebsd.in: Use an absolute device path for vfs.root.mountfrom'. Set vfs.root.mountfrom.options=rw'.

grub.d/10_freebsd.in +2 -3
Index: util/grub.d/10_freebsd.in
===================================================================
@@ -50,8 +50,6 @@ if [ "x$kfreebsd" != "x" ] ; then
     devices_rel_dirname=`make_system_path_relative_to_its_root $devices_dirname`
   fi
 
-  root_device=`basename ${GRUB_DEVICE}`
-
   # For "ufs" it's the same.  Do we care about the others?
   kfreebsd_fs=${GRUB_FS}
 
@@ -69,7 +67,8 @@ EOF
 EOF
   fi
   cat << EOF
-	set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${root_device}
+	set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${GRUB_DEVICE}
+	set FreeBSD.vfs.root.mountfrom.options=rw
 }
 EOF
 fi
#2 lore raw

Committed.

Quoted 52 lines · Robert Millan
Quoted 2 lines · Robert Millan

FreeBSD.vfs.root.mountfrom expects an absolute path, not just device name.

Actually, both work, but the former is what their loader uses, and it's simpler for us to handle, so let's juse use that.

Also, the default setting on FreeBSD is to mount / as writable, for which we need vfs.root.mountfrom.options=rw.

See new patch.

Signature · 13 lines
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

2009-08-04  Robert Millan  <[email protected]>

	* util/grub.d/10_freebsd.in: Use an absolute device path for
	`vfs.root.mountfrom'.  Set `vfs.root.mountfrom.options=rw'.

Index: util/grub.d/10_freebsd.in
===================================================================
grub.d/10_freebsd.in +2 -3
@@ -50,8 +50,6 @@ if [ "x$kfreebsd" != "x" ] ; then
     devices_rel_dirname=`make_system_path_relative_to_its_root $devices_dirname`
   fi
 
-  root_device=`basename ${GRUB_DEVICE}`
-
   # For "ufs" it's the same.  Do we care about the others?
   kfreebsd_fs=${GRUB_FS}
 
@@ -69,7 +67,8 @@ EOF
 EOF
   fi
   cat << EOF
-	set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${root_device}
+	set FreeBSD.vfs.root.mountfrom=${kfreebsd_fs}:${GRUB_DEVICE}
+	set FreeBSD.vfs.root.mountfrom.options=rw
 }
 EOF
 fi

_______________________________________________
Grub-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel

Signature · 5 lines
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."