From owner-freebsd-fs@FreeBSD.ORG Sun Nov 3 03:22:21 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A21B339F; Sun, 3 Nov 2013 03:22:21 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 52BEC284D; Sun, 3 Nov 2013 03:22:21 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id ld13so3781195vcb.5 for ; Sat, 02 Nov 2013 20:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=/v+7IEryTuWSNaT5MXvVcdpiMlmiBAI958uhdhRl84A=; b=mVspGHshDB20l8f+RpTdwMpkwH/jKQMMbB/dvWCqRAWT1J9D08Iiuyyw/FGHuA5Ybm Q7Mf3pXuLSPviEKDPt4bfrR2+LylXwozqa2J23s4+OQgCGf5b3rENUOxRCQ+ouJH2LnA m+n+0XGiX4cFIQxOGwdp21N13C7oenYtA2iI29upPiK3G8igKEgx2wpBdG4Q95aNmMjZ 27BjOM3IJnE6C5tgXgKoB7r4VHtDoWmh92sUPTqSWCM31sGUo8/pOebALqn/LApQXk4z AoIJGMc7BVSvGx6HsRiPNWATl4NFQd0A+oAd/LeyegikUHZvheAXFEwvN2Dr+A3ccIs3 PVzg== MIME-Version: 1.0 X-Received: by 10.220.184.70 with SMTP id cj6mr1461044vcb.23.1383448939996; Sat, 02 Nov 2013 20:22:19 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.221.9.2 with HTTP; Sat, 2 Nov 2013 20:22:19 -0700 (PDT) Date: Sat, 2 Nov 2013 20:22:19 -0700 X-Google-Sender-Auth: ALZlonwybfmhgWGXaPYz6AJI_cQ Message-ID: Subject: Can't mount root from raidz2 after r255763 in stable/9 From: Artem Belevich To: fs@freebsd.org, "stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 03:22:21 -0000 Hi, I have a box with root mounted from 8-disk raidz2 ZFS volume. After recent buildworld I've ran into an issue that kernel fails to mount root with error 6. r255763 on stable/9 is the first revision that fails to mount root on mybox. Preceding r255749 boots fine. Commit r255763 (http://svnweb.freebsd.org/base?view=revision&revision=255763) MFCs bunch of changes from 10 but I don't see anything that obviously impacts ZFS. Attempting to boot with vfs.zfs.debug=1 shows that order in which geom providers are probed by zfs has apparently changed. Kernels that boot, show "guid match for provider /dev/gpt/" while failing kernels show "guid match for provider /dev/daX" -- the raw disks that are *not* the right geom provider for my pool slices. Beats me why ZFS picks raw disks over GPT partitions it should have. Pool configuration: #zpool status z0 pool: z0 state: ONLINE scan: scrub repaired 0 in 8h57m with 0 errors on Sat Oct 19 20:23:52 2013 config: NAME STATE READ WRITE CKSUM z0 ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 gpt/da0p4-z0 ONLINE 0 0 0 gpt/da1p4-z0 ONLINE 0 0 0 gpt/da2p4-z0 ONLINE 0 0 0 gpt/da3p4-z0 ONLINE 0 0 0 gpt/da4p4-z0 ONLINE 0 0 0 gpt/da5p4-z0 ONLINE 0 0 0 gpt/da6p4-z0 ONLINE 0 0 0 gpt/da7p4-z0 ONLINE 0 0 0 logs mirror-1 ONLINE 0 0 0 gpt/ssd-zil-z0 ONLINE 0 0 0 gpt/ssd1-zil-z0 ONLINE 0 0 0 cache gpt/ssd1-l2arc-z0 ONLINE 0 0 0 errors: No known data errors Here are screen captures from a failed boot: https://plus.google.com/photos/+ArtemBelevich/albums/5941857781891332785 And here's boot log from successful boot on the same system: http://pastebin.com/XCwebsh7 Removing ZIL and L2ARC makes no difference -- r255763 still fails to mount root. I'm thoroughly baffled. Is there's something wrong with the pool -- some junk metadata somewhere on the disk that now screws with the root mounting? Changed order in geom provider enumeration? Something else? Any suggestions on what I can do to debug this further? --Artem From owner-freebsd-fs@FreeBSD.ORG Sun Nov 3 08:03:23 2013 Return-Path: Delivered-To: fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7F40A3F4; Sun, 3 Nov 2013 08:03:23 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 45B482284; Sun, 3 Nov 2013 08:03:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA00333; Sun, 03 Nov 2013 10:03:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VcseT-0001oz-40; Sun, 03 Nov 2013 10:03:17 +0200 Message-ID: <5276030E.5040100@FreeBSD.org> Date: Sun, 03 Nov 2013 10:02:22 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Artem Belevich , fs@FreeBSD.org, "stable@freebsd.org" Subject: Re: Can't mount root from raidz2 after r255763 in stable/9 References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 08:03:23 -0000 on 03/11/2013 05:22 Artem Belevich said the following: > Hi, > > I have a box with root mounted from 8-disk raidz2 ZFS volume. > After recent buildworld I've ran into an issue that kernel fails to > mount root with error 6. > r255763 on stable/9 is the first revision that fails to mount root on > mybox. Preceding r255749 boots fine. > > Commit r255763 (http://svnweb.freebsd.org/base?view=revision&revision=255763) > MFCs bunch of changes from 10 but I don't see anything that obviously > impacts ZFS. Indeed. > Attempting to boot with vfs.zfs.debug=1 shows that order in which geom > providers are probed by zfs has apparently changed. Kernels that boot, > show "guid match for provider /dev/gpt/" while > failing kernels show "guid match for provider /dev/daX" -- the raw > disks that are *not* the right geom provider for my pool slices. Beats > me why ZFS picks raw disks over GPT partitions it should have. Perhaps the kernel gpart code fails to recognize the partitions and thus ZFS can't see them? > Pool configuration: > #zpool status z0 > pool: z0 > state: ONLINE > scan: scrub repaired 0 in 8h57m with 0 errors on Sat Oct 19 20:23:52 2013 > config: > > NAME STATE READ WRITE CKSUM > z0 ONLINE 0 0 0 > raidz2-0 ONLINE 0 0 0 > gpt/da0p4-z0 ONLINE 0 0 0 > gpt/da1p4-z0 ONLINE 0 0 0 > gpt/da2p4-z0 ONLINE 0 0 0 > gpt/da3p4-z0 ONLINE 0 0 0 > gpt/da4p4-z0 ONLINE 0 0 0 > gpt/da5p4-z0 ONLINE 0 0 0 > gpt/da6p4-z0 ONLINE 0 0 0 > gpt/da7p4-z0 ONLINE 0 0 0 > logs > mirror-1 ONLINE 0 0 0 > gpt/ssd-zil-z0 ONLINE 0 0 0 > gpt/ssd1-zil-z0 ONLINE 0 0 0 > cache > gpt/ssd1-l2arc-z0 ONLINE 0 0 0 > > errors: No known data errors > > Here are screen captures from a failed boot: > https://plus.google.com/photos/+ArtemBelevich/albums/5941857781891332785 I don't have permission to view this album. > And here's boot log from successful boot on the same system: > http://pastebin.com/XCwebsh7 > > Removing ZIL and L2ARC makes no difference -- r255763 still fails to mount root. > > I'm thoroughly baffled. Is there's something wrong with the pool -- > some junk metadata somewhere on the disk that now screws with the root > mounting? Changed order in geom provider enumeration? Something else? > Any suggestions on what I can do to debug this further? gpart. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Sun Nov 3 16:57:10 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0D45DC7; Sun, 3 Nov 2013 16:57:10 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7C4E92756; Sun, 3 Nov 2013 16:57:10 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id lh4so4138168vcb.32 for ; Sun, 03 Nov 2013 08:57:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HLzOy22XTehLapNhcuUAjHZoKvV2y2VC3uJ4IoUf8NA=; b=RBzJ6zWpR7fU7ap4h3nWJ721m1mbxdTGQ3IRSQxJWh/2iwuOsRKOLVg7X0yGJFCdLQ EN5Y7WS9JGGNLCBlW5E424WxepgUOpx7360fFr/o0HJUVCecCZ5WFDkNVQiBCb0rCCet ncd4gzsmNvTfr+m28Etmorz5mHy++Hl6qPPthlhBGq6+uZpKvL3uIKKuQXlhpQqdAkEc 8j8RmwQXqaGql+ky1Xj1elqqqeT4lc8tYd2pBry5XzfBdFCNnActXAmpnjgUouCQQJnb NWpUhdht4gJpSYhfdMVjOq5t4DkkeFJvwd1LN2Y6whpBH5fZ8F349mIBCEbrM2fkueOW wejQ== MIME-Version: 1.0 X-Received: by 10.52.230.202 with SMTP id ta10mr25582vdc.41.1383497829542; Sun, 03 Nov 2013 08:57:09 -0800 (PST) Sender: artemb@gmail.com Received: by 10.221.9.2 with HTTP; Sun, 3 Nov 2013 08:57:09 -0800 (PST) In-Reply-To: <5276030E.5040100@FreeBSD.org> References: <5276030E.5040100@FreeBSD.org> Date: Sun, 3 Nov 2013 08:57:09 -0800 X-Google-Sender-Auth: iq9FehKtcph_4Wxfmd_-UJ_AA2M Message-ID: Subject: Re: Can't mount root from raidz2 after r255763 in stable/9 From: Artem Belevich To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: "stable@freebsd.org" , fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 16:57:11 -0000 TL;DR; version -- Solved. The failure was caused by zombie ZFS volume labels from the previous life of the disks in another pool. For some reason kernel picks labels from the raw device first now and tries to boot from the pool that does not exist. Nuking old labels with dd solved my booting issues. On Sun, Nov 3, 2013 at 1:02 AM, Andriy Gapon wrote: > on 03/11/2013 05:22 Artem Belevich said the following: >> Hi, >> >> I have a box with root mounted from 8-disk raidz2 ZFS volume. >> After recent buildworld I've ran into an issue that kernel fails to >> mount root with error 6. >> r255763 on stable/9 is the first revision that fails to mount root on >> mybox. Preceding r255749 boots fine. >> >> Commit r255763 (http://svnweb.freebsd.org/base?view=revision&revision=255763) >> MFCs bunch of changes from 10 but I don't see anything that obviously >> impacts ZFS. > > Indeed. > >> Attempting to boot with vfs.zfs.debug=1 shows that order in which geom >> providers are probed by zfs has apparently changed. Kernels that boot, >> show "guid match for provider /dev/gpt/" while >> failing kernels show "guid match for provider /dev/daX" -- the raw >> disks that are *not* the right geom provider for my pool slices. Beats >> me why ZFS picks raw disks over GPT partitions it should have. > > Perhaps the kernel gpart code fails to recognize the partitions and thus ZFS > can't see them? > >> Pool configuration: >> #zpool status z0 >> pool: z0 >> state: ONLINE >> scan: scrub repaired 0 in 8h57m with 0 errors on Sat Oct 19 20:23:52 2013 >> config: >> >> NAME STATE READ WRITE CKSUM >> z0 ONLINE 0 0 0 >> raidz2-0 ONLINE 0 0 0 >> gpt/da0p4-z0 ONLINE 0 0 0 >> gpt/da1p4-z0 ONLINE 0 0 0 >> gpt/da2p4-z0 ONLINE 0 0 0 >> gpt/da3p4-z0 ONLINE 0 0 0 >> gpt/da4p4-z0 ONLINE 0 0 0 >> gpt/da5p4-z0 ONLINE 0 0 0 >> gpt/da6p4-z0 ONLINE 0 0 0 >> gpt/da7p4-z0 ONLINE 0 0 0 >> logs >> mirror-1 ONLINE 0 0 0 >> gpt/ssd-zil-z0 ONLINE 0 0 0 >> gpt/ssd1-zil-z0 ONLINE 0 0 0 >> cache >> gpt/ssd1-l2arc-z0 ONLINE 0 0 0 >> >> errors: No known data errors >> >> Here are screen captures from a failed boot: >> https://plus.google.com/photos/+ArtemBelevich/albums/5941857781891332785 > > I don't have permission to view this album. Argh. Copy-paste error. Try these : https://plus.google.com/photos/101142993171487001774/albums/5941857781891332785?authkey=CPm-4YnarsXhKg https://plus.google.com/photos/+ArtemBelevich/albums/5941857781891332785?authkey=CPm-4YnarsXhKg > >> And here's boot log from successful boot on the same system: >> http://pastebin.com/XCwebsh7 >> >> Removing ZIL and L2ARC makes no difference -- r255763 still fails to mount root. >> >> I'm thoroughly baffled. Is there's something wrong with the pool -- >> some junk metadata somewhere on the disk that now screws with the root >> mounting? Changed order in geom provider enumeration? Something else? >> Any suggestions on what I can do to debug this further? > > gpart. Long version of the story: It was stale metadata after all. 'zdb -l /dev/daN' showed that one of the four pool labels was still found on every drive in the pool. Long ago the drives were temporarily used as raw drives in a ZFS pool on a test box. Then I destroyed the pool, sliced them into partitions with GPT and used one of partitions to build current pool. Apparently not all old pool labels were overwritten by the new pool, but by accident that went unnoticed until now because new pool was detected first. Now detection order has changed (I'm still not sure how or why) and that resurrected the old non-existing pool and caused boot failures. After finding location of volume labels on the disk and nuking them with dd boot issues went away. The scary part was that the label was *inside* the current pool slice so I had to corrupt current pool data. I figured that considering that label is still alive, current pool didn't write anything there yet and therefore it should be safe to overwrite the label. I first did it on one drive only. In case I was wrong, ZFS should have been able to rebuild the pool. Lucky for me no vital data was hurt in the process and zfs scrub reported zero errors. After nuking old labels on other drives, boot issues went away. Even though my problem has been dealt with, I still wonder whether pool detection should be more robust. I've been lucky that it was kernel that changed pool detection and not the bootloader. It would've made troubleshooting even more interesting. Would it make sense to prefer partitions over whole drives? Or, perhaps prefer pools with all the labels intact over devices that only have small fraction of valid labels? --Artem From owner-freebsd-fs@FreeBSD.ORG Mon Nov 4 11:06:48 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A175F61C for ; Mon, 4 Nov 2013 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E6BA2C30 for ; Mon, 4 Nov 2013 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA4B6meX048369 for ; Mon, 4 Nov 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA4B6m7p048367 for freebsd-fs@FreeBSD.org; Mon, 4 Nov 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Nov 2013 11:06:48 GMT Message-Id: <201311041106.rA4B6m7p048367@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-fs@FreeBSD.org Subject: Current problem reports assigned to freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/182570 fs [zfs] [patch] ZFS panic in receive o kern/182536 fs [zfs] zfs deadlock o kern/181966 fs [zfs] Kernel panic in ZFS I/O: solaris assert: BP_EQUA o kern/181834 fs [nfs] amd mounting NFS directories can drive a dead-lo o kern/181565 fs [swap] Problem with vnode-backed swap space. o kern/181377 fs [zfs] zfs recv causes an inconsistant pool o kern/181281 fs [msdosfs] stack trace after successfull 'umount /mnt' o kern/181082 fs [fuse] [ntfs] Write to mounted NTFS filesystem using F o kern/180979 fs [netsmb][patch]: Fix large files handling o kern/180876 fs [zfs] [hast] ZFS with trim,bio_flush or bio_delete loc o kern/180678 fs [NFS] succesfully exported filesystems being reported o kern/180438 fs [smbfs] [patch] mount_smbfs fails on arm because of wr p kern/180236 fs [zfs] [nullfs] Leakage free space using ZFS with nullf o kern/178854 fs [ufs] FreeBSD kernel crash in UFS s kern/178467 fs [zfs] [request] Optimized Checksum Code for ZFS o kern/178412 fs [smbfs] Coredump when smbfs mounted o kern/178388 fs [zfs] [patch] allow up to 8MB recordsize o kern/178387 fs [zfs] [patch] sparse files performance improvements o kern/178349 fs [zfs] zfs scrub on deduped data could be much less see o kern/178329 fs [zfs] extended attributes leak o kern/178238 fs [nullfs] nullfs don't release i-nodes on unlink. f kern/178231 fs [nfs] 8.3 nfsv4 client reports "nfsv4 client/server pr o kern/177985 fs [zfs] disk usage problem when copying from one zfs dat o kern/177971 fs [nfs] FreeBSD 9.1 nfs client dirlist problem w/ nfsv3, o kern/177966 fs [zfs] resilver completes but subsequent scrub reports o kern/177658 fs [ufs] FreeBSD panics after get full filesystem with uf o kern/177536 fs [zfs] zfs livelock (deadlock) with high write-to-disk o kern/177445 fs [hast] HAST panic o kern/177240 fs [zfs] zpool import failed with state UNAVAIL but all d o kern/176978 fs [zfs] [panic] zfs send -D causes "panic: System call i o kern/176857 fs [softupdates] [panic] 9.1-RELEASE/amd64/GENERIC panic o bin/176253 fs zpool(8): zfs pool indentation is misleading/wrong o kern/176141 fs [zfs] sharesmb=on makes errors for sharenfs, and still o kern/175950 fs [zfs] Possible deadlock in zfs after long uptime o kern/175897 fs [zfs] operations on readonly zpool hang o kern/175449 fs [unionfs] unionfs and devfs misbehaviour o kern/175179 fs [zfs] ZFS may attach wrong device on move o kern/175071 fs [ufs] [panic] softdep_deallocate_dependencies: unrecov o kern/174372 fs [zfs] Pagefault appears to be related to ZFS o kern/174315 fs [zfs] chflags uchg not supported o kern/174310 fs [zfs] root point mounting broken on CURRENT with multi o kern/174279 fs [ufs] UFS2-SU+J journal and filesystem corruption o kern/173830 fs [zfs] Brain-dead simple change to ZFS error descriptio o kern/173718 fs [zfs] phantom directory in zraid2 pool f kern/173657 fs [nfs] strange UID map with nfsuserd o kern/173363 fs [zfs] [panic] Panic on 'zpool replace' on readonly poo o kern/173136 fs [unionfs] mounting above the NFS read-only share panic o kern/172942 fs [smbfs] Unmounting a smb mount when the server became o kern/172348 fs [unionfs] umount -f of filesystem in use with readonly o kern/172334 fs [unionfs] unionfs permits recursive union mounts; caus o kern/171626 fs [tmpfs] tmpfs should be noisier when the requested siz o kern/171415 fs [zfs] zfs recv fails with "cannot receive incremental o kern/170945 fs [gpt] disk layout not portable between direct connect o bin/170778 fs [zfs] [panic] FreeBSD panics randomly o kern/170680 fs [nfs] Multiple NFS Client bug in the FreeBSD 7.4-RELEA o kern/170497 fs [xfs][panic] kernel will panic whenever I ls a mounted o kern/169945 fs [zfs] [panic] Kernel panic while importing zpool (afte o kern/169480 fs [zfs] ZFS stalls on heavy I/O o kern/169398 fs [zfs] Can't remove file with permanent error o kern/169339 fs panic while " : > /etc/123" o kern/169319 fs [zfs] zfs resilver can't complete o kern/168947 fs [nfs] [zfs] .zfs/snapshot directory is messed up when o kern/168942 fs [nfs] [hang] nfsd hangs after being restarted (not -HU o kern/168158 fs [zfs] incorrect parsing of sharenfs options in zfs (fs o kern/167979 fs [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste o kern/167977 fs [smbfs] mount_smbfs results are differ when utf-8 or U o kern/167688 fs [fusefs] Incorrect signal handling with direct_io o kern/167685 fs [zfs] ZFS on USB drive prevents shutdown / reboot o kern/167612 fs [portalfs] The portal file system gets stuck inside po o kern/167272 fs [zfs] ZFS Disks reordering causes ZFS to pick the wron o kern/167260 fs [msdosfs] msdosfs disk was mounted the second time whe o kern/167109 fs [zfs] [panic] zfs diff kernel panic Fatal trap 9: gene o kern/167105 fs [nfs] mount_nfs can not handle source exports wiht mor o kern/167067 fs [zfs] [panic] ZFS panics the server o kern/167065 fs [zfs] boot fails when a spare is the boot disk o kern/167048 fs [nfs] [patch] RELEASE-9 crash when using ZFS+NULLFS+NF o kern/166912 fs [ufs] [panic] Panic after converting Softupdates to jo o kern/166851 fs [zfs] [hang] Copying directory from the mounted UFS di o kern/166477 fs [nfs] NFS data corruption. o kern/165950 fs [ffs] SU+J and fsck problem o kern/165521 fs [zfs] [hang] livelock on 1 Gig of RAM with zfs when 31 o kern/165392 fs Multiple mkdir/rmdir fails with errno 31 o kern/165087 fs [unionfs] lock violation in unionfs o kern/164472 fs [ufs] fsck -B panics on particular data inconsistency o kern/164370 fs [zfs] zfs destroy for snapshot fails on i386 and sparc o kern/164261 fs [nullfs] [patch] fix panic with NFS served from NULLFS o kern/164256 fs [zfs] device entry for volume is not created after zfs o kern/164184 fs [ufs] [panic] Kernel panic with ufs_makeinode o kern/163801 fs [md] [request] allow mfsBSD legacy installed in 'swap' o kern/163770 fs [zfs] [hang] LOR between zfs&syncer + vnlru leading to o kern/163501 fs [nfs] NFS exporting a dir and a subdir in that dir to o kern/162944 fs [coda] Coda file system module looks broken in 9.0 o kern/162860 fs [zfs] Cannot share ZFS filesystem to hosts with a hyph o kern/162751 fs [zfs] [panic] kernel panics during file operations o kern/162591 fs [nullfs] cross-filesystem nullfs does not work as expe o kern/162519 fs [zfs] "zpool import" relies on buggy realpath() behavi o kern/161968 fs [zfs] [hang] renaming snapshot with -r including a zvo o kern/161864 fs [ufs] removing journaling from UFS partition fails on o kern/161579 fs [smbfs] FreeBSD sometimes panics when an smb share is o kern/161533 fs [zfs] [panic] zfs receive panic: system ioctl returnin o kern/161438 fs [zfs] [panic] recursed on non-recursive spa_namespace_ o kern/161424 fs [nullfs] __getcwd() calls fail when used on nullfs mou o kern/161280 fs [zfs] Stack overflow in gptzfsboot o kern/161205 fs [nfs] [pfsync] [regression] [build] Bug report freebsd o kern/161169 fs [zfs] [panic] ZFS causes kernel panic in dbuf_dirty o kern/161112 fs [ufs] [lor] filesystem LOR in FreeBSD 9.0-BETA3 o kern/160893 fs [zfs] [panic] 9.0-BETA2 kernel panic f kern/160860 fs [ufs] Random UFS root filesystem corruption with SU+J o kern/160801 fs [zfs] zfsboot on 8.2-RELEASE fails to boot from root-o o kern/160790 fs [fusefs] [panic] VPUTX: negative ref count with FUSE o kern/160777 fs [zfs] [hang] RAID-Z3 causes fatal hang upon scrub/impo o kern/160706 fs [zfs] zfs bootloader fails when a non-root vdev exists o kern/160591 fs [zfs] Fail to boot on zfs root with degraded raidz2 [r o kern/160410 fs [smbfs] [hang] smbfs hangs when transferring large fil o kern/160283 fs [zfs] [patch] 'zfs list' does abort in make_dataset_ha o kern/159930 fs [ufs] [panic] kernel core o kern/159402 fs [zfs][loader] symlinks cause I/O errors o kern/159357 fs [zfs] ZFS MAXNAMELEN macro has confusing name (off-by- o kern/159356 fs [zfs] [patch] ZFS NAME_ERR_DISKLIKE check is Solaris-s o kern/159351 fs [nfs] [patch] - divide by zero in mountnfs() o kern/159251 fs [zfs] [request]: add FLETCHER4 as DEDUP hash option o kern/159077 fs [zfs] Can't cd .. with latest zfs version o kern/159048 fs [smbfs] smb mount corrupts large files o kern/159045 fs [zfs] [hang] ZFS scrub freezes system o kern/158839 fs [zfs] ZFS Bootloader Fails if there is a Dead Disk o kern/158802 fs amd(8) ICMP storm and unkillable process. o kern/158231 fs [nullfs] panic on unmounting nullfs mounted over ufs o f kern/157929 fs [nfs] NFS slow read o kern/157399 fs [zfs] trouble with: mdconfig force delete && zfs strip o kern/157179 fs [zfs] zfs/dbuf.c: panic: solaris assert: arc_buf_remov o kern/156797 fs [zfs] [panic] Double panic with FreeBSD 9-CURRENT and o kern/156781 fs [zfs] zfs is losing the snapshot directory, p kern/156545 fs [ufs] mv could break UFS on SMP systems o kern/156193 fs [ufs] [hang] UFS snapshot hangs && deadlocks processes o kern/156039 fs [nullfs] [unionfs] nullfs + unionfs do not compose, re o kern/155615 fs [zfs] zfs v28 broken on sparc64 -current o kern/155587 fs [zfs] [panic] kernel panic with zfs p kern/155411 fs [regression] [8.2-release] [tmpfs]: mount: tmpfs : No o kern/155199 fs [ext2fs] ext3fs mounted as ext2fs gives I/O errors o bin/155104 fs [zfs][patch] use /dev prefix by default when importing o kern/154930 fs [zfs] cannot delete/unlink file from full volume -> EN o kern/154828 fs [msdosfs] Unable to create directories on external USB o kern/154491 fs [smbfs] smb_co_lock: recursive lock for object 1 p kern/154228 fs [md] md getting stuck in wdrain state o kern/153996 fs [zfs] zfs root mount error while kernel is not located o kern/153753 fs [zfs] ZFS v15 - grammatical error when attempting to u o kern/153716 fs [zfs] zpool scrub time remaining is incorrect o kern/153695 fs [patch] [zfs] Booting from zpool created on 4k-sector o kern/153680 fs [xfs] 8.1 failing to mount XFS partitions o kern/153418 fs [zfs] [panic] Kernel Panic occurred writing to zfs vol o kern/153351 fs [zfs] locking directories/files in ZFS o bin/153258 fs [patch][zfs] creating ZVOLs requires `refreservation' s kern/153173 fs [zfs] booting from a gzip-compressed dataset doesn't w o bin/153142 fs [zfs] ls -l outputs `ls: ./.zfs: Operation not support o kern/153126 fs [zfs] vdev failure, zpool=peegel type=vdev.too_small o kern/152022 fs [nfs] nfs service hangs with linux client [regression] o kern/151942 fs [zfs] panic during ls(1) zfs snapshot directory o kern/151905 fs [zfs] page fault under load in /sbin/zfs o bin/151713 fs [patch] Bug in growfs(8) with respect to 32-bit overfl o kern/151648 fs [zfs] disk wait bug o kern/151629 fs [fs] [patch] Skip empty directory entries during name o kern/151330 fs [zfs] will unshare all zfs filesystem after execute a o kern/151326 fs [nfs] nfs exports fail if netgroups contain duplicate o kern/151251 fs [ufs] Can not create files on filesystem with heavy us o kern/151226 fs [zfs] can't delete zfs snapshot o kern/150503 fs [zfs] ZFS disks are UNAVAIL and corrupted after reboot o kern/150501 fs [zfs] ZFS vdev failure vdev.bad_label on amd64 o kern/150390 fs [zfs] zfs deadlock when arcmsr reports drive faulted o kern/150336 fs [nfs] mountd/nfsd became confused; refused to reload n o kern/149208 fs mksnap_ffs(8) hang/deadlock o kern/149173 fs [patch] [zfs] make OpenSolaris installa o kern/149015 fs [zfs] [patch] misc fixes for ZFS code to build on Glib o kern/149014 fs [zfs] [patch] declarations in ZFS libraries/utilities o kern/149013 fs [zfs] [patch] make ZFS makefiles use the libraries fro o kern/148504 fs [zfs] ZFS' zpool does not allow replacing drives to be o kern/148490 fs [zfs]: zpool attach - resilver bidirectionally, and re o kern/148368 fs [zfs] ZFS hanging forever on 8.1-PRERELEASE o kern/148138 fs [zfs] zfs raidz pool commands freeze o kern/147903 fs [zfs] [panic] Kernel panics on faulty zfs device o kern/147881 fs [zfs] [patch] ZFS "sharenfs" doesn't allow different " o kern/147420 fs [ufs] [panic] ufs_dirbad, nullfs, jail panic (corrupt o kern/146941 fs [zfs] [panic] Kernel Double Fault - Happens constantly o kern/146786 fs [zfs] zpool import hangs with checksum errors o kern/146708 fs [ufs] [panic] Kernel panic in softdep_disk_write_compl o kern/146528 fs [zfs] Severe memory leak in ZFS on i386 o kern/146502 fs [nfs] FreeBSD 8 NFS Client Connection to Server o kern/145750 fs [unionfs] [hang] unionfs locks the machine s kern/145712 fs [zfs] cannot offline two drives in a raidz2 configurat o kern/145411 fs [xfs] [panic] Kernel panics shortly after mounting an f bin/145309 fs bsdlabel: Editing disk label invalidates the whole dev o kern/145272 fs [zfs] [panic] Panic during boot when accessing zfs on o kern/145246 fs [ufs] dirhash in 7.3 gratuitously frees hashes when it o kern/145238 fs [zfs] [panic] kernel panic on zpool clear tank o kern/145229 fs [zfs] Vast differences in ZFS ARC behavior between 8.0 o kern/145189 fs [nfs] nfsd performs abysmally under load o kern/144929 fs [ufs] [lor] vfs_bio.c + ufs_dirhash.c p kern/144447 fs [zfs] sharenfs fsunshare() & fsshare_main() non functi o kern/144416 fs [panic] Kernel panic on online filesystem optimization s kern/144415 fs [zfs] [panic] kernel panics on boot after zfs crash o kern/144234 fs [zfs] Cannot boot machine with recent gptzfsboot code o kern/143825 fs [nfs] [panic] Kernel panic on NFS client o bin/143572 fs [zfs] zpool(1): [patch] The verbose output from iostat o kern/143212 fs [nfs] NFSv4 client strange work ... o kern/143184 fs [zfs] [lor] zfs/bufwait LOR o kern/142878 fs [zfs] [vfs] lock order reversal o kern/142597 fs [ext2fs] ext2fs does not work on filesystems with real o kern/142489 fs [zfs] [lor] allproc/zfs LOR o kern/142466 fs Update 7.2 -> 8.0 on Raid 1 ends with screwed raid [re o kern/142306 fs [zfs] [panic] ZFS drive (from OSX Leopard) causes two o kern/142068 fs [ufs] BSD labels are got deleted spontaneously o kern/141950 fs [unionfs] [lor] ufs/unionfs/ufs Lock order reversal o kern/141897 fs [msdosfs] [panic] Kernel panic. msdofs: file name leng o kern/141463 fs [nfs] [panic] Frequent kernel panics after upgrade fro o kern/141091 fs [patch] [nullfs] fix panics with DIAGNOSTIC enabled o kern/141086 fs [nfs] [panic] panic("nfs: bioread, not dir") on FreeBS o kern/141010 fs [zfs] "zfs scrub" fails when backed by files in UFS2 o kern/140888 fs [zfs] boot fail from zfs root while the pool resilveri o kern/140661 fs [zfs] [patch] /boot/loader fails to work on a GPT/ZFS- o kern/140640 fs [zfs] snapshot crash o kern/140068 fs [smbfs] [patch] smbfs does not allow semicolon in file o kern/139725 fs [zfs] zdb(1) dumps core on i386 when examining zpool c o kern/139715 fs [zfs] vfs.numvnodes leak on busy zfs p bin/139651 fs [nfs] mount(8): read-only remount of NFS volume does n o kern/139407 fs [smbfs] [panic] smb mount causes system crash if remot o kern/138662 fs [panic] ffs_blkfree: freeing free block o kern/138421 fs [ufs] [patch] remove UFS label limitations o kern/138202 fs mount_msdosfs(1) see only 2Gb o kern/137588 fs [unionfs] [lor] LOR nfs/ufs/nfs o kern/136968 fs [ufs] [lor] ufs/bufwait/ufs (open) o kern/136945 fs [ufs] [lor] filedesc structure/ufs (poll) o kern/136944 fs [ffs] [lor] bufwait/snaplk (fsync) o kern/136873 fs [ntfs] Missing directories/files on NTFS volume p kern/136470 fs [nfs] Cannot mount / in read-only, over NFS o kern/135546 fs [zfs] zfs.ko module doesn't ignore zpool.cache filenam o kern/135469 fs [ufs] [panic] kernel crash on md operation in ufs_dirb o kern/135050 fs [zfs] ZFS clears/hides disk errors on reboot o kern/134491 fs [zfs] Hot spares are rather cold... o kern/133676 fs [smbfs] [panic] umount -f'ing a vnode-based memory dis p kern/133174 fs [msdosfs] [patch] msdosfs must support multibyte inter o kern/132960 fs [ufs] [panic] panic:ffs_blkfree: freeing free frag o kern/132397 fs reboot causes filesystem corruption (failure to sync b o kern/132331 fs [ufs] [lor] LOR ufs and syncer o kern/132237 fs [msdosfs] msdosfs has problems to read MSDOS Floppy o kern/132145 fs [panic] File System Hard Crashes o kern/131441 fs [unionfs] [nullfs] unionfs and/or nullfs not combineab o kern/131360 fs [nfs] poor scaling behavior of the NFS server under lo o kern/131342 fs [nfs] mounting/unmounting of disks causes NFS to fail o bin/131341 fs makefs: error "Bad file descriptor" on the mount poin o kern/130920 fs [msdosfs] cp(1) takes 100% CPU time while copying file o kern/130210 fs [nullfs] Error by check nullfs o kern/129760 fs [nfs] after 'umount -f' of a stale NFS share FreeBSD l o kern/129488 fs [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o kern/129231 fs [ufs] [patch] New UFS mount (norandom) option - mostly o kern/129152 fs [panic] non-userfriendly panic when trying to mount(8) o kern/127787 fs [lor] [ufs] Three LORs: vfslock/devfs/vfslock, ufs/vfs o bin/127270 fs fsck_msdosfs(8) may crash if BytesPerSec is zero o kern/127029 fs [panic] mount(8): trying to mount a write protected zi o kern/126973 fs [unionfs] [hang] System hang with unionfs and init chr o kern/126553 fs [unionfs] unionfs move directory problem 2 (files appe o kern/126287 fs [ufs] [panic] Kernel panics while mounting an UFS file o kern/125895 fs [ffs] [panic] kernel: panic: ffs_blkfree: freeing free s kern/125738 fs [zfs] [request] SHA256 acceleration in ZFS o kern/123939 fs [msdosfs] corrupts new files o bin/123574 fs [unionfs] df(1) -t option destroys info for unionfs (a o kern/122380 fs [ffs] ffs_valloc:dup alloc (Soekris 4801/7.0/USB Flash o bin/122172 fs [fs]: amd(8) automount daemon dies on 6.3-STABLE i386, o bin/121898 fs [nullfs] pwd(1)/getcwd(2) fails with Permission denied o kern/121385 fs [unionfs] unionfs cross mount -> kernel panic o bin/121072 fs [smbfs] mount_smbfs(8) cannot normally convert the cha o kern/120483 fs [ntfs] [patch] NTFS filesystem locking changes o kern/120482 fs [ntfs] [patch] Sync style changes between NetBSD and F o kern/118912 fs [2tb] disk sizing/geometry problem with large array o kern/118713 fs [minidump] [patch] Display media size required for a k o kern/118318 fs [nfs] NFS server hangs under special circumstances o bin/118249 fs [ufs] mv(1): moving a directory changes its mtime o kern/118126 fs [nfs] [patch] Poor NFS server write performance o kern/118107 fs [ntfs] [panic] Kernel panic when accessing a file at N o kern/117954 fs [ufs] dirhash on very large directories blocks the mac o bin/117315 fs [smbfs] mount_smbfs(8) and related options can't mount o kern/117158 fs [zfs] zpool scrub causes panic if geli vdevs detach on o bin/116980 fs [msdosfs] [patch] mount_msdosfs(8) resets some flags f o conf/116931 fs lack of fsck_cd9660 prevents mounting iso images with o kern/116583 fs [ffs] [hang] System freezes for short time when using o bin/115361 fs [zfs] mount(8) gets into a state where it won't set/un o kern/114955 fs [cd9660] [patch] [request] support for mask,dirmask,ui o kern/114847 fs [ntfs] [patch] [request] dirmask support for NTFS ala o kern/114676 fs [ufs] snapshot creation panics: snapacct_ufs2: bad blo o bin/114468 fs [patch] [request] add -d option to umount(8) to detach o kern/113852 fs [smbfs] smbfs does not properly implement DFS referral o bin/113838 fs [patch] [request] mount(8): add support for relative p o bin/113049 fs [patch] [request] make quot(8) use getopt(3) and show o kern/112658 fs [smbfs] [patch] smbfs and caching problems (resolves b o kern/111843 fs [msdosfs] Long Names of files are incorrectly created o kern/111782 fs [ufs] dump(8) fails horribly for large filesystems s bin/111146 fs [2tb] fsck(8) fails on 6T filesystem o bin/107829 fs [2TB] fdisk(8): invalid boundary checking in fdisk / w o kern/106107 fs [ufs] left-over fsck_snapshot after unfinished backgro o kern/104406 fs [ufs] Processes get stuck in "ufs" state under persist o kern/104133 fs [ext2fs] EXT2FS module corrupts EXT2/3 filesystems o kern/103035 fs [ntfs] Directories in NTFS mounted disc images appear o kern/101324 fs [smbfs] smbfs sometimes not case sensitive when it's s o kern/99290 fs [ntfs] mount_ntfs ignorant of cluster sizes s bin/97498 fs [request] newfs(8) has no option to clear the first 12 o kern/97377 fs [ntfs] [patch] syntax cleanup for ntfs_ihash.c o kern/95222 fs [cd9660] File sections on ISO9660 level 3 CDs ignored o kern/94849 fs [ufs] rename on UFS filesystem is not atomic o bin/94810 fs fsck(8) incorrectly reports 'file system marked clean' o kern/94769 fs [ufs] Multiple file deletions on multi-snapshotted fil o kern/94733 fs [smbfs] smbfs may cause double unlock o kern/93942 fs [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D o kern/92272 fs [ffs] [hang] Filling a filesystem while creating a sna o kern/91134 fs [smbfs] [patch] Preserve access and modification time a kern/90815 fs [smbfs] [patch] SMBFS with character conversions somet o kern/88657 fs [smbfs] windows client hang when browsing a samba shar o kern/88555 fs [panic] ffs_blkfree: freeing free frag on AMD 64 o bin/87966 fs [patch] newfs(8): introduce -A flag for newfs to enabl o kern/87859 fs [smbfs] System reboot while umount smbfs. o kern/86587 fs [msdosfs] rm -r /PATH fails with lots of small files o bin/85494 fs fsck_ffs: unchecked use of cg_inosused macro etc. o kern/80088 fs [smbfs] Incorrect file time setting on NTFS mounted vi o bin/74779 fs Background-fsck checks one filesystem twice and omits o kern/73484 fs [ntfs] Kernel panic when doing `ls` from the client si o bin/73019 fs [ufs] fsck_ufs(8) cannot alloc 607016868 bytes for ino o kern/71774 fs [ntfs] NTFS cannot "see" files on a WinXP filesystem o bin/70600 fs fsck(8) throws files away when it can't grow lost+foun o kern/68978 fs [panic] [ufs] crashes with failing hard disk, loose po o kern/67326 fs [msdosfs] crash after attempt to mount write protected o kern/65920 fs [nwfs] Mounted Netware filesystem behaves strange o kern/65901 fs [smbfs] [patch] smbfs fails fsx write/truncate-down/tr o kern/61503 fs [smbfs] mount_smbfs does not work as non-root o kern/55617 fs [smbfs] Accessing an nsmb-mounted drive via a smb expo o kern/51685 fs [hang] Unbounded inode allocation causes kernel to loc o kern/36566 fs [smbfs] System reboot with dead smb mount and umount o bin/27687 fs fsck(8) wrapper is not properly passing options to fsc o kern/18874 fs [2TB] 32bit NFS servers export wrong negative values t o kern/9619 fs [nfs] Restarting mountd kills existing mounts 336 problems total. From owner-freebsd-fs@FreeBSD.ORG Tue Nov 5 12:31:18 2013 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 36E4A3DD for ; Tue, 5 Nov 2013 12:31:18 +0000 (UTC) (envelope-from Albert.Shih@obspm.fr) Received: from smtp-int-m.obspm.fr (smtp-int-m.obspm.fr [145.238.187.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C85BB238C for ; Tue, 5 Nov 2013 12:31:17 +0000 (UTC) Received: from pcjas.obspm.fr (pcjas.obspm.fr [145.238.184.233]) by smtp-int-m.obspm.fr (8.14.3/8.14.3/SIO Observatoire de Paris - 07/2009) with ESMTP id rA5CUS37022223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 5 Nov 2013 13:30:29 +0100 Date: Tue, 5 Nov 2013 13:30:28 +0100 From: Albert Shih To: freebsd-fs@FreeBSD.org Subject: mountd can't delete exports for Message-ID: <20131105123028.GA21794@pcjas.obspm.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.22 (2013-10-16) X-Miltered: at smtp-int-m.obspm.fr with ID 5278E4E4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5278E4E4.000/145.238.184.233/pcjas.obspm.fr/pcjas.obspm.fr/ X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 12:31:18 -0000 Hi, I've some very strange behavior since some day on my FreeBSD zfs nfs server. This server run FreeBSD 9.0 and everything (= nfs and backup server) works fine. But since some days I've got lot of message like Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Daily-2013-10-22: Invalid argument Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Daily-2013-10-10: Invalid argument Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Daily-2013-10-09: Invalid argument Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Daily-2013-10-17: Invalid argument Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Daily-2013-10-15: Invalid argument Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Daily-2013-10-06: Invalid argument Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Monthly-2013-10-01: Invalid argument Nov 5 13:12:49 filer1 mountd[76392]: can't delete exports for /filer1/sauvegardes/filer2/.zfs/snapshot/Daily-2013-10-20: Invalid argument I've do some google and don't find any solution. On this server I've got many zfs partition, only 4 are export through nfs, and none of this 4 have any snapshots. The rest of zfs partition who have snapshots aren't exported. Regards. -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex France Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71 xmpp: jas@obspm.fr Heure local/Local time: mar 5 nov 2013 13:25:26 CET From owner-freebsd-fs@FreeBSD.ORG Wed Nov 6 04:20:17 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5FFE54E; Wed, 6 Nov 2013 04:20:17 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BAEC92F59; Wed, 6 Nov 2013 04:20:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA64KHLU034818; Wed, 6 Nov 2013 04:20:17 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA64KHUH034817; Wed, 6 Nov 2013 04:20:17 GMT (envelope-from linimon) Date: Wed, 6 Nov 2013 04:20:17 GMT Message-Id: <201311060420.rA64KHUH034817@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-fs@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/183689: [lor] lock order reversal when umounting a ZFS disk. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 04:20:18 -0000 Old Synopsis: [lock order reversal] when umounting a ZFS disk. New Synopsis: [lor] lock order reversal when umounting a ZFS disk. Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 6 04:19:56 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=183689 From owner-freebsd-fs@FreeBSD.ORG Wed Nov 6 07:59:11 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 16473F60; Wed, 6 Nov 2013 07:59:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E14432942; Wed, 6 Nov 2013 07:59:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA67xAAk093415; Wed, 6 Nov 2013 07:59:10 GMT (envelope-from avg@freefall.freebsd.org) Received: (from avg@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA67x91L093412; Wed, 6 Nov 2013 07:59:09 GMT (envelope-from avg) Date: Wed, 6 Nov 2013 07:59:09 GMT Message-Id: <201311060759.rA67x91L093412@freefall.freebsd.org> To: eocallaghan@alterapraxis.com, avg@FreeBSD.org, freebsd-fs@FreeBSD.org From: avg@FreeBSD.org Subject: Re: kern/183689: [lor] lock order reversal when umounting a ZFS disk. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 07:59:11 -0000 Synopsis: [lor] lock order reversal when umounting a ZFS disk. State-Changed-From-To: open->closed State-Changed-By: avg State-Changed-When: Wed Nov 6 07:59:09 UTC 2013 State-Changed-Why: Not a problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=183689 From owner-freebsd-fs@FreeBSD.ORG Wed Nov 6 08:00:01 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D08C121 for ; Wed, 6 Nov 2013 08:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24CAC2959 for ; Wed, 6 Nov 2013 08:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA6800CF093696 for ; Wed, 6 Nov 2013 08:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA6800h7093695; Wed, 6 Nov 2013 08:00:00 GMT (envelope-from gnats) Date: Wed, 6 Nov 2013 08:00:00 GMT Message-Id: <201311060800.rA6800h7093695@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Andriy Gapon Subject: Re: kern/183689: [lor] lock order reversal when umounting a ZFS disk. X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andriy Gapon List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 08:00:01 -0000 The following reply was made to PR kern/183689; it has been noted by GNATS. From: Andriy Gapon To: bug-followup@FreeBSD.org, eocallaghan@alterapraxis.com Cc: Subject: Re: kern/183689: [lor] lock order reversal when umounting a ZFS disk. Date: Wed, 06 Nov 2013 09:57:41 +0200 This is a harmless LOR and happens with any fs, not just ZFS. -- Andriy Gapon From owner-freebsd-fs@FreeBSD.ORG Fri Nov 8 10:59:11 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 811F9172 for ; Fri, 8 Nov 2013 10:59:11 +0000 (UTC) (envelope-from benjamin.lutz@biolab.ch) Received: from gw01-1.biotronik.org (gw01-1.biotronik.org [91.204.10.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4272172 for ; Fri, 8 Nov 2013 10:59:09 +0000 (UTC) X-Disclaimed: 57934 To: freebsd-fs@freebsd.org MIME-Version: 1.0 Subject: Ghost ZFS pool prevents mounting root fs X-KeepSent: 58789A8B:60B611D5-C1257C1D:0039CC23; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3FP3 November 15, 2012 From: Benjamin Lutz Message-ID: Date: Fri, 8 Nov 2013 11:53:52 +0100 X-MIMETrack: Serialize by Router on GW01-1/SRV/MSC(Release 9.0 HF441|July 23, 2013) at 08.11.2013 11:59:04, Serialize complete at 08.11.2013 11:59:04 Content-Type: text/plain; charset="US-ASCII" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Andre Seidelt , Dirk Hoefle X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 10:59:11 -0000 Hello, I have a server here that after trying to reboot during the 9.2 update process refuses to mount the root file system, which is a ZFS (tank). The error message given is: Trying to mount root from zfs:tank []... Mounting from zfs:tank failed with error 5. Adding a mit more verbosity by setting vfs.zfs.debug=1 gives one additional crucial bit of information that probably explains why, it tries to find the disk /dev/label/disk7, but no such disk exists. When I first set up the server, I used glabel to label the disks disk0, disk1, ..., disk7, disk8 (so the full path ends up being /dev/label/disk0) and created a RAIDZ pool with those. Then I realized that I needed boot partitions. I destroyed the pool and the labels, and instead used gpart to set up 2 partitions on every disk, one for the boot loader, and one for ZFS. Since GPT allows you to label partitions, glabel is no longer necessary and is no longer used, instead the disks are called /dev/gpt/disk00, ..., /dev/gpt/disk11 (yeah, I added 3 more at that point.) The machine has worked fine with that configuration for a bit more than a year, and has lived through a couple of system updates. Imagine my surprise then when suddenly the old disk name shows up like the ghost of christmas past. Now, I can boot off the 9.2 installer USB stick and import the pool just fine. Using that, I've reinstalled the kernel and base system, but the problem persists. I did some poking around with zdb, and strangely enough, zdb finds *two* pools both called tank, one which references the old disk names, and one which references the new ones. Please find zdb's full output below. Can you tell me how to resolve the situation, i.e. how to make the ghost pool go away? I'd rather not recreate the pool or move the data to another system, since it's around 16TB and would take forever. I've had a couple of ideas myself: - move the rootfs back to a UFS partition since using zpool(8)/zfs(8) to manipulate the pool instead of the kernel's mountroot code seems to work just fine. - Since zpool(8) only sees the new, proper pool, renaming it might work. But ideally there's a way to exorcize the ghost instead of just ignoring it. Cheers, Benjamin # zdb -e tank tank vdev_children: 1 version: 28 pool_guid: 4570073208211798611 name: 'tank' state: 2 hostid: 1638041647 hostname: 'blackhole' vdev_tree: type: 'root' id: 0 guid: 4570073208211798611 children[0]: type: 'raidz' id: 0 guid: 5554077360160676751 nparity: 3 metaslab_array: 30 metaslab_shift: 37 ashift: 12 asize: 16003153002496 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 7103686668495146668 phys_path: '/dev/label/disk0' whole_disk: 1 create_txg: 4 path: '/dev/da3' children[1]: type: 'disk' id: 1 guid: 11488943812765429059 phys_path: '/dev/label/disk1' whole_disk: 1 create_txg: 4 path: '/dev/da1' children[2]: type: 'disk' id: 2 guid: 2240980772490601588 phys_path: '/dev/label/disk2' whole_disk: 1 create_txg: 4 path: '/dev/da2' children[3]: type: 'disk' id: 3 guid: 7712444707588256364 phys_path: '/dev/label/disk3' whole_disk: 1 create_txg: 4 path: '/dev/da6' children[4]: type: 'disk' id: 4 guid: 7829288003258469012 phys_path: '/dev/label/disk4' whole_disk: 1 create_txg: 4 path: '/dev/da5' children[5]: type: 'disk' id: 5 guid: 9120531484255382572 phys_path: '/dev/label/disk5' whole_disk: 1 create_txg: 4 path: '/dev/da4' children[6]: type: 'disk' id: 6 guid: 7514906893097480706 phys_path: '/dev/label/disk6' whole_disk: 1 create_txg: 4 path: '/dev/da7' children[7]: type: 'disk' id: 7 guid: 4415230843798627292 path: '/dev/label/disk7' phys_path: '/dev/label/disk7' whole_disk: 1 create_txg: 4 tank vdev_children: 1 version: 28 pool_guid: 4271606601895493352 name: 'tank' state: 0 vdev_tree: type: 'root' id: 0 guid: 4271606601895493352 children[0]: type: 'raidz' id: 0 guid: 5259196639191116590 nparity: 3 metaslab_array: 30 metaslab_shift: 36 ashift: 12 asize: 23746817556480 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 2163203387272462113 phys_path: '/dev/gpt/disk00' whole_disk: 1 DTL: 35 create_txg: 4 path: '/dev/gpt/disk00' children[1]: type: 'disk' id: 1 guid: 1705985029979435838 phys_path: '/dev/gpt/disk01' whole_disk: 1 DTL: 47 create_txg: 4 path: '/dev/gpt/disk01' children[2]: type: 'disk' id: 2 guid: 1954596596797161476 phys_path: '/dev/gpt/disk02' whole_disk: 1 DTL: 46 create_txg: 4 path: '/dev/gpt/disk02' children[3]: type: 'disk' id: 3 guid: 2938549304351001523 phys_path: '/dev/gpt/disk03' whole_disk: 1 DTL: 45 create_txg: 4 path: '/dev/gpt/disk03' children[4]: type: 'disk' id: 4 guid: 5829232400893566256 phys_path: '/dev/gpt/disk04' whole_disk: 1 DTL: 44 create_txg: 4 path: '/dev/gpt/disk04' children[5]: type: 'disk' id: 5 guid: 33801690562498165 phys_path: '/dev/gpt/disk05' whole_disk: 1 DTL: 43 create_txg: 4 path: '/dev/gpt/disk05' children[6]: type: 'disk' id: 6 guid: 8909758428297665941 phys_path: '/dev/gpt/disk06' whole_disk: 1 DTL: 42 create_txg: 4 path: '/dev/gpt/disk06' children[7]: type: 'disk' id: 7 guid: 8327488498400702594 path: '/dev/gpt/disk07' phys_path: '/dev/gpt/disk07' whole_disk: 1 DTL: 562740 create_txg: 4 offline: 1 children[8]: type: 'disk' id: 8 guid: 3781829895852494854 phys_path: '/dev/gpt/disk08' whole_disk: 1 DTL: 40 create_txg: 4 path: '/dev/gpt/disk08' children[9]: type: 'disk' id: 9 guid: 12478617399065078660 phys_path: '/dev/gpt/disk09' whole_disk: 1 DTL: 37 create_txg: 4 path: '/dev/gpt/disk09' children[10]: type: 'disk' id: 10 guid: 10513667545487916410 phys_path: '/dev/gpt/disk10' whole_disk: 1 DTL: 66 create_txg: 4 path: '/dev/gpt/disk10' children[11]: type: 'disk' id: 11 guid: 16680570826821909684 phys_path: '/dev/gpt/disk11' whole_disk: 1 DTL: 109 create_txg: 4 path: '/dev/gpt/disk11' root@:~ # zdb -l /dev/da1 -------------------------------------------- LABEL 0 -------------------------------------------- failed to unpack label 0 -------------------------------------------- LABEL 1 -------------------------------------------- failed to unpack label 1 -------------------------------------------- LABEL 2 -------------------------------------------- version: 28 name: 'tank' state: 2 txg: 61 pool_guid: 4570073208211798611 hostid: 1638041647 hostname: 'blackhole' top_guid: 5554077360160676751 guid: 11488943812765429059 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 5554077360160676751 nparity: 3 metaslab_array: 30 metaslab_shift: 37 ashift: 12 asize: 16003153002496 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 7103686668495146668 path: '/dev/label/disk0' phys_path: '/dev/label/disk0' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 11488943812765429059 path: '/dev/label/disk1' phys_path: '/dev/label/disk1' whole_disk: 1 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 2240980772490601588 path: '/dev/label/disk2' phys_path: '/dev/label/disk2' whole_disk: 1 create_txg: 4 children[3]: type: 'disk' id: 3 guid: 7712444707588256364 path: '/dev/label/disk3' phys_path: '/dev/label/disk3' whole_disk: 1 create_txg: 4 children[4]: type: 'disk' id: 4 guid: 7829288003258469012 path: '/dev/label/disk4' phys_path: '/dev/label/disk4' whole_disk: 1 create_txg: 4 children[5]: type: 'disk' id: 5 guid: 9120531484255382572 path: '/dev/label/disk5' phys_path: '/dev/label/disk5' whole_disk: 1 create_txg: 4 children[6]: type: 'disk' id: 6 guid: 7514906893097480706 path: '/dev/label/disk6' phys_path: '/dev/label/disk6' whole_disk: 1 create_txg: 4 children[7]: type: 'disk' id: 7 guid: 4415230843798627292 path: '/dev/label/disk7' phys_path: '/dev/label/disk7' whole_disk: 1 create_txg: 4 -------------------------------------------- LABEL 3 -------------------------------------------- version: 28 name: 'tank' state: 2 txg: 61 pool_guid: 4570073208211798611 hostid: 1638041647 hostname: 'blackhole' top_guid: 5554077360160676751 guid: 11488943812765429059 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 5554077360160676751 nparity: 3 metaslab_array: 30 metaslab_shift: 37 ashift: 12 asize: 16003153002496 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 7103686668495146668 path: '/dev/label/disk0' phys_path: '/dev/label/disk0' whole_disk: 1 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 11488943812765429059 path: '/dev/label/disk1' phys_path: '/dev/label/disk1' whole_disk: 1 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 2240980772490601588 path: '/dev/label/disk2' phys_path: '/dev/label/disk2' whole_disk: 1 create_txg: 4 children[3]: type: 'disk' id: 3 guid: 7712444707588256364 path: '/dev/label/disk3' phys_path: '/dev/label/disk3' whole_disk: 1 create_txg: 4 children[4]: type: 'disk' id: 4 guid: 7829288003258469012 path: '/dev/label/disk4' phys_path: '/dev/label/disk4' whole_disk: 1 create_txg: 4 children[5]: type: 'disk' id: 5 guid: 9120531484255382572 path: '/dev/label/disk5' phys_path: '/dev/label/disk5' whole_disk: 1 create_txg: 4 children[6]: type: 'disk' id: 6 guid: 7514906893097480706 path: '/dev/label/disk6' phys_path: '/dev/label/disk6' whole_disk: 1 create_txg: 4 children[7]: type: 'disk' id: 7 guid: 4415230843798627292 path: '/dev/label/disk7' phys_path: '/dev/label/disk7' whole_disk: 1 create_txg: 4 -- Benjamin Lutz | Software Engineer | BIOLAB Technology AG Dufourstr. 80 | CH-8008 Zurich | www.biolab.ch | benjamin.lutz@biolab.ch PHONE +41 44 295 97 13 | MOBILE +41 79 558 57 13 | FAX +41 44 295 97 19 This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately. From owner-freebsd-fs@FreeBSD.ORG Fri Nov 8 12:36:16 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 85DC09BB for ; Fri, 8 Nov 2013 12:36:16 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C8902660 for ; Fri, 8 Nov 2013 12:36:15 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Vel2M-0003G7-R0 for freebsd-fs@freebsd.org; Fri, 08 Nov 2013 13:19:44 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: Ghost ZFS pool prevents mounting root fs References: Date: Fri, 08 Nov 2013 13:19:41 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (Win32) X-Authenticated-As-Hash: 5a5bc696c05b24d66fef48d694aeed0652e57d03 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: 0.8 X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 X-Scan-Signature: 6b223126f74881c4298feccdef78015c X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 12:36:16 -0000 On Fri, 08 Nov 2013 11:53:52 +0100, Benjamin Lutz wrote: > Hello, > > I have a server here that after trying to reboot during the 9.2 update > process refuses to mount the root file system, which is a ZFS (tank). > > The error message given is: > Trying to mount root from zfs:tank []... > Mounting from zfs:tank failed with error 5. > > Adding a mit more verbosity by setting vfs.zfs.debug=1 gives one > additional crucial bit of information that probably explains why, it > tries > to find the disk /dev/label/disk7, but no such disk exists. > > When I first set up the server, I used glabel to label the disks disk0, > disk1, ..., disk7, disk8 (so the full path ends up being > /dev/label/disk0) > and created a RAIDZ pool with those. Then I realized that I needed boot > partitions. I destroyed the pool and the labels, and instead used gpart > to > set up 2 partitions on every disk, one for the boot loader, and one for > ZFS. Since GPT allows you to label partitions, glabel is no longer > necessary and is no longer used, instead the disks are called > /dev/gpt/disk00, ..., /dev/gpt/disk11 (yeah, I added 3 more at that > point.) The machine has worked fine with that configuration for a bit > more > than a year, and has lived through a couple of system updates. > > Imagine my surprise then when suddenly the old disk name shows up like > the > ghost of christmas past. > > Now, I can boot off the 9.2 installer USB stick and import the pool just > fine. Using that, I've reinstalled the kernel and base system, but the > problem persists. > > I did some poking around with zdb, and strangely enough, zdb finds *two* > pools both called tank, one which references the old disk names, and one > which references the new ones. Please find zdb's full output below. > > Can you tell me how to resolve the situation, i.e. how to make the ghost > pool go away? I'd rather not recreate the pool or move the data to > another > system, since it's around 16TB and would take forever. > > I've had a couple of ideas myself: > - move the rootfs back to a UFS partition since using zpool(8)/zfs(8) to > manipulate the pool instead of the kernel's mountroot code seems to work > just fine. > - Since zpool(8) only sees the new, proper pool, renaming it might work. > > But ideally there's a way to exorcize the ghost instead of just ignoring > it. Don't know if this happened to you, but there are multiple messages on this list about glabels which are not correctly deleted from the disk. So they are still there and FreeBSD will pick them up. Glabels are stored at the end of the partition or disk. Looking at the pool_guid FreeBSD sees two different pools. Ronald. > > Cheers, > Benjamin > > # zdb -e tank > tank > vdev_children: 1 > version: 28 > pool_guid: 4570073208211798611 > name: 'tank' > state: 2 > hostid: 1638041647 > hostname: 'blackhole' > vdev_tree: > type: 'root' > id: 0 > guid: 4570073208211798611 > children[0]: > type: 'raidz' > id: 0 > guid: 5554077360160676751 > nparity: 3 > metaslab_array: 30 > metaslab_shift: 37 > ashift: 12 > asize: 16003153002496 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 7103686668495146668 > phys_path: '/dev/label/disk0' > whole_disk: 1 > create_txg: 4 > path: '/dev/da3' > children[1]: > type: 'disk' > id: 1 > guid: 11488943812765429059 > phys_path: '/dev/label/disk1' > whole_disk: 1 > create_txg: 4 > path: '/dev/da1' > children[2]: > type: 'disk' > id: 2 > guid: 2240980772490601588 > phys_path: '/dev/label/disk2' > whole_disk: 1 > create_txg: 4 > path: '/dev/da2' > children[3]: > type: 'disk' > id: 3 > guid: 7712444707588256364 > phys_path: '/dev/label/disk3' > whole_disk: 1 > create_txg: 4 > path: '/dev/da6' > children[4]: > type: 'disk' > id: 4 > guid: 7829288003258469012 > phys_path: '/dev/label/disk4' > whole_disk: 1 > create_txg: 4 > path: '/dev/da5' > children[5]: > type: 'disk' > id: 5 > guid: 9120531484255382572 > phys_path: '/dev/label/disk5' > whole_disk: 1 > create_txg: 4 > path: '/dev/da4' > children[6]: > type: 'disk' > id: 6 > guid: 7514906893097480706 > phys_path: '/dev/label/disk6' > whole_disk: 1 > create_txg: 4 > path: '/dev/da7' > children[7]: > type: 'disk' > id: 7 > guid: 4415230843798627292 > path: '/dev/label/disk7' > phys_path: '/dev/label/disk7' > whole_disk: 1 > create_txg: 4 > tank > vdev_children: 1 > version: 28 > pool_guid: 4271606601895493352 > name: 'tank' > state: 0 > vdev_tree: > type: 'root' > id: 0 > guid: 4271606601895493352 > children[0]: > type: 'raidz' > id: 0 > guid: 5259196639191116590 > nparity: 3 > metaslab_array: 30 > metaslab_shift: 36 > ashift: 12 > asize: 23746817556480 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 2163203387272462113 > phys_path: '/dev/gpt/disk00' > whole_disk: 1 > DTL: 35 > create_txg: 4 > path: '/dev/gpt/disk00' > children[1]: > type: 'disk' > id: 1 > guid: 1705985029979435838 > phys_path: '/dev/gpt/disk01' > whole_disk: 1 > DTL: 47 > create_txg: 4 > path: '/dev/gpt/disk01' > children[2]: > type: 'disk' > id: 2 > guid: 1954596596797161476 > phys_path: '/dev/gpt/disk02' > whole_disk: 1 > DTL: 46 > create_txg: 4 > path: '/dev/gpt/disk02' > children[3]: > type: 'disk' > id: 3 > guid: 2938549304351001523 > phys_path: '/dev/gpt/disk03' > whole_disk: 1 > DTL: 45 > create_txg: 4 > path: '/dev/gpt/disk03' > children[4]: > type: 'disk' > id: 4 > guid: 5829232400893566256 > phys_path: '/dev/gpt/disk04' > whole_disk: 1 > DTL: 44 > create_txg: 4 > path: '/dev/gpt/disk04' > children[5]: > type: 'disk' > id: 5 > guid: 33801690562498165 > phys_path: '/dev/gpt/disk05' > whole_disk: 1 > DTL: 43 > create_txg: 4 > path: '/dev/gpt/disk05' > children[6]: > type: 'disk' > id: 6 > guid: 8909758428297665941 > phys_path: '/dev/gpt/disk06' > whole_disk: 1 > DTL: 42 > create_txg: 4 > path: '/dev/gpt/disk06' > children[7]: > type: 'disk' > id: 7 > guid: 8327488498400702594 > path: '/dev/gpt/disk07' > phys_path: '/dev/gpt/disk07' > whole_disk: 1 > DTL: 562740 > create_txg: 4 > offline: 1 > children[8]: > type: 'disk' > id: 8 > guid: 3781829895852494854 > phys_path: '/dev/gpt/disk08' > whole_disk: 1 > DTL: 40 > create_txg: 4 > path: '/dev/gpt/disk08' > children[9]: > type: 'disk' > id: 9 > guid: 12478617399065078660 > phys_path: '/dev/gpt/disk09' > whole_disk: 1 > DTL: 37 > create_txg: 4 > path: '/dev/gpt/disk09' > children[10]: > type: 'disk' > id: 10 > guid: 10513667545487916410 > phys_path: '/dev/gpt/disk10' > whole_disk: 1 > DTL: 66 > create_txg: 4 > path: '/dev/gpt/disk10' > children[11]: > type: 'disk' > id: 11 > guid: 16680570826821909684 > phys_path: '/dev/gpt/disk11' > whole_disk: 1 > DTL: 109 > create_txg: 4 > path: '/dev/gpt/disk11' > > > root@:~ # zdb -l /dev/da1 > -------------------------------------------- > LABEL 0 > -------------------------------------------- > failed to unpack label 0 > -------------------------------------------- > LABEL 1 > -------------------------------------------- > failed to unpack label 1 > -------------------------------------------- > LABEL 2 > -------------------------------------------- > version: 28 > name: 'tank' > state: 2 > txg: 61 > pool_guid: 4570073208211798611 > hostid: 1638041647 > hostname: 'blackhole' > top_guid: 5554077360160676751 > guid: 11488943812765429059 > vdev_children: 1 > vdev_tree: > type: 'raidz' > id: 0 > guid: 5554077360160676751 > nparity: 3 > metaslab_array: 30 > metaslab_shift: 37 > ashift: 12 > asize: 16003153002496 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 7103686668495146668 > path: '/dev/label/disk0' > phys_path: '/dev/label/disk0' > whole_disk: 1 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 11488943812765429059 > path: '/dev/label/disk1' > phys_path: '/dev/label/disk1' > whole_disk: 1 > create_txg: 4 > children[2]: > type: 'disk' > id: 2 > guid: 2240980772490601588 > path: '/dev/label/disk2' > phys_path: '/dev/label/disk2' > whole_disk: 1 > create_txg: 4 > children[3]: > type: 'disk' > id: 3 > guid: 7712444707588256364 > path: '/dev/label/disk3' > phys_path: '/dev/label/disk3' > whole_disk: 1 > create_txg: 4 > children[4]: > type: 'disk' > id: 4 > guid: 7829288003258469012 > path: '/dev/label/disk4' > phys_path: '/dev/label/disk4' > whole_disk: 1 > create_txg: 4 > children[5]: > type: 'disk' > id: 5 > guid: 9120531484255382572 > path: '/dev/label/disk5' > phys_path: '/dev/label/disk5' > whole_disk: 1 > create_txg: 4 > children[6]: > type: 'disk' > id: 6 > guid: 7514906893097480706 > path: '/dev/label/disk6' > phys_path: '/dev/label/disk6' > whole_disk: 1 > create_txg: 4 > children[7]: > type: 'disk' > id: 7 > guid: 4415230843798627292 > path: '/dev/label/disk7' > phys_path: '/dev/label/disk7' > whole_disk: 1 > create_txg: 4 > -------------------------------------------- > LABEL 3 > -------------------------------------------- > version: 28 > name: 'tank' > state: 2 > txg: 61 > pool_guid: 4570073208211798611 > hostid: 1638041647 > hostname: 'blackhole' > top_guid: 5554077360160676751 > guid: 11488943812765429059 > vdev_children: 1 > vdev_tree: > type: 'raidz' > id: 0 > guid: 5554077360160676751 > nparity: 3 > metaslab_array: 30 > metaslab_shift: 37 > ashift: 12 > asize: 16003153002496 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 7103686668495146668 > path: '/dev/label/disk0' > phys_path: '/dev/label/disk0' > whole_disk: 1 > create_txg: 4 > children[1]: > type: 'disk' > id: 1 > guid: 11488943812765429059 > path: '/dev/label/disk1' > phys_path: '/dev/label/disk1' > whole_disk: 1 > create_txg: 4 > children[2]: > type: 'disk' > id: 2 > guid: 2240980772490601588 > path: '/dev/label/disk2' > phys_path: '/dev/label/disk2' > whole_disk: 1 > create_txg: 4 > children[3]: > type: 'disk' > id: 3 > guid: 7712444707588256364 > path: '/dev/label/disk3' > phys_path: '/dev/label/disk3' > whole_disk: 1 > create_txg: 4 > children[4]: > type: 'disk' > id: 4 > guid: 7829288003258469012 > path: '/dev/label/disk4' > phys_path: '/dev/label/disk4' > whole_disk: 1 > create_txg: 4 > children[5]: > type: 'disk' > id: 5 > guid: 9120531484255382572 > path: '/dev/label/disk5' > phys_path: '/dev/label/disk5' > whole_disk: 1 > create_txg: 4 > children[6]: > type: 'disk' > id: 6 > guid: 7514906893097480706 > path: '/dev/label/disk6' > phys_path: '/dev/label/disk6' > whole_disk: 1 > create_txg: 4 > children[7]: > type: 'disk' > id: 7 > guid: 4415230843798627292 > path: '/dev/label/disk7' > phys_path: '/dev/label/disk7' > whole_disk: 1 > create_txg: 4 > -- > Benjamin Lutz | Software Engineer | BIOLAB Technology AG > Dufourstr. 80 | CH-8008 Zurich | www.biolab.ch | benjamin.lutz@biolab.ch > PHONE +41 44 295 97 13 | MOBILE +41 79 558 57 13 | FAX +41 44 295 97 19 > > > > This e-mail and the information it contains including attachments are > confidential and meant > only for use by the intended recipient(s); disclosure or copying is > strictly prohibited. If you > are not addressed, but in the possession of this e-mail, please notify > the > sender immediately. > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Fri Nov 8 19:07:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 22F59E1 for ; Fri, 8 Nov 2013 19:07:29 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6D002B81 for ; Fri, 8 Nov 2013 19:07:28 +0000 (UTC) Received: by mail-vb0-f42.google.com with SMTP id p14so1714275vbm.29 for ; Fri, 08 Nov 2013 11:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=B4a4taKU4NyS4nsHvMBQ6SW4Bt6N3WZHfS9ijkHLF8k=; b=WxqQGy/hEUmO/mLly3jml+iXrli/4c2lDai5O0Ni8uo6+fnwBP9Vh+Y/aTih84bx82 gLnj9qS0UJov6cnXlGK3YUNIh4ovC6UOQG6XRV8PU3F23qbscl6og8rmengO5HhI4ADz NKumlNL98JmYBp17iuI41VDsVahv2Y3ybY5qjwR+BWm4ubBa6sq4M7ol2l6E/HfLteEG TNDbqCk5XPKoNxyGbqflh+rmRHfJp7B82rJKtV56C+kJechsMKMYiB6nRcVy7vyLZPxb CtvyWVZ938zRyoxlme+hbh/qBI9MBFC+AdGKpcf9Y6psBzPfsQ63jEelklzq19p/bEPF Ua/w== MIME-Version: 1.0 X-Received: by 10.221.27.73 with SMTP id rp9mr3442890vcb.29.1383937647837; Fri, 08 Nov 2013 11:07:27 -0800 (PST) Sender: artemb@gmail.com Received: by 10.221.9.2 with HTTP; Fri, 8 Nov 2013 11:07:27 -0800 (PST) In-Reply-To: References: Date: Fri, 8 Nov 2013 11:07:27 -0800 X-Google-Sender-Auth: -VdnxGoQYivfnrpFQ0xgIPb3RcM Message-ID: Subject: Re: Ghost ZFS pool prevents mounting root fs From: Artem Belevich To: Benjamin Lutz Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs , Andre Seidelt , Dirk Hoefle X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 19:07:29 -0000 On Fri, Nov 8, 2013 at 2:53 AM, Benjamin Lutz wrote: > Hello, > > I have a server here that after trying to reboot during the 9.2 update > process refuses to mount the root file system, which is a ZFS (tank). > > The error message given is: > Trying to mount root from zfs:tank []... > Mounting from zfs:tank failed with error 5. > > Adding a mit more verbosity by setting vfs.zfs.debug=1 gives one > additional crucial bit of information that probably explains why, it tries > to find the disk /dev/label/disk7, but no such disk exists. I ran into the same issue recently. http://lists.freebsd.org/pipermail/freebsd-fs/2013-November/018496.html > Can you tell me how to resolve the situation, i.e. how to make the ghost > pool go away? I'd rather not recreate the pool or move the data to another > system, since it's around 16TB and would take forever. It should be doable, but usual "YMMV", "proceed at your own risk", "here, there be dragons" warnings apply. [snip] > root@:~ # zdb -l /dev/da1 > -------------------------------------------- > LABEL 0 > -------------------------------------------- > failed to unpack label 0 > -------------------------------------------- > LABEL 1 > -------------------------------------------- > failed to unpack label 1 > -------------------------------------------- > LABEL 2 > -------------------------------------------- > version: 28 > name: 'tank' > state: 2 > txg: 61 > pool_guid: 4570073208211798611 > hostid: 1638041647 > hostname: 'blackhole' > top_guid: 5554077360160676751 > guid: 11488943812765429059 > vdev_children: 1 > vdev_tree: > type: 'raidz' > id: 0 > guid: 5554077360160676751 > nparity: 3 > metaslab_array: 30 > metaslab_shift: 37 > ashift: 12 > asize: 16003153002496 > is_log: 0 > create_txg: 4 > children[0]: > type: 'disk' > id: 0 > guid: 7103686668495146668 > path: '/dev/label/disk0' > phys_path: '/dev/label/disk0' > whole_disk: 1 > create_txg: 4 The ghost labels are at the end of /dev/da1 (and, probably all other drives that used to be part of that pool). In my case I ended up manually zeroing out first sector of offending labels. ZFS places two copies of the labels at 512K and 256K from the end of the pool slice. See ZFS on-disk specification here: http://maczfs.googlecode.com/files/ZFSOnDiskFormat.pdf It's fairly easy to find with: #dd if=/dev/da1 bs=1m iseek={disk size in mb -1} count=1 | hexdump -C | grep version Once you know where exactly it is, deleting it is simple. Watch out for dd typos or, perhaps use some sort of disk editor to make sure you're not overwriting wrong data. It's a fairly risky operation as you have to make sure you don't nuke anything else by accident. If the disk portion with the labels is currently unallocated, then things are relatively safe. If it's currently used, then you'll need to figure out whether it's safe to overwrite those labels directly or find another way to do it. I.e. if the area with the labels is currently used for some other filesystem, you may be able to get rid of the label by filling up that filesystem with data which would hopefully overwrite labels with something else. If the labels are within the area that is part of the current pool, you are probably safe as it's either in unused area or it's not been used by ZFS yet. In my case the ghost labels were in the neighbourhood of the labels of the current pool and nuking them produced zero errors on scrub. Once you've established that manual label nuking is what you want, here's the recipe: * Make sure risking your data is *really* worth it. Consider erasing drives one-by-one and let raidz repair the pool if you have any doubts. Now that that's out of the way, let's nuke them. * offline one of the drives with the ghost labels or do the operation on an unmounted pool (I've booted from MFSBSD CD). Make sure that it is the right sector you're writing to (i.e. it's the label with wrong disks): * dd if=/dev/daN bs=512 iseek= count=10 | hexdump -C Nuke the ghost! Note: you only want to write *one* sector. Make sure you don't forget to edit count if you use shell history and reuse the commend above. * dd if=/dev/zero of=/dev/daN bs=512 oseek={sector that has 'version' word in the label} count=1 * make sure "zdb -l /dev/daN" no longer shows ghost label. * online the disk * scrub the pool. In case you made a mistake and wrote to the wrong place that may save your pool. I did the scrub only after I've erased label on the first drive to make sure it didn't damage anything vital. * repeat for all other disks with ghost labels. * run the scrub after all ghost labels have been erased. Just in case. Good luck. --Artem From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 01:39:57 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDF0EBD2 for ; Sat, 9 Nov 2013 01:39:57 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm42-vm5.bullet.mail.bf1.yahoo.com (nm42-vm5.bullet.mail.bf1.yahoo.com [216.109.114.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EEE02E50 for ; Sat, 9 Nov 2013 01:39:57 +0000 (UTC) Received: from [98.139.212.152] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 09 Nov 2013 01:39:50 -0000 Received: from [98.139.211.196] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 09 Nov 2013 01:39:50 -0000 Received: from [127.0.0.1] by smtp205.mail.bf1.yahoo.com with NNFMP; 09 Nov 2013 01:39:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1383961190; bh=wLueOnEVIUYFbP8J7/q5Ktq+kMJASMacM2XH2HFYJks=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=n5yNbQo7jmu47Lqo87fW4k1eyLUjHpKccVmCrwDVI7WN3G1dShbjXnck5Y4ni0kAqk751MIpLxKiNpb1KD7RFLqPVzJu6K7OAS9u4ony3Qj2QWy+TI8Qm/UJitLPWcpbkcO28Sam8mPBsEtXgn61m9STIVdGXDzvWcyFKmzUQkM= X-Yahoo-Newman-Id: 95380.17155.bm@smtp205.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ogD6lnYVM1lyDwMO_d7dc2NE1D8RGU1AUCTfzNDFGx5xoLE KD8qIu0SZhufZr07XmDvV6ab2Uj4aIopd1aqBhZu04Fj2oI_UqYeMQ8e2ynB az26jUUYLV32n9XuL.7RlazlsUUZmmsV9t7D4NN3973oQ.ny2A3iKeK6DU3H PLB1JH0BP5_JTDahO327PfDxXXGvaoN1iX9oEoP6PbDQdUSkRdmJSErv01M_ Djpq6pFDk9s3YxESWbEBZQUl45zpiXgYoRpfx4l4.Bjqzjg8H9Vi4d9.NYsu S0GYdBowmuySIToDnyWjMKdoBju7FCtvfqZdyFn_kmCfuO2e0CluUG9Nf9wB 7NjlPhIcDuOO1_CMEDRXlvh5anZuqrYV0pZ_XbL.PZXdHI_aOZhgl6Q6HSux uke1BcCb2mPjeRj04NUFB4vw36oH6f10U08slWRC4xY6kC1CbUucP8fDa.De JZ0YsxzcDsa5P5HA6edSV0fq.pGA.Lz_HXj.i1x3ODWmut0aNpzWj8nzU94J N7S7iVCvIeio67QID6KskD6zEm7KmhPLrgiiBZqnPlNSD13YWiJDpuEDSQLK kEeyztuRl5zn.9BeMIfXjYwgk77p0h1c1CladQJFuQIEWEW.pNz4yOp9ChGh tQOh0t5DRTkMNkDtiCoJckjlOPLqid38Out3QXu1PPSylK7Qj50rs0vyuc79 UwQ-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp205.mail.bf1.yahoo.com with SMTP; 08 Nov 2013 17:39:50 -0800 PST Subject: [CFR] printf format changes From: Sean Bruno To: freebsd-fs Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Ryq/sEnz3sTCBJFKkoyJ" Date: Fri, 08 Nov 2013 17:39:48 -0800 Message-ID: <1383961188.1526.10.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 01:39:58 -0000 --=-Ryq/sEnz3sTCBJFKkoyJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://people.freebsd.org/~sbruno/freebsd_libzfs_printf_changes.txt Some minor nits from compiles. Tested on i386/amd64 with clang. Not sure how to test with gcc though. sean --=-Ryq/sEnz3sTCBJFKkoyJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (FreeBSD) iQEcBAABAgAGBQJSfZJkAAoJEBkJRdwI6BaHx4kH/jQdOnB46tT0XEuif5ZussUA O9bcLltoioApmTTFYOPQ04Xn3r9CNf2KMfud5ugGH0tXxSu4Af1XrWIS+zTNPrtN wmqAXZhoaNDSaWGj29HNcFNWOQCEbGppDEf/GA7E9HNwqyz5HdQOvo05O/oPbisC 1XAzukRwmOUpat9CRvqczQ2Kce77aeH7FCaJCIYuCyXXUP8px2ezyw/klWr7qTQl UjRqQsGJXoOS6Rm/rV+zntS04QOHzEn/L5nO5KeXPI4hKExAghyF+6YnTHoiPdut LUWxz5PzZsgiUggFPdDO//29CqtXYLMibmrOvIR1SUvWVVuqDV0pWP/+qemee3M= =z8Sd -----END PGP SIGNATURE----- --=-Ryq/sEnz3sTCBJFKkoyJ-- From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 04:00:59 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5181DD21 for ; Sat, 9 Nov 2013 04:00:59 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11DDC2486 for ; Sat, 9 Nov 2013 04:00:59 +0000 (UTC) Received: by mail-qe0-f41.google.com with SMTP id x7so2823089qeu.0 for ; Fri, 08 Nov 2013 20:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XDO9+/AEnQHitgXjP7/jAWoRC94C9qhdv5S463NIm4w=; b=fZ7S6ew3Kxsa6FYTXBDjEnznkX7fRE/KrB4Juw1ZcfVKFqbtFRTbIZGj8IXAtfYtst B/eRDIq7CaJNgtvzgSsuFHHtmqR+d6BlmMaUvGwcFheoCokrW1w6EaxxYZKdTavZtuii IIzEdl1X7MH1AyDVz6dWIlaj0doPyCcRpGpuY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=XDO9+/AEnQHitgXjP7/jAWoRC94C9qhdv5S463NIm4w=; b=MHWNkpDLyrMqQHbGlaxBHN5C0p6kFtySrT+9SjavfacMs5W6twWdYO/+P899NBB35J te0nGvJXt/ezjO4FhV1fa6mC7a6A6v2nCBYXx7RcuYKYgMrEkLKQgLrOpz/mAWjS78LB EZxAYWpREXjefrEerk3vqGog+RI2Ct+wXpOP1HM2QYyimbPF8ypjn4wrFSSMRL+kD5st /tImbUqcuXsmh0iVwEuGnhMvMIMHceg1ranNWb4D0H8AnaMJOBzxdZCb5/fqM2nwqMVs ixT4d0pG2xZ99CQRZf5EXOs+ReJRroqbXSoeR5Hv+izUznlRB1nQah6cl1oXSNmk/93x C0Uw== X-Gm-Message-State: ALoCoQn4iQFS0W1Urg39DrnmiN9B6FdJl4aq/isxQ1md+GqQvx3Zvb0wQAGxhGgWGCzCDqySkOmc X-Received: by 10.224.163.132 with SMTP id a4mr29274574qay.54.1383969658187; Fri, 08 Nov 2013 20:00:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.63.101 with HTTP; Fri, 8 Nov 2013 20:00:28 -0800 (PST) In-Reply-To: <1383961188.1526.10.camel@powernoodle.corp.yahoo.com> References: <1383961188.1526.10.camel@powernoodle.corp.yahoo.com> From: Eitan Adler Date: Fri, 8 Nov 2013 23:00:28 -0500 Message-ID: Subject: Re: [CFR] printf format changes To: Sean Bruno Content-Type: text/plain; charset=UTF-8 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 04:00:59 -0000 On Fri, Nov 8, 2013 at 8:39 PM, Sean Bruno wrote: > http://people.freebsd.org/~sbruno/freebsd_libzfs_printf_changes.txt > > Some minor nits from compiles. Tested on i386/amd64 with clang. Most of these should be sent upstream to openzfs. -- Eitan Adler From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 08:37:01 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 175EB54C; Sat, 9 Nov 2013 08:37:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id B296B21D3; Sat, 9 Nov 2013 08:36:59 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id E75D23C17D3; Sat, 9 Nov 2013 19:36:51 +1100 (EST) Date: Sat, 9 Nov 2013 19:36:49 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: sbruno@freebsd.org Subject: Re: [CFR] printf format changes In-Reply-To: <1383961188.1526.10.camel@powernoodle.corp.yahoo.com> Message-ID: <20131109183432.R907@besplex.bde.org> References: <1383961188.1526.10.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=DstvpgP+ c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=rXxADq7T2ngA:10 a=6I5d2MoRAAAA:8 a=3oGK8yAXRtgIlRceRwsA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-fs X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 08:37:01 -0000 On Fri, 8 Nov 2013, Sean Bruno wrote: > http://people.freebsd.org/~sbruno/freebsd_libzfs_printf_changes.txt > > Some minor nits from compiles. Tested on i386/amd64 with clang. > > Not sure how to test with gcc though. Every part of the patch that I can see in the mail (that is, none) is correct. svn mail sends much larger diffs than this. After fetching the patch: % Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c % =================================================================== % --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c (revision 257859) % +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c (working copy) % @@ -2134,7 +2134,7 @@ % localtime_r(&time, &t) == NULL || % strftime(propbuf, proplen, "%a %b %e %k:%M %Y", % &t) == 0) % - (void) snprintf(propbuf, proplen, "%llu", val); % + (void) snprintf(propbuf, proplen, "%ju", (intmax_t)val); % } % break; % Style bug: line expanded beyond 80 columns. The vendor code is fairly careful about this, but has plenty of other things that I don't like, starting with obfuscating format strings to avoid long lines. Style bug: non-use of the long long abomination. The vendor won't like your fix. They prefer to use the abomination. They keep using the abomination in the format (%llu) and spell the cast '(ulonglong_t)' in many places in this file, but this patch shows that they missed many. Type mismatches: `val' starts as an unsigned type (uint64_t) but is cast to a signed type (intmax_t). This gives another type mismatch with the the format, which requires a signed type. You may be able to prove that the behaviour is defined and correct on all arches after studying the C standard for less than a week. It is much easier to see that it is correct, and possibly even defined, in the usual case where intmax_t and uintmax_t are 64 bits. The vendor code has these type mismatches in 2 places (Sep 10 version). The vendor casts to longlong_t where they should cast to ulonglong_t. They consistently use the unsigned format (%llu; never %lld). % @@ -2648,7 +2648,7 @@ % return (err); % % if (literal) { % - (void) snprintf(propbuf, proplen, "%llu", propvalue); % + (void) snprintf(propbuf, proplen, "%ju", (intmax_t)propvalue); % } else if (propvalue == 0 && % (type == ZFS_PROP_USERQUOTA || type == ZFS_PROP_GROUPQUOTA)) { % (void) strlcpy(propbuf, "none", proplen); As above, except for the long line. Unfortunately, using the vendor spelling of the cast will make the line too long. All the changes have much the same bugs. No further comment on ones that have a subset of the above. % ... % Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_diff.c % =================================================================== % --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_diff.c (revision 257859) % +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_diff.c (working copy) % @@ -116,7 +116,7 @@ % (void) snprintf(di->errbuf, sizeof (di->errbuf), % dgettext(TEXT_DOMAIN, % "Unable to determine path or stats for " % - "object %lld in %s"), obj, dsname); % + "object %jd in %s"), (intmax_t)obj, dsname); % return (-1); % } % } 'obj' starts as an unsigned type (uint64_t), but is converted to a signed type for printing in a signed format. Perhaps that is intended. No further comment on this. % Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c % =================================================================== % --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c (revision 257859) % +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c (working copy) % @@ -1472,15 +1472,15 @@ % } % if (loss > 120) { % (void) printf(dgettext(TEXT_DOMAIN, % - "%s approximately %lld "), % + "%s approximately %jd "), % dryrun ? "Would discard" : "Discarded", % - (loss + 30) / 60); % + (intmax_t)(loss + 30) / 60); % (void) printf(dgettext(TEXT_DOMAIN, % "minutes of transactions.\n")); 'loss' is signed (int64_t), so the signed format is clearly correct. % Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c % =================================================================== % --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c (revision 257859) % +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c (working copy) % @@ -2083,7 +2083,7 @@ % needagain = B_TRUE; % else % progress = B_TRUE; % - sprintf(guidname, "%lu", thisguid); % + sprintf(guidname, "%ju", (uintmax_t)thisguid); % nvlist_add_boolean(deleted, guidname); % continue; % } The vendor used a very wrong format here. No furthe comment on this. % @@ -3081,8 +3081,8 @@ % zfs_nicenum(bytes, buf1, sizeof (buf1)); % zfs_nicenum(bytes/delta, buf2, sizeof (buf1)); % % - (void) printf("received %sB stream in %lu seconds (%sB/sec)\n", % - buf1, delta, buf2); % + (void) printf("received %sB stream in %ld seconds (%sB/sec)\n", % + buf1, (unsigned long)delta, buf2); % } % % return (0); Various type mismatches: delta is time_t which was supposed to be fully opaque (C) but is an integer type with a specified representation of times (POSIX). It can be signed or unsigned, but it is usually signed. It only needs to be signed to represent times before the Epoch and negative time differences. Printing it using a signed format is the easiest way to allow for it having negative differences without having to decide if they can happen, although this is not strictly correct. Here you change the format to signed for no apparent reason and then get a type mismatch by casting the arg to unsigned. Both should be to signed. But let the vendor decide this and keep the unsigned format. Overflow errors: some systems have 64-bit time_t to avoid overflow errors. Casting to long or unsigned long breaks this on 32-bit systems for times later than 2038. Times later than 2038 are probably not needed here, so let the vendor decide this too, by keeping the %lu format and casting the arg to match it. Bruce From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 12:58:11 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E4AEF900 for ; Sat, 9 Nov 2013 12:58:11 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 80D3F2C39 for ; Sat, 9 Nov 2013 12:58:11 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id cb5so756708wib.4 for ; Sat, 09 Nov 2013 04:58:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=y4wTtRF9Ts6B02PITww2YyGy9WXGtUKayD2oeMP/PYY=; b=LyJMl98I85DdAZp5FLoK0YnfHmTkpWoFGH3cPKR0w2XXSGaX/q0sGjInApkBFDTJKZ hst0vyDfszORwJq8jsq5Mu/fC4vHa1Olo9nMP5B31uiDEZx9eVvwrz8eIlaQI0fRKFyN DRHRaE47Ei9FBkd4clx2OqFU9e0JxnTEp+hX/AIRJudyikWEeYGm0D7YXtEclE6akNTd pZ1HWgAlV2IqPEizMeXqocNGY9xYl2uK9wzq2RqvbcKY47zG1Q+42JPMuKtU+wk9HCea kzmY6TjCy6s5iUqqyxCYNeRz50srCeFVqIsyhQ1OAr5+0f/57zUgnpvHeH4I8WA3QoTc sPVw== X-Gm-Message-State: ALoCoQld5x825yYXaI3QV3kX6ktcJ1JhjTF1vN1R3WEfwB+nD4j50QBjKJUCulUaKVhwdnuhAVtW X-Received: by 10.180.12.179 with SMTP id z19mr5921387wib.24.1384001883820; Sat, 09 Nov 2013 04:58:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.175.8 with HTTP; Sat, 9 Nov 2013 04:57:23 -0800 (PST) X-Originating-IP: [124.90.145.51] From: Haowu Ge Date: Sat, 9 Nov 2013 20:57:23 +0800 Message-ID: Subject: I configured FreeBSD does not start (GPT + ZFS) To: freebsd-fs@freebsd.org, freebsd-amd64@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 12:58:12 -0000 I tried to install via mfsbsd on bsdinstaller GPT + ZFS environment System will not boot, suggesting that "no operating system found" Notebook BIOS BIOS Legacy mode has been set gpart set-a active ada0 also tried, it does not start https://www.7axu.com/files/images/BSDINSTALLER.jpg https://www.7axu.com/files/images/GPART.jpg -- Regards. By: Haowu Ge; PGP:DD1AA2E8 WWW: https://www.7axu.com/ From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 13:10:35 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79885C1E for ; Sat, 9 Nov 2013 13:10:35 +0000 (UTC) (envelope-from ronald-freebsd8@klop.yi.org) Received: from cpsmtpb-ews06.kpnxchange.com (cpsmtpb-ews06.kpnxchange.com [213.75.39.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1024D2CB4 for ; Sat, 9 Nov 2013 13:10:33 +0000 (UTC) Received: from cpsps-ews05.kpnxchange.com ([10.94.84.172]) by cpsmtpb-ews06.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 9 Nov 2013 14:09:23 +0100 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 9 Nov 2013 14:09:23 +0100 Received: from sjakie.klop.ws ([212.182.167.131]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 9 Nov 2013 14:09:23 +0100 Received: from 212-182-167-131.ip.telfort.nl (localhost [127.0.0.1]) by sjakie.klop.ws (Postfix) with ESMTP id 06828D398 for ; Sat, 9 Nov 2013 14:09:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-fs@freebsd.org Subject: Re: I configured FreeBSD does not start (GPT + ZFS) References: Date: Sat, 09 Nov 2013 14:09:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-OriginalArrivalTime: 09 Nov 2013 13:09:23.0387 (UTC) FILETIME=[E8D550B0:01CEDD4C] X-RcptDomain: freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 13:10:35 -0000 On Sat, 09 Nov 2013 13:57:23 +0100, Haowu Ge wrote: > I tried to install via mfsbsd on bsdinstaller GPT + ZFS environment > System will not boot, suggesting that "no operating system found" > > Notebook BIOS BIOS Legacy mode has been set And if you unset it? Are you sure your laptop supports GPT/EFI boot? Ronald. > gpart set-a active ada0 also tried, it does not start > > https://www.7axu.com/files/images/BSDINSTALLER.jpg > https://www.7axu.com/files/images/GPART.jpg > -- > Regards. > By: Haowu Ge; PGP:DD1AA2E8 > WWW: https://www.7axu.com/ > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 13:45:39 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1CDC92DB for ; Sat, 9 Nov 2013 13:45:39 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AA99C2E0A for ; Sat, 9 Nov 2013 13:45:38 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so543751wid.11 for ; Sat, 09 Nov 2013 05:45:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Qg3PZ89QffiuCJBW57teRdiDEX/U5rjhXDPubrGohpo=; b=NMUTNAXcZFO0alA+SN/IWEuf/Xy/geSaErxmCVYBOJSHA8WWKlncHmToKlJqdX3WRo FY6IuxqG4QL8OY6sMSMSwL2fDtqmoJVbtijuFzBymUrEmQcUsOiClVYzb9Eca4u1rccg YC1KHzWvm3L8MEBbWzDNv3P+f9hKf50vaRYH8HOL81QmLl/w8NBH+2JaKR1XMU5qA2ci x6HmYB+NXItOQMRqjupVm2XW9hQwae4sCw6hxThRFnMqqh/yrD2WIC1IHtIXxXOy6+kU X8tbzq8gnDR7LeVJfipLgx1FWP3jLkvWWKheM6n9wdnzq7Q4qPp8TH92KLUChOLh1ede KERA== X-Gm-Message-State: ALoCoQl6vUCQW4wo0y35Hw/vuAw7sBjO34ZdjNI0lxtLOeVy3pkXjywUF+q3CkK72GU8FSGhxdu3 X-Received: by 10.180.12.111 with SMTP id x15mr6142758wib.0.1384004730813; Sat, 09 Nov 2013 05:45:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.175.8 with HTTP; Sat, 9 Nov 2013 05:44:50 -0800 (PST) X-Originating-IP: [124.90.145.51] In-Reply-To: References: From: Haowu Ge Date: Sat, 9 Nov 2013 21:44:50 +0800 Message-ID: Subject: Re: I configured FreeBSD does not start (GPT + ZFS) To: Ronald Klop Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@freebsd.org, freebsd-amd64@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 13:45:39 -0000 UEFI BIOS Version https://www.7axu.com/files/images/UEFIBIOS.jpg These three models have been tried, can not start https://www.7axu.com/files/images/UEFILegacyBoot.jpg -- Regards. By: Haowu Ge; PGP:DD1AA2E8 WWW: https://www.7axu.com/ 2013/11/9 Ronald Klop > On Sat, 09 Nov 2013 13:57:23 +0100, Haowu Ge wrote: > > I tried to install via mfsbsd on bsdinstaller GPT + ZFS environment >> System will not boot, suggesting that "no operating system found" >> >> Notebook BIOS BIOS Legacy mode has been set >> > > And if you unset it? Are you sure your laptop supports GPT/EFI boot? > > Ronald. > > gpart set-a active ada0 also tried, it does not start >> >> https://www.7axu.com/files/images/BSDINSTALLER.jpg >> https://www.7axu.com/files/images/GPART.jpg >> -- >> Regards. >> By: Haowu Ge; PGP:DD1AA2E8 >> WWW: https://www.7axu.com/ >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 17:14:29 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CDC21A80; Sat, 9 Nov 2013 17:14:29 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F7912964; Sat, 9 Nov 2013 17:14:29 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id rA9HEPiu082925; Sat, 9 Nov 2013 10:14:25 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id rA9HEPr4082922; Sat, 9 Nov 2013 10:14:25 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Sat, 9 Nov 2013 10:14:24 -0700 (MST) From: Warren Block To: Haowu Ge Subject: Re: I configured FreeBSD does not start (GPT + ZFS) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sat, 09 Nov 2013 10:14:25 -0700 (MST) Cc: freebsd-fs@freebsd.org, freebsd-amd64@freebsd.org, Ronald Klop X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 17:14:29 -0000 On Sat, 9 Nov 2013, Haowu Ge wrote: > UEFI BIOS Version https://www.7axu.com/files/images/UEFIBIOS.jpg > > These three models have been tried, can not start > https://www.7axu.com/files/images/UEFILegacyBoot.jpg Some Lenovo Thinkpads are known to have problems with booting from GPT. Update the BIOS, later versions may fix it. From owner-freebsd-fs@FreeBSD.ORG Sat Nov 9 17:50:01 2013 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8121D105 for ; Sat, 9 Nov 2013 17:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5C56A2AA6 for ; Sat, 9 Nov 2013 17:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rA9Ho1FM064977 for ; Sat, 9 Nov 2013 17:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rA9Ho1AG064968; Sat, 9 Nov 2013 17:50:01 GMT (envelope-from gnats) Date: Sat, 9 Nov 2013 17:50:01 GMT Message-Id: <201311091750.rA9Ho1AG064968@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Scot Hetzel Subject: Re: bin/115361: [zfs] mount(8) gets into a state where it won't set/unset ZFS properties (atime, exec, setuid) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Scot Hetzel List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 17:50:01 -0000 The following reply was made to PR bin/115361; it has been noted by GNATS. From: Scot Hetzel To: Martin Matuska Cc: bug-followup@freebsd.org Subject: Re: bin/115361: [zfs] mount(8) gets into a state where it won't set/unset ZFS properties (atime, exec, setuid) Date: Sat, 9 Nov 2013 11:45:46 -0600 On Tue, Oct 11, 2011 at 2:23 AM, Martin Matuska wrote: > If there are no objections, I would like to close this PR. > > -- > Martin Matuska > FreeBSD committer > http://blog.vx.sk > I just ran the zfstest script on: FreeBSD fbsd10 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r257220: Sun Oct 27 22:42:08 CDT 2013 root@fbsd10:/usr/obj/usr/src/sys/GENERIC i386 The results below shows that mount still can't change devices, setuid or xattr attributes on the zfs filesystem (zfs get devices,setuid,xattr ${ZFS_FILESYSTEM}). they should show as off, and SOURCE should change to temporary, but they stay at default. NOTE: change ZFS_FILESYSTEM and ZFS_MOUNTPOINT in the zfstest script to the appropriate zfs filesystem and mount point. ================================================================================ Test setting/unsetting of devices ===> Current settings for Scratch/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles devices on default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, local, nfsv4acls) ===> mount -u -o nodevices /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles devices on default <- should be off and temporary Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nfsv4acls) <- missing nodevices ===> mount -u -o devices /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles devices on default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nfsv4acls) ================================================================================ Test setting/unsetting of setuid ===> Current settings for Scratch/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles setuid on default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, local, nfsv4acls) ===> mount -u -o nosetuid /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles setuid on default <- should be off and temporary Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nosuid, nfsv4acls) ===> mount -u -o setuid /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles setuid on default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nfsv4acls) ================================================================================ Test setting/unsetting of suid ===> Current settings for Scratch/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles devices on default Scratch/ports/distfiles setuid on default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, local, nfsv4acls) ===> mount -u -o nosuid /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles devices on default <- should be off and temporary Scratch/ports/distfiles setuid on default <- should be off and temporary Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nosuid, nfsv4acls) <- missing nodevices ===> mount -u -o nonosuid /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles devices on default Scratch/ports/distfiles setuid on default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nfsv4acls) ===> mount -u -o suid /usr/ports/distfiles =====> nosuid already set NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles devices on default Scratch/ports/distfiles setuid on default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nfsv4acls) ================================================================================ Test setting/unsetting of xattr ===> Current settings for Scratch/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles xattr off temporary Scratch/ports/distfiles on /usr/ports/distfiles (zfs, local, nfsv4acls) ===> mount -u -o noxattr /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles xattr off temporary Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nfsv4acls) <- missing noxattr ===> mount -u -o xattr /usr/ports/distfiles NAME PROPERTY VALUE SOURCE Scratch/ports/distfiles xattr off temporary <- should be on and default Scratch/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported, local, nfsv4acls) ================================================================================ -- DISCLAIMER: No electrons were maimed while sending this message. Only slightly bruised.