Bug 159222

Comment 1 Mark Linimon 2011-07-28 00:46:14 UTC

Responsible Changed
From-To: freebsd-amd64->freebsd-bugs

reclassify.

Comment 2 Andriy Gapon 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

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 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

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 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"