kern/175179: ZFS may attach wrong device on move
>Number: 175179 >Category: kern >Synopsis: ZFS may attach wrong device on move >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 10 13:20:01 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Steven Chamberlain >Release:9.0-RELEASE-p5 >Organization: >Environment: GNU/kFreeBSD mail 9.0-2-amd64 #0 Sat Nov 24 04:44:27 UTC 2012 x86_64 amd64 AMD Athlon(tm) 64 Processor 3700+ GNU/kFreeBSD (This was an issue seen originally seen on Debian GNU/kFreeBSD systems http://bugs.debian.org/651624 but I'm now reporting it as a believed FreeBSD kernel ZFS bug). >Description: In the uncommon situation that a ZFS zvol resides on a msdos partition, and that partition extends to the end of the drive, there can be a problem when the device is renamed (e.g. /dev/ad0->/dev/ada0, renaming of SCSI driver, or reattachment of drive to another bus). Since the drive location no longer matches zpool.cache, dev_geom_attach_by_guid searches all GEOM devices for it. The matching GUID may be found first at the end of /dev/ada0, and so the whole-disk device is attached instead of, for example, /dev/ada0s4 The pool is started, but because the start of /dev/ada0 is in the wrong place, the device is marked UNAVAIL. If enough devices in the pool were renamed (especially in the case of FreeBSD 8->9 renaming, /dev/ad?->/dev/ada?) then a root-on-ZFS system will be unbootable as shown: > ada0: Previously was known as ad4 > [...] > Trying to mount from zfs:tank/root [rw]... > vdev_geom_open_by_guid:352[1]: Searching by guid [$number] > vdev_geom_read_guid:239[1]: Reading guid from ada0 > vdev_geom_read_guid:273[1]: guid for ada0 is $number > vdev_geom_attach:95[1]: Attaching to ada0. > vdev_geom_attach:116[1]: Created geom consumer for ada0 > vdev_geom_open_by_guid:363[1]: Attach by guid [$number] succegged, provider > /dev/ada0 > vdev_geom_detach:156[1]: Closing access to ada0 > vdev_geom_detach:160Mounting from zfs:tank/root failed with error 6 Destroyed > consumer to ada0 >How-To-Repeat: I find it easiest to reproduce with qemu: Create a VM with -hda disk1.img -hdb disk2.img Partition with /dev/ada?s1 (unused), and /dev/ada?s4 which extends to the end of the disk; create a mirrored root zpool on /dev/ada0s4 and /dev/ada1s4 and set that up to become the root filesystem. Reboot and verify this is working. Now shut down, and 'move' the drives to the second IDE bus when restarting the VM: -hda /dev/null -hdb /dev/null -hdc disk1.img -hdd disk2.img Mounting from zfs:tank/root failed with error 6 Alternate method: create the root zpool on IDE disks with FreeBSD 8, then try to upgrade to a FreeBSD 9 kernel. Device renaming triggers the same issue. >Fix: GEOM partitions should ideally be checked before the whole disk. The problem is easily avoided though by leaving a little space at the end of the drive. For each drive in the zpool: I detached, adjusted the ZFS partition's start+end sectors to leave some space at the end of the disk, zeroed that space, reattached it in the pool, resilvered and updated zpool.cache. Re-testing as above, the /dev/ada?s4 partitions are then properly detected upon being moved. Thanks! >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/175181: bsdinstall doesn't install base files from /usr/share/skel; breaks POLA
>Number: 175181 >Category: bin >Synopsis: bsdinstall doesn't install base files from /usr/share/skel; >breaks POLA >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 10 15:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release:10-CURRENT >Organization: EMC Isilon >Environment: FreeBSD fallout.local 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r+96bb463: Tue Jan 8 00:39:55 PST 2013 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd64 >Description: I grabbed one of gjb's livecd releases and when I was going through trying to set things up, I noticed that .profile wasn't installed to my home directory like I expect if I would have run pw useradd -m. bsdinstall (and the password utility it uses) needs to follow an equivalent process because otherwise it's silly that one has to manually setup files in user's home directories when installing from the livecd. >How-To-Repeat: - Install from a FreeBSD 9.0+ LiveCD. - Create a user foo. - Note that ~foo/ doesn't contain .profile and other files from /usr/share/skel. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/175182: kernel panic on RADIX_MPATH when deleting route
>Number: 175182 >Category: misc >Synopsis: kernel panic on RADIX_MPATH when deleting route >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Jan 10 15:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: oleg >Release: >Organization: >Environment: 9.1 release amd64 >Description: simplest crush on virtualbox: options RADIX_MPATH problem with -link or -interfcace option to route delete >How-To-Repeat: cd /usr/src/ echo " include GENERIC options KDB # Enable kernel debugger support. options DDB # Support DDB. options RADIX_MPATH " > sys/amd64/conf/MY #make -j8 kernel KERNCONF=MY -DNO_CLEAN -DNO_CLEANDIR -DNO_KERNELCLEAN #reboot #=== #sync;sync;sync;sleep 1;sync # virtualbox default gate and interface iff=em0 gw=10.0.2.2 #netstat -rnf inet #here panic: route delete default $gw -link $iff #OR route delete default $gw -interfcace $gw >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/167103: dtrace(1) generates core dump trying to build perl with dtrace enabled
Synopsis: dtrace(1) generates core dump trying to build perl with dtrace enabled State-Changed-From-To: open->analyzed State-Changed-By: markj State-Changed-When: Thu Jan 10 22:45:48 UTC 2013 State-Changed-Why: I understand the problems now and am working on some patches. The second problem described in my replies is due to a bug in libelf which has been fixed upstream (in elftoolchain). Responsible-Changed-From-To: freebsd-bugs->markj Responsible-Changed-By: markj Responsible-Changed-When: Thu Jan 10 22:45:48 UTC 2013 Responsible-Changed-Why: I understand the problems now and am working on some patches. The second problem described in my replies is due to a bug in libelf which has been fixed upstream (in elftoolchain). http://www.freebsd.org/cgi/query-pr.cgi?pr=167103 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting route
Old Synopsis: kernel panic on RADIX_MPATH when deleting route New Synopsis: [panic] kernel panic on RADIX_MPATH when deleting route Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jan 11 07:51:36 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=175182 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
