In single-user mode (with just / mounted r/o), any change to the label of the disk the root partition is residing on seems to immediately invalidate the device for the kernel. E.g., after the partition was written out by bsdlabel(8), any access to the disk with fail with EIO or EXIO. OTOH, in multi-user mode (i.e., with everything mounted r/w) editing the label is just impossible: bsdlabel will complain: bsdlabel: Class not found How-To-Repeat: Boot in single-user mode. Create MFS /tmp so that the editor is happy: mdmfs -s10m md /tmp Change the default editor: export EDITOR=ed Start bsdlabel: bsdlabel -e ad0s1 Make a harmless change, e.g., create a new partition in the unused space at the end of the disk -- make sure there is some! Save. Run any command from / as nothing else is mounted, e.g., "ls /boot" or "reboot" See the kernel croak: vnode_pager_getpages: I/O read error ls: Input/output error or reboot: Device not configured
Responsible Changed From-To: freebsd-bugs->freebsd-fs Filesystem related.
I found bsdlabel: Class not found many times, and I have no solution. I saw it even on single user mode. Please help me, for I cannot update my boot code by bsdlabel -B, and I cannot use ahci.
State Changed From-To: open->feedback Do you still able to reproduce this problem on recent releases?
Hi there, Sorry but FreeBSD 9.0-RELEASE still appears to have this issue. When installed using BSD label partitioning scheme, a modification to ada0's label seems to nuke the kernel's view of the disk -- I can't think of a better way to explain it. The disk itself is OK and the change makes it OK to the disk but the kernel can no more use the root partition until rebooted, returning weird errnos such as EIO or EXIO. No idea here if the bug is limited to BSD label scheme. Cheers, Yar
Hi Andrey, 2012/2/6 Andrey V. Elsukov <ae@freebsd.org>: > On 04.02.2012 7:50, Yar Tikhiy wrote: >> >> =A0Sorry but FreeBSD 9.0-RELEASE still appears to have this issue. =A0Wh= en >> =A0installed using BSD label partitioning scheme, a modification to >> =A0ada0's label seems to nuke the kernel's view of the disk -- I can't >> =A0think of a better way to explain it. =A0The disk itself is OK and the >> =A0change makes it OK to the disk but the kernel can no more use the roo= t >> =A0partition until rebooted, returning weird errnos such as EIO or EXIO. >> =A0No idea here if the bug is limited to BSD label scheme. > > When you are in single user mode your root filesystem is mounted read-onl= y. > When you run bsdlabel it opens geom provider for writing and this trigger= s spoiling for it. > When bsdlabel closes provider GEOM_PART destroys it and creates again. > But VFS code seems loses it. Sorry but do you think it's intended behavior or not? It doesn't look so to me and, IMMSMR, it wasn't there before. Please correct me if I'm wrong. Thanks, Yar
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped