Date: Tue, 5 Apr 2016 13:51:28 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: Martin.Ambroz@tudc.cz Cc: freebsd-stable@freebsd.org Subject: Re: A gpart(8) mystery on 10.3-RELEASE Message-ID: <alpine.BSF.2.20.1604051331280.14591@mail.fig.ol.no> In-Reply-To: <09882402DE3EFD46AEE62C518AF3B4E501F4EE36@cd00000olcnt050.mail.cd.cz> References: <alpine.BSF.2.20.1604051125030.14591@mail.fig.ol.no> <09882402DE3EFD46AEE62C518AF3B4E501F4EE36@cd00000olcnt050.mail.cd.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Apr 2016 12:07+0200, Martin.Ambroz@tudc.cz wrote: > Trond Endrestøl píše v út 05. 04. 2016 v 11:30 +0200: > > What am I doing wrong? Can't gpart(8) write both the pmbr and the efi > image as a single command? Is it an off-by-one error in gpart(8)? > > uname -a > FreeBSD 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > gpart create -s gpt ada0 > ada0 created > > gpart add -a 4K -s 800K -t efi ada0 > ada0p1 added > > gpart add -a 4K -s 4G -t freebsd-swap ada0 > ada0p2 added > > gpart add -a 4K -t freebsd-zfs ada0 > ada0p3 added > > gpart show -p ada0 > => 34 41942973 ada0 GPT (20G) > 34 6 - free - (3.0K) > 40 1600 ada0p1 efi (800K) > 1640 8388608 ada0p2 freebsd-swap (4.0G) > 8390248 33552752 ada0p3 freebsd-zfs (16G) > 41943000 7 - free - (3.5K) > > gpart bootcode -b /boot/pmbr -p /boot/boot1.efifat -i 1 ada0 > gpart: /boot/boot1.efifat: file too big (524288 limit) > > gpart bootcode -b /boot/pmbr ada0 > bootcode written to ada0 > > gpart bootcode -p /boot/boot1.efifat -i 1 ada0 > <no output> > > System is bootable. > Try "dd if=/boot/boot1.efifat of=/dev/ada0p1" instead. I'm aware of dd(1), but I feel gpart(8) should be able to handle this task, which it sort of does, if you do the -b and the -p parts as separate invocations as demonstrated above. gpart(8) should take the current boot firmware into consideration. If the boot firmware is BIOS, then a limit of 512K (524288 bytes) is fine as that's the current limit for the bootcode in /boot/pmbr. If the boot firmware is (U)EFI, then gpart(8) should allow a -p image of a size less than or equal to the partition's size, while simultaneously writing the PMBR. I.e., contrary to the current documentation for gpart(8)'s bootcode subcommand: The size of the file must be smaller than the size of the partition. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-stable@freebsd.org Tue Apr 5 11:58:46 2016 Return-Path: <owner-freebsd-stable@freebsd.org> Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A91BB043D9 for <freebsd-stable@mailman.ysv.freebsd.org>; Tue, 5 Apr 2016 11:58:46 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 588231D2C for <freebsd-stable@freebsd.org>; Tue, 5 Apr 2016 11:58:46 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 54598B043D8; Tue, 5 Apr 2016 11:58:46 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 518B8B043D7 for <stable@mailman.ysv.freebsd.org>; Tue, 5 Apr 2016 11:58:46 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E60051D2B for <stable@freebsd.org>; Tue, 5 Apr 2016 11:58:45 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id u206so891825wme.1 for <stable@freebsd.org>; Tue, 05 Apr 2016 04:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=K7YnHZ2olW8pMbO3tVfKfJQW54I6D7N/dOMeS82nG4Q=; b=KOPe3fQHGKqiD5eRexcyO7p8s3oyjQEaUMAn7d2f3hi/wXX3dWBUGxMy2GJtKwWbiT K8nOz1dHILiyJ+uhmR3BSdRNT+KtcrR/tgNUQ/jhW9Jtezd4rFxKEbPvBL2SSzg89uyf MuFNPUNvVL+IeHfkJnZ5g1zzio11DI3c5B0PILhKhJfbDHVpkjJh2ashA/g7BcArEvMv 2mrKoDouvrMtc28B3PAwHz/yObTtfEm+aNFnLnzcFDmORRjqs1ml2WoWOkiW+m1yMqfO Ve7h8RSiHIxsypxe1C0s5DvjK0EcFR2V620Y3cZ+YzJwfttrurhWD4ZslR9hywjVJ+b4 HUDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=K7YnHZ2olW8pMbO3tVfKfJQW54I6D7N/dOMeS82nG4Q=; b=eIVcyD8YsAaO5I+cKwl52UrG6YR7vueyMdRWEoJWps/jrJkEzeR5WN4PzFpKnOvUmf 0t7bmcvpiF4nIxYTbd20q/kysFPcmaxPVghYUmG9gehRy1q7gJTTi0+K7kD/6nry1UtN QsVNxgcmWT1HjmGuhZQnknpvfXF5K7wtad5VrrydltUd8rC0ssJZmzfjRTP5ggFIn1mL eesSleiXWXgceZI4fdiKrgHrWUHW+gVdQcpW5N01K003gKJ+Tbbrkpk7R5/Zoz1ihBHm /S3+G1uuQV6NAeBEG0POpgdkuvPsH/IaKgnN1DAxgk9JWxU2dJNx0ILMGVSjpNfOgfUS bzGQ== X-Gm-Message-State: AD7BkJJxC1L4fHyvoWTV542LPmG1G2Xxqq3s1odn37DAG07D4Xd6ERszeZTGUTKbqhvKJw== X-Received: by 10.194.23.7 with SMTP id i7mr3208092wjf.9.1459857524398; Tue, 05 Apr 2016 04:58:44 -0700 (PDT) Received: from brick.home (eum237.neoplus.adsl.tpnet.pl. [83.20.184.237]) by smtp.gmail.com with ESMTPSA id m67sm14097068wma.3.2016.04.05.04.58.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Apr 2016 04:58:43 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= <etnapierala@gmail.com> Date: Tue, 5 Apr 2016 13:58:40 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> To: David Wolfskill <david@catwhisker.org>, stable@freebsd.org Subject: Re: Interaction between make & autofs/automountd Message-ID: <20160405115840.GA47120@brick.home> Mail-Followup-To: David Wolfskill <david@catwhisker.org>, stable@freebsd.org References: <20160111152849.GF1223@albert.catwhisker.org> <20160404124915.GM1232@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160404124915.GM1232@albert.catwhisker.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-stable>, <mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable/>; List-Post: <mailto:freebsd-stable@freebsd.org> List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-stable>, <mailto:freebsd-stable-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 05 Apr 2016 11:58:46 -0000 On 0404T0549, David Wolfskill wrote: > On Mon, Jan 11, 2016 at 07:28:49AM -0800, David Wolfskill wrote: > > ... > > A couple of the machines use autofs & automountd to make the ports tree > > available on demand. (In the case of the 3rd, I manually mount it when > > needed, but that's not at issue for this note, and I won't pursue that > > further here.) > > > > The machines that use autofs do so by using symlinks and the existing > > maps; e.g.: > > > > albert(10.2-S)[7] ls -lT /usr/ports > > lrwxr-xr-x 1 root wheel 20 Dec 21 04:15:39 2010 /usr/ports -> /net/howland/c/ports > > ... > > > > The contents of /etc/autofs are "vanilla" -- I have not changed > > them. I did modify /etc/auto_master a bit, to remove the "nobrowse" > > option for -net. > > > > For most purposes, including: > > * svn update > > * cd to a port directory > > * Updating files in distfiles > > * reading arbitrary files in the tree > > > > this works well, and there's no indication of any problems or issues. > > > > I recently noticed, thiough, that running "portmaster -aF" generates a > > large number of messages. > > > > I was able to narrow this down to portmaster's invocation of (e.g.) > > * cd /usr/ports/sysutils/dmidecode > > * make -V PKGNAME > > > > The "cd" seems OK; it's the "make -V PKGNAME" -- even if I invoke it by: > > hand. It works, but at the expense of messages: > > > > albert(10.2-S)[4] dirs; date; make -V PKGNAME; date > > /usr/ports/sysutils/dmidecode > > Mon Jan 11 07:26:45 PST 2016 > > dmidecode-3.0 > > Mon Jan 11 07:26:47 PST 2016 > > albert(10.2-S)[5] > > > > Jan 11 15:26:45 albert automountd[13912]: "/etc/autofs/special_hosts share", pid 13913, terminated with exit status 1 > > Jan 11 15:26:45 albert automountd[13912]: failed to handle special map "-hosts" > > Jan 11 15:26:45 albert kernel: WARNING: autofs_trigger_one: request for /net/ completed with error 5 > > Jan 11 15:26:46 albert automountd[13915]: "/etc/autofs/special_hosts share", pid 13916, terminated with exit status 1 > > Jan 11 15:26:46 albert automountd[13915]: failed to handle special map "-hosts" > > Jan 11 15:26:46 albert kernel: WARNING: autofs_trigger_one: request for /net/ completed with error 5 > > Jan 11 15:26:47 albert automountd[13918]: "/etc/autofs/special_hosts share", pid 13919, terminated with exit status 1 > > Jan 11 15:26:47 albert automountd[13918]: failed to handle special map "-hosts" > > Jan 11 15:26:47 albert kernel: WARNING: autofs_trigger_one: request for /net/ completed with error 5 > > ... > > The above got to bugging me enough that I looked into it again, and I > stumbled across <https://forums.freebsd.org/threads/49012/>; in the > process of trying figure out what was wrong. Using the clue there (of > manually starting automountd in debugging mode), I find: > > automountd: waiting for request from the kernel > automountd: not forking due to -d flag; will exit after servicing a single request > automountd: got request 553: from map -hosts, path /net/, prefix "/net", key "share", options "nosuid,intr" > automountd: parsing map "-hosts" > automountd: executing "/etc/autofs/special_hosts share" as pid 12717 > RPC: Unknown host > showmount: can't do exports rpc > automountd: "/etc/autofs/special_hosts share", pid 12717, terminated with exit status 1 > automountd: failed to handle special map "-hosts" > automountd: completing request 553 with error 5 > > > So if the above is to be believed (which I certainly hope!), something > is causing invocation of: > > /etc/autofs/special_hosts share > > which is problematic, as the argument (if any) to /etc/autofs/special_hosts > is expected to be an entry name from /etc/hosts (or equivalent). > > In turn, this appears to be happening because something is invoking > automountd with 'key "share"' -- and I'm not seeing what is doing that, > but "make" seems to be one of the few(?) things that prompts this > behavior. Hm, that's curious. Could you perhaps try to use ktrace(1) to see if something is eg trying to access /net/share for some reason? > In the mean time, I've now circumvented the issue in my case by > creating a CNAME named "share" that points to the hostname of the > NFS server. And sure enough, I no longer see the whines. > > While that does give a clear(er) indication of the nature of the > problem, I suspect I'm setting myself up for "interesting modes of > failure" when I need to refer to data that reside on a different > NFS server (also accessed via the automounter). Well, the requests were already failing with EIO, it's just that they fail much quicker now :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1604051331280.14591>