Bug 159222 - [boot0] unusual behavior writing boot0 from single user mode
Summary: [boot0] unusual behavior writing boot0 from single user mode
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-07-27 07:30 UTC by tim newsham
Modified: 2018-05-20 23:50 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tim newsham 2011-07-27 07:30:08 UTC
I boot single user, then I run "df" to see which disk is root.  Then I run:

   # fdisk -B -b /boot/boot0 /dev/da0

when its done it says "/boot/boot0: Device not configured" (error varies)
and then afterwards most commands I type (like "ls") elicit:
"vnode_pager_getpages: I/O read error" from the kernel.

I get the same behavior on my real machine as well as in vmware.  The
vmware has a clean 8.2 release installed off of DVD (8.2 release disk)
and then updated with "freebsd-update".

How-To-Repeat: Install 8.2 release for amd64.
Update with freebsd-update (I don't know if this matters).
Boot single user.
Run "fdisk -B -b /boot/boot0 /dev/da0" (or whatever the root disk drive is).
Run "ls" after it completes.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2011-07-28 00:46:14 UTC
Responsible Changed
From-To: freebsd-amd64->freebsd-bugs

reclassify.
Comment 2 Andriy Gapon freebsd_committer 2011-07-28 16:27:53 UTC
I've noticed that you report a problem with performing some disk-related
operations, but you haven't provided any information about your disk partitioning
and filesystem layout.
Also you emphasized that the problem occurs in the single user mode, but it is not
immediately clear if you tested the same operations in the multi-user mode.

-- 
Andriy Gapon
Comment 3 tim.newsham 2011-07-28 17:59:12 UTC
On Thu, Jul 28, 2011 at 5:27 AM, Andriy Gapon <avg@freebsd.org> wrote:
> I've noticed that you report a problem with performing some disk-related
> operations, but you haven't provided any information about your disk partitioning
> and filesystem layout.
> Also you emphasized that the problem occurs in the single user mode, but it is not
> immediately clear if you tested the same operations in the multi-user mode.

I believe I got a permission denied error when trying in multi
user mode.  I assumed it was due to secure level.  I just tried it
again now and it asked me twice for confirmation and when I
did reported:
  fdisk: Class not found
  fdisk: Failed to write sector zero

at this point none of the issues I reported in the bug occur.

As for disks, I have tried on two separate systems.  One system was
created just for this test in vmware and used the .iso installer
and accepted the default partitioning and slicing offered by the installer.
I assume there's nothing special about it:

******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=1044 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=1044 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 16771797 (8189 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>


> Andriy Gapon

-- 
Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Comment 4 Andriy Gapon freebsd_committer 2011-07-30 09:03:04 UTC
on 28/07/2011 19:59 Tim Newsham said the following:
> On Thu, Jul 28, 2011 at 5:27 AM, Andriy Gapon <avg@freebsd.org> wrote:
>> I've noticed that you report a problem with performing some disk-related
>> operations, but you haven't provided any information about your disk partitioning
>> and filesystem layout.
>> Also you emphasized that the problem occurs in the single user mode, but it is not
>> immediately clear if you tested the same operations in the multi-user mode.
> 
> I believe I got a permission denied error when trying in multi
> user mode.  I assumed it was due to secure level.  I just tried it
> again now and it asked me twice for confirmation and when I
> did reported:
>   fdisk: Class not found
>   fdisk: Failed to write sector zero
> 
> at this point none of the issues I reported in the bug occur.

Can you also try to perform a supposedly equivalent operation using gpart?
/sbin/gpart bootcode -b /boot/boot0 da0
Both in multi-user and single-user modes?

> As for disks, I have tried on two separate systems.  One system was
> created just for this test in vmware and used the .iso installer
> and accepted the default partitioning and slicing offered by the installer.
> I assume there's nothing special about it:
> 
> ******* Working on device /dev/da0 *******
> parameters extracted from in-core disklabel are:
> cylinders=1044 heads=255 sectors/track=63 (16065 blks/cyl)
> 
> Figures below won't work with BIOS for partitions not in cyl 1
> parameters to be used for BIOS calculations are:
> cylinders=1044 heads=255 sectors/track=63 (16065 blks/cyl)
> 
> Media sector size is 512
> Warning: BIOS sector numbering starts with sector 1
> Information from DOS bootblock is:
> The data for partition 1 is:
> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
>     start 63, size 16771797 (8189 Meg), flag 80 (active)
>         beg: cyl 0/ head 1/ sector 1;
>         end: cyl 1023/ head 254/ sector 63
> The data for partition 2 is:
> <UNUSED>
> The data for partition 3 is:
> <UNUSED>
> The data for partition 4 is:
> <UNUSED>

Can you pls also provide gpart show and gpart list outputs?

-- 
Andriy Gapon
Comment 5 longwitz 2015-11-13 10:01:23 UTC
Writing to the first block of the disk in FreeBSD 8 with mounted readonly root partition always results in "Device not configured", when the root partition was never mounted for write before. This is normal behaviour of GEOM in FreeBSD 8. Also this is well known to Soekris users, because nanobsd.sh does not mount the root partition for write (root_rw_mount="NO") and therefore boot0cfg called in updatepX fails with "Device not configured".

After boot of FreeBSD 8 the root partition is initially mounted readonly
and sysctl -b  kern.geom.confxml gives

  <geom id="0xc5fa8480">
      <class ref="0xc0a72380"/>
      <name>ffs.label/disks2a</name>
      <rank>5</rank>
        <consumer id="0xc5f8dcc0">
          <geom ref="0xc5fa8480"/>
          <provider ref="0xc5f6f880"/>
          <mode>r1w0e0</mode>
        </consumer>
    </geom>

After "mount -uw /; mount -ur" the mode changes to r1w0e1 and the root partition will not disappear any longer, when a program tries to write to the first block of the disk. This magic in FreeBSD 8 comes from the source ffs_vfsops.c:

mount rootfs readonly:
       /*
         * If we are a root mount, drop the E flag so fsck can do its magic.
         * We will pick it up again when we remount R/W.
         */
        if (error == 0 && ronly && (mp->mnt_flag & MNT_ROOTFS))
                error = g_access(cp, 0, 0, -1);

mount -uw / (called from /etc/rc.d/root):
       /*
         * If we're the root device, we may not have an E count
         * yet, get it now.
         */
        if (ump->um_cp->ace == 0)
                error = g_access(ump->um_cp, 0, 1, 1);
        else
                error = g_access(ump->um_cp, 0, 1, 0);

On my Soekris boxes I prefer to leave the rootfs readonly all the time and
use the following patch for boot0cfg to avoid any trouble with "Device not configured":

--- boot0cfg.c.orig     2015-03-25 15:40:49.000000000 +0100
+++ boot0cfg.c  2015-06-09 20:32:53.000000000 +0200
@@ -352,21 +352,22 @@
     char *pname;
     struct gctl_req *grq;

-    fd = open(fname, O_WRONLY | flags, 0666);
-    if (fd != -1) {
-       n = write(fd, mbr, mbr_size);
-       close(fd);
-       if (n != mbr_size)
-          errx(1, "%s: short write", fname);
-       return;
-    }
-
     /*
      * If we're called to write to a backup file, don't try to
      * write through GEOM. It only generates additional errors.
+     * Otherwise if we're called to write to disk, don't try to
+     * open the disk for writing.
      */
-    if (flags != 0)
+    if (flags != 0) {
+       fd = open(fname, O_WRONLY | flags, 0666);
+       if (fd != -1) {
+          n = write(fd, mbr, mbr_size);
+          close(fd);
+          if (n != mbr_size)
+             errx(1, "%s: short write", fname);
+       }
        return;
+    }

     /* Try open it read only. */
     fd = open(fname, O_RDONLY);
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:50:13 UTC
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"