Subject: kern/3760: read only root screws up sync
To: None <gnats-bugs@gnats.netbsd.org>
From: Michael C. Richardson <mcr@sandelman.ottawa.on.ca>
List: netbsd-bugs
Date: 06/17/1997 23:54:01
>Number:         3760
>Category:       kern
>Synopsis:       read only doesn't require sync'ing
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 17 20:50:00 1997
>Last-Modified:
>Originator:     Michael C. Richardson
>Organization:
Sandelman Software Works
>Release:        1.2D
>Environment:
System: NetBSD istari.sandelman.ottawa.on.ca 1.2D NetBSD 1.2D (SSW) #10: Wed Jun 11 00:01:01 EDT 1997 mcr@istari.sandelman.ottawa.on.ca:/j/netbsd/src/sys/arch/i386/compile/SSW i386
Architecture: i386

>Description:
  I just booted up a serial test machine (i386), tried to run my
application and realized that I wasn't running with a read/write root
disk.
  I solved this by having my control script take over again and do the
right thing. This involves rebooting again to make sure the new kernel
took and running the right commands (over serial port) upon boot.
  This is what I saw when going down:

elrond# /puijo/bin/sshkeyd -k /etc/vpn/ssh.kdb -D sshkeyd=10 >&/tmp/sshkeyd.log&
/tmp/sshkeyd.log: Read-only file system.
[1] 21
[1]    Exit 1                 /puijo/bin/sshkeyd -k /etc/vpn/ssh.kdb -D sshkeyd=10 >& /tmp/sshkeyd.log
elrond# jobs
elrond# 
puijo test cmd: reboot
rm -f /netbsd; ln -f /netbsd.puijo0 /netbsd; reboot
rm: /netbsd: Read-only file system
ln: /netbsd: Read-only file system
Jun 18 04:46:30 init: kernel security level changed from 0 to 1
syncing disks... fs = /
panic: update: rofs mod

dumping to dev 1, offset 104576
dump 8 7 6 5 4 3 2 1 succeeded

  It would appear that the attempt to create files causes the file
system buffers to be dirty, even though the file system can't be
modified, being read only.
  The system should just go down, or shouldn't mark those pages as dirty.

>How-To-Repeat:

  If my hypothesis is correct, it should be just:

  reboot -- -s
  get a single user shell
  # touch /foo	
	[it fails]
  # reboot

  But this doesn't reproduce it, nor does repeating my previous script
controlled proceedure. Sorry, I can't be more helpful here.

>Fix:

>Audit-Trail:
>Unformatted: