Subject: kern/21404: new kernel breaks file system for old kernels
To: None <>
From: None <>
List: netbsd-bugs
Date: 04/30/2003 22:41:49
>Number:         21404
>Category:       kern
>Synopsis:       new kernel breaks file system for old kernels
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Apr 30 12:42:00 UTC 2003
>Originator:     matthew green
>Release:        NetBSD 1.6P
people's front against (bozotic) www (softwar foundation)
System: NetBSD 1.6R NetBSD 1.6R (_fish_) #134: Tue Apr 29 13:06:57 EST 2003 i386
Architecture: i386
Machine: i386

	i had been running 1.6L (just prior to SA's) on my laptop for the
	past 3.5 months, and decided it was time to update.  i built a new
	kernel after updating my config file, and booted the new kernel..
	it came up multiuser but i had somehow managed to comment npx@isa
	so many programs dumped core.  i then logged in on the console,
	and rebooted the old kernel.  at this point i lost.  while i was
	able to load the kernel and it was able to mountroot, it failed
	to check /dev/console and exec /sbin/init with ENOTDIR.  after i
	found a (1.5) bootable cdrom lying around, i was able to boot up
	and run an old "fsck".  it complained about the superblock being
	broken and needed a "fsck_ffs -b 32" to fix my file systems (not
	just root, but all of them.)
	this is extremely broken.  i don't know what exactly had happened
	to my filesystems, but simply booting a new kernel and then going
	back to the old one not working is unacceptable!  i fear what damage
	would be done to non-netbsd UFS filesystems.


	run old system.  boot -current kernel.  boot old kernel again.  lose.


	i don't know.  it's been suggested that having UFS2 be an actual
	separate filesystem type would fix this but i don't know enough
	about it to really know... as long as the fix means "we do not
	damage old filesystems".