NetBSD Problem Report #54467

From martin@aprisoft.de  Thu Aug 15 16:23:02 2019
Return-Path: <martin@aprisoft.de>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 176C87A1BA
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 15 Aug 2019 16:23:02 +0000 (UTC)
Message-Id: <20190815162252.9112F5CC853@emmas.aprisoft.de>
Date: Thu, 15 Aug 2019 18:22:52 +0200 (CEST)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: new tar overwrites symlinks to directories
X-Send-Pr-Version: 3.95

>Number:         54467
>Category:       bin
>Synopsis:       new tar overwrites symlinks to directories
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 15 16:25:00 +0000 2019
>Closed-Date:    Tue Apr 21 18:31:43 +0000 2020
>Last-Modified:  Tue Apr 21 18:31:43 +0000 2020
>Originator:     Martin Husemann
>Release:        NetBSD 9.99.7
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD whoever-brings-the-night.aprisoft.de 9.99.7 NetBSD 9.99.7 (WHOEVER) #293: Mon Aug 12 12:59:36 CEST 2019 martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/sparc64/compile/WHOEVER sparc64
Architecture: sparc64
Machine: sparc64
>Description:

The new tar(1) is overeager in restoring directories if those already exist
as a symlink to another directory.

This kills updates on machines that have /usr as a symlink to someplace else
with our base.tgz containing

	 drwxr-xr-x  0 root   wheel        0 Jul 14 16:36 ./usr

>How-To-Repeat:

Try this:

	cd /tmp
	mkdir test
	cd test
	mkdir a b b/c
	tar cvf /tmp/test.tar .
	mv b d
	ln -s d b
	tar xvf /tmp/test.tar
	ls -l

It should show something like:

total 8
drwxr-xr-x  2 martin  wheel   0 Aug 15 18:20 a/
lrwxr-xr-x  1 martin  wheel   1 Aug 15 18:20 b@ -> d
drwxr-xr-x  3 martin  wheel  48 Aug 15 18:20 d/

but in -current it shows:

total 16
drwxr-xr-x  2 martin  wheel   0 Aug 15 18:22 a/
drwxr-xr-x  3 martin  wheel  48 Aug 15 18:22 b/
drwxr-xr-x  3 martin  wheel  48 Aug 15 18:22 d/


>Fix:
n/a

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/54467: broken tar symlink behaviour
Date: Thu, 15 Aug 2019 19:29:03 +0200

 This behaviour is documented, see the SECURITY section in tar(1).
 Unfortunately there seems to be no option to supress this behaviour.

 We will have to make sure all install media have pax installed and switch
 to that (or backout the switch to bsdtar).

 Martin

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 21:37:44 +0200

 On Thu, Aug 15, 2019 at 04:25:00PM +0000, martin@NetBSD.org wrote:
 > The new tar(1) is overeager in restoring directories if those already exist
 > as a symlink to another directory.

 That's how it should behave. Seems like a bug in pax-as-tar if nothing
 else.

 > This kills updates on machines that have /usr as a symlink to someplace else
 > with our base.tgz containing
 > 
 > 	 drwxr-xr-x  0 root   wheel        0 Jul 14 16:36 ./usr

 This sounds like it is asking for trouble to me. Why would you ever want
 to make /usr a symlink?!

 Joerg

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 22:25:11 +0200

 On Sat, Aug 17, 2019 at 07:50:02PM +0000, Joerg Sonnenberger wrote:
 >  On Thu, Aug 15, 2019 at 04:25:00PM +0000, martin@NetBSD.org wrote:
 >  > The new tar(1) is overeager in restoring directories if those already exist
 >  > as a symlink to another directory.
 >  
 >  That's how it should behave. Seems like a bug in pax-as-tar if nothing
 >  else.

 It should be overridable by some option, at least.

 >  > This kills updates on machines that have /usr as a symlink to someplace else
 >  > with our base.tgz containing
 >  > 
 >  > 	 drwxr-xr-x  0 root   wheel        0 Jul 14 16:36 ./usr
 >  
 >  This sounds like it is asking for trouble to me. Why would you ever want
 >  to make /usr a symlink?!

 Why not?
 In this concrete case it is the result of history, limited size boot disk
 and maybe suboptimal admin choices a long time ago. It always has worked
 fine, now it is broken.

 It is a setup that may happen to others in the real world and we should be
 very carefull before breaking it, and also should prominently warn about it.

 Martin

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 23:14:12 +0200

 On Sat, Aug 17, 2019 at 08:30:02PM +0000, Martin Husemann wrote:
 >  On Sat, Aug 17, 2019 at 07:50:02PM +0000, Joerg Sonnenberger wrote:
 >  >  On Thu, Aug 15, 2019 at 04:25:00PM +0000, martin@NetBSD.org wrote:
 >  >  > The new tar(1) is overeager in restoring directories if those already exist
 >  >  > as a symlink to another directory.
 >  >  
 >  >  That's how it should behave. Seems like a bug in pax-as-tar if nothing
 >  >  else.
 >  
 >  It should be overridable by some option, at least.

 It can be, -P covers it. I strongly believe that sysinst should not be
 setting it though.

 >  >  > This kills updates on machines that have /usr as a symlink to someplace else
 >  >  > with our base.tgz containing
 >  >  > 
 >  >  > 	 drwxr-xr-x  0 root   wheel        0 Jul 14 16:36 ./usr
 >  >  
 >  >  This sounds like it is asking for trouble to me. Why would you ever want
 >  >  to make /usr a symlink?!
 >  
 >  Why not?

 Because it messes up physical vs logical path. Even a null mount would
 be better.

 Joerg

From: "John D. Baker" <jdbaker@consolidated.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sat, 17 Aug 2019 20:40:07 -0500 (CDT)

 On Thu, 15 Aug 2019 16:25:00 +0000 (UTC), martin@NetBSD.org wrote:

 > The new tar(1) is overeager in restoring directories if those already
 > exist as a symlink to another directory.

 > This kills updates on machines that have /usr as a symlink to someplace
 > else

 This also kills 'named' if one has it running chrooted.  The migration
 process copies "/etc/namedb/*" to "/var/chroot/named/etc/namedb/" and
 replaces "/etc/namedb" with a symlink.

 After an update, "/etc/namedb" is overwritten back to a directory and
 the subsequent 'etcupdate' reports "root.cache", "bind.keys", etc. as
 missing.


 -- 
 |/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
 |\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSD            FreeBSD
 | X  No HTML/proprietary data in email.   BSD just sits there and works!
 |/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 10:40:32 +0200

 On Sat, Aug 17, 2019 at 11:14:12PM +0200, Joerg Sonnenberger wrote:
 > It can be, -P covers it. I strongly believe that sysinst should not be
 > setting it though.

 This is not documented, or am I misreading the man page?

 For sysinst I am not sure yet (and of course if everyone agrees I can easily
 deal with my own local issue).

 > >  Why not?
 > 
 > Because it messes up physical vs logical path. Even a null mount would
 > be better.

 Sure, as would have better planning before we gained debug sets and sizes
 exploded - the point is that it happens in the wild (whether for good or
 for bad reasons does not really matter).

 We either need to keep supporting it, detect and warn, or at least signal
 a big red flag in updating instructions telling users how to migrate. I am
 open to all of these (or other solutions).

 Martin

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 "martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 18:27:58 +0300

 Looking at -P on bsdtar.c:

 /* A basic set of security flags to request from libarchive. */
 #define SECURITY                                        \ 
         (ARCHIVE_EXTRACT_SECURE_SYMLINKS                \
          | ARCHIVE_EXTRACT_SECURE_NODOTDOT)

 .....
 #if 0
                 /*
                  * The common BSD -P option is not necessary, since
                  * our default is to archive symlinks, not follow
                  * them.  This is convenient, as -P conflicts with GNU
                  * tar anyway.
                  */
                 case 'P': /* BSD convention */
                         /* Default behavior, no option necessary. */
                         break;
 #endif
                 case 'P': /* GNU tar */
                         bsdtar->extract_flags &= ~SECURITY;
                         bsdtar->flags |= OPTFLAG_ABSOLUTE_PATHS;
                         break;


 So I guess -P does what we want and unfortunately more. I'd rather it
 just disabled ARCHIVE_EXTRACT_SECURE_SYMLINKS... We could
 add a long option that did exactly want we wanted I guess:
 --security=-extract-secure-symlinks

 christos

From: Joerg Sonnenberger <joerg@bec.de>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 17:55:34 +0200

 On Sun, Aug 18, 2019 at 03:30:01PM +0000, Christos Zoulas wrote:
 >  So I guess -P does what we want and unfortunately more. I'd rather it
 >  just disabled ARCHIVE_EXTRACT_SECURE_SYMLINKS... We could
 >  add a long option that did exactly want we wanted I guess:
 >  --security=-extract-secure-symlinks

 If you allow symlinks tricks, you can just allow absolute path names
 too. It really doesn't make any difference as attack vector.

 Joerg

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 "martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 19:12:59 +0300

 >=20
 > If you allow symlinks tricks, you can just allow absolute path names
 > too. It really doesn't make any difference as attack vector.

 I am not talking about an attack vector, I am just saying that the =
 behavior
 of extracting a tar archive having absolute symlinks in it, will change =
 with -P...
 I do understand the ramifications of allowing symlinks, I just want to =
 replicate
 the behavior of our current tar.

 christos

From: Hisashi T Fujinaka <htodd@twofifty.com>
To: gnats-bugs@netbsd.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 13:39:14 -0700 (PDT)

 On Sun, 18 Aug 2019, John D. Baker wrote:

 > The following reply was made to PR bin/54467; it has been noted by GNATS.
 >
 > From: "John D. Baker" <jdbaker@consolidated.net>
 > To: gnats-bugs@NetBSD.org
 > Cc:
 > Subject: Re: bin/54467: new tar overwrites symlinks to directories
 > Date: Sat, 17 Aug 2019 20:40:07 -0500 (CDT)
 >
 > On Thu, 15 Aug 2019 16:25:00 +0000 (UTC), martin@NetBSD.org wrote:
 >
 > > The new tar(1) is overeager in restoring directories if those already
 > > exist as a symlink to another directory.
 >
 > > This kills updates on machines that have /usr as a symlink to someplace
 > > else
 >
 > This also kills 'named' if one has it running chrooted.  The migration
 > process copies "/etc/namedb/*" to "/var/chroot/named/etc/namedb/" and
 > replaces "/etc/namedb" with a symlink.
 >
 > After an update, "/etc/namedb" is overwritten back to a directory and
 > the subsequent 'etcupdate' reports "root.cache", "bind.keys", etc. as
 > missing.

 As well as unbound. I was wondering why it kept getting clobbered until
 I saw this thread.

 -- 
 Hisashi T Fujinaka - htodd@twofifty.com
 BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee

From: Joerg Sonnenberger <joerg@bec.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
	"martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 23:21:39 +0200

 On Sun, Aug 18, 2019 at 07:12:59PM +0300, Christos Zoulas wrote:
 > 
 > > 
 > > If you allow symlinks tricks, you can just allow absolute path names
 > > too. It really doesn't make any difference as attack vector.
 > 
 > I am not talking about an attack vector, I am just saying that the behavior
 > of extracting a tar archive having absolute symlinks in it, will change with -P...
 > I do understand the ramifications of allowing symlinks, I just want to replicate
 > the behavior of our current tar.

 The behavior is not so much about relative or absolute symlinks, but
 about symlinks used as of a longer path. The pax behavior is IMO a
 major security issue and I don't think "supporting" it alone makes any
 sense.

 Joerg

From: John Nemeth <jnemeth@cue.bc.ca>
To: Joerg Sonnenberger <joerg@bec.de>, Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
        "martin@netbsd.org" <martin@NetBSD.org>
Subject: Re: bin/54467: new tar overwrites symlinks to directories
Date: Sun, 18 Aug 2019 15:09:48 -0700

 On Aug 18, 11:21pm, Joerg Sonnenberger wrote:
 } On Sun, Aug 18, 2019 at 07:12:59PM +0300, Christos Zoulas wrote:
 } > 
 } > > 
 } > > If you allow symlinks tricks, you can just allow absolute path names
 } > > too. It really doesn't make any difference as attack vector.
 } > 
 } > I am not talking about an attack vector, I am just saying that the behavior
 } > of extracting a tar archive having absolute symlinks in it, will change with -P...
 } > I do understand the ramifications of allowing symlinks, I just want to replicate
 } > the behavior of our current tar.
 } 
 } The behavior is not so much about relative or absolute symlinks, but
 } about symlinks used as of a longer path. The pax behavior is IMO a
 } major security issue and I don't think "supporting" it alone makes any
 } sense.

      Regardless of any kind of question of "purity" (including in
 the name of security), it is absolutely unacceptable for the sysinst
 upgrade process to break people's systems.  If having sysinst use
 the -P option by default stops it from breaking people's systems,
 then so be it.

 }-- End of excerpt from Joerg Sonnenberger

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/54467 CVS commit: src/usr.sbin/sysinst
Date: Tue, 12 Nov 2019 18:04:37 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Tue Nov 12 18:04:37 UTC 2019

 Modified Files:
 	src/usr.sbin/sysinst: util.c

 Log Message:
 PR 54467: we trust our own sets, extract them with -P to allow symlink
 redirection (especially for updates and chroot services - back out
 once a better solution for those is implemented)


 To generate a diff of this commit:
 cvs rdiff -u -r1.35 -r1.36 src/usr.sbin/sysinst/util.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "SAITOH Masanobu" <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/54467 CVS commit: [netbsd-9] src/usr.sbin/sysinst
Date: Sun, 17 Nov 2019 13:45:27 +0000

 Module Name:	src
 Committed By:	msaitoh
 Date:		Sun Nov 17 13:45:26 UTC 2019

 Modified Files:
 	src/usr.sbin/sysinst [netbsd-9]: Makefile.inc bsddisklabel.c
 	    configmenu.c defs.h disklabel.c disks.c gpt.c install.c label.c
 	    main.c mbr.c mbr.h msg.mi.de msg.mi.en msg.mi.es msg.mi.fr
 	    msg.mi.pl net.c part_edit.c partitions.c partitions.h partman.c
 	    run.c util.c
 	src/usr.sbin/sysinst/arch/amd64 [netbsd-9]: md.c md.h
 	src/usr.sbin/sysinst/arch/ews4800mips [netbsd-9]: Makefile
 	src/usr.sbin/sysinst/arch/i386 [netbsd-9]: md.c menus.md msg.md.de
 	    msg.md.en msg.md.es msg.md.fr msg.md.pl
 	src/usr.sbin/sysinst/arch/playstation2 [netbsd-9]: msg.md.de msg.md.en
 	    msg.md.es msg.md.fr msg.md.pl

 Log Message:
 Pull up following revision(s) (requested by martin in ticket #436):
 	usr.sbin/sysinst/disks.c: revision 1.55
 	usr.sbin/sysinst/msg.mi.en: revision 1.24
 	usr.sbin/sysinst/mbr.c: revision 1.22
 	usr.sbin/sysinst/disks.c: revision 1.56
 	usr.sbin/sysinst/msg.mi.en: revision 1.25
 	usr.sbin/sysinst/disks.c: revision 1.57
 	usr.sbin/sysinst/arch/playstation2/msg.md.pl: revision 1.3
 	usr.sbin/sysinst/Makefile.inc: revision 1.30
 	usr.sbin/sysinst/configmenu.c: revision 1.11
 	usr.sbin/sysinst/util.c: revision 1.35
 	usr.sbin/sysinst/gpt.c: revision 1.12
 	usr.sbin/sysinst/util.c: revision 1.36
 	usr.sbin/sysinst/arch/playstation2/msg.md.de: revision 1.3
 	usr.sbin/sysinst/arch/i386/menus.md: revision 1.3
 	usr.sbin/sysinst/util.c: revision 1.37
 	usr.sbin/sysinst/part_edit.c: revision 1.11
 	usr.sbin/sysinst/arch/i386/msg.md.en: revision 1.2
 	usr.sbin/sysinst/util.c: revision 1.38
 	usr.sbin/sysinst/part_edit.c: revision 1.12
 	usr.sbin/sysinst/arch/i386/msg.md.en: revision 1.3
 	usr.sbin/sysinst/util.c: revision 1.39
 	usr.sbin/sysinst/part_edit.c: revision 1.13
 	usr.sbin/sysinst/arch/i386/msg.md.en: revision 1.4
 	usr.sbin/sysinst/disklabel.c: revision 1.15
 	usr.sbin/sysinst/bsddisklabel.c: revision 1.30
 	usr.sbin/sysinst/arch/i386/msg.md.es: revision 1.2
 	usr.sbin/sysinst/bsddisklabel.c: revision 1.31
 	usr.sbin/sysinst/arch/i386/msg.md.es: revision 1.3
 	usr.sbin/sysinst/arch/i386/msg.md.es: revision 1.4
 	usr.sbin/sysinst/mbr.h: revision 1.4
 	usr.sbin/sysinst/main.c: revision 1.18
 	usr.sbin/sysinst/partman.c: revision 1.44
 	usr.sbin/sysinst/msg.mi.de: revision 1.17
 	usr.sbin/sysinst/arch/i386/msg.md.fr: revision 1.2
 	usr.sbin/sysinst/msg.mi.de: revision 1.18
 	usr.sbin/sysinst/arch/i386/msg.md.fr: revision 1.3
 	usr.sbin/sysinst/arch/playstation2/msg.md.en: revision 1.3
 	usr.sbin/sysinst/arch/i386/msg.md.fr: revision 1.4
 	usr.sbin/sysinst/arch/amd64/md.c: revision 1.2
 	usr.sbin/sysinst/arch/ews4800mips/Makefile: revision 1.3
 	usr.sbin/sysinst/arch/playstation2/msg.md.es: revision 1.3
 	usr.sbin/sysinst/label.c: revision 1.13
 	usr.sbin/sysinst/Makefile.inc: revision 1.29
 	usr.sbin/sysinst/label.c: revision 1.14
 	usr.sbin/sysinst/util.c: revision 1.40
 	usr.sbin/sysinst/partitions.c: revision 1.5
 	usr.sbin/sysinst/arch/amd64/md.h: revision 1.8
 	usr.sbin/sysinst/msg.mi.es: revision 1.18
 	usr.sbin/sysinst/net.c: revision 1.34
 	usr.sbin/sysinst/msg.mi.es: revision 1.19
 	usr.sbin/sysinst/arch/i386/msg.md.pl: revision 1.2
 	usr.sbin/sysinst/arch/i386/md.c: revision 1.22
 	usr.sbin/sysinst/msg.mi.fr: revision 1.22
 	usr.sbin/sysinst/arch/playstation2/msg.md.fr: revision 1.3
 	usr.sbin/sysinst/arch/i386/msg.md.pl: revision 1.3
 	usr.sbin/sysinst/arch/i386/md.c: revision 1.23
 	usr.sbin/sysinst/msg.mi.pl: revision 1.25
 	usr.sbin/sysinst/msg.mi.fr: revision 1.23
 	usr.sbin/sysinst/arch/i386/msg.md.pl: revision 1.4
 	usr.sbin/sysinst/arch/i386/md.c: revision 1.24
 	usr.sbin/sysinst/partitions.h: revision 1.8
 	usr.sbin/sysinst/msg.mi.pl: revision 1.26
 	usr.sbin/sysinst/arch/i386/msg.md.de: revision 1.2
 	usr.sbin/sysinst/arch/i386/msg.md.de: revision 1.3
 	usr.sbin/sysinst/arch/i386/msg.md.de: revision 1.4
 	usr.sbin/sysinst/run.c: revision 1.13
 	usr.sbin/sysinst/defs.h: revision 1.46
 	usr.sbin/sysinst/install.c: revision 1.12
 	usr.sbin/sysinst/defs.h: revision 1.47
 	usr.sbin/sysinst/install.c: revision 1.13
 	usr.sbin/sysinst/defs.h: revision 1.48
 Add options to the various partitioning stages that allow cloning of
 alien partitions (optionally including data).
 PR 54467: we trust our own sets, extract them with -P to allow symlink
 redirection (especially for updates and chroot services - back out
 once a better solution for those is implemented)
 Make cloning support optional, so we can save some space on very small
 install media.
 Drop MBR and cloning support on crunched install media.
 Make tar extraction flags depend on our usage of pax-as-tar or bsdtar.
 Fix missing newlines in bios match display, pointed out by maxv.
 Drop unused variable.
 Fix table of bios geomatries
 knf style adjustments
 Make the bootblock selection menu more sane, pointed out by maxv
 Make sure all menus have a translatable exit option (or none at all).
 On amd64 support installation with a KASLR kernel, via "custom install"
 and selecting the GENERIC_KASLR kernel set.
 Setup /prekern and boot.cfg accordingly.


 To generate a diff of this commit:
 cvs rdiff -u -r1.22 -r1.22.2.1 src/usr.sbin/sysinst/Makefile.inc
 cvs rdiff -u -r1.23.2.5 -r1.23.2.6 src/usr.sbin/sysinst/bsddisklabel.c
 cvs rdiff -u -r1.10 -r1.10.2.1 src/usr.sbin/sysinst/configmenu.c
 cvs rdiff -u -r1.42.2.3 -r1.42.2.4 src/usr.sbin/sysinst/defs.h
 cvs rdiff -u -r1.10.2.4 -r1.10.2.5 src/usr.sbin/sysinst/disklabel.c
 cvs rdiff -u -r1.44.2.10 -r1.44.2.11 src/usr.sbin/sysinst/disks.c
 cvs rdiff -u -r1.6.2.5 -r1.6.2.6 src/usr.sbin/sysinst/gpt.c
 cvs rdiff -u -r1.9.2.1 -r1.9.2.2 src/usr.sbin/sysinst/install.c
 cvs rdiff -u -r1.10.2.2 -r1.10.2.3 src/usr.sbin/sysinst/label.c
 cvs rdiff -u -r1.17 -r1.17.2.1 src/usr.sbin/sysinst/main.c
 cvs rdiff -u -r1.19.2.2 -r1.19.2.3 src/usr.sbin/sysinst/mbr.c
 cvs rdiff -u -r1.3 -r1.3.2.1 src/usr.sbin/sysinst/mbr.h
 cvs rdiff -u -r1.13.2.3 -r1.13.2.4 src/usr.sbin/sysinst/msg.mi.de
 cvs rdiff -u -r1.19.2.4 -r1.19.2.5 src/usr.sbin/sysinst/msg.mi.en
 cvs rdiff -u -r1.14.2.3 -r1.14.2.4 src/usr.sbin/sysinst/msg.mi.es
 cvs rdiff -u -r1.17.2.4 -r1.17.2.5 src/usr.sbin/sysinst/msg.mi.fr
 cvs rdiff -u -r1.20.2.4 -r1.20.2.5 src/usr.sbin/sysinst/msg.mi.pl
 cvs rdiff -u -r1.33 -r1.33.2.1 src/usr.sbin/sysinst/net.c
 cvs rdiff -u -r1.7.2.2 -r1.7.2.3 src/usr.sbin/sysinst/part_edit.c
 cvs rdiff -u -r1.1.2.2 -r1.1.2.3 src/usr.sbin/sysinst/partitions.c
 cvs rdiff -u -r1.4.2.3 -r1.4.2.4 src/usr.sbin/sysinst/partitions.h
 cvs rdiff -u -r1.41.2.1 -r1.41.2.2 src/usr.sbin/sysinst/partman.c
 cvs rdiff -u -r1.12 -r1.12.2.1 src/usr.sbin/sysinst/run.c
 cvs rdiff -u -r1.29.2.4 -r1.29.2.5 src/usr.sbin/sysinst/util.c
 cvs rdiff -u -r1.1 -r1.1.30.1 src/usr.sbin/sysinst/arch/amd64/md.c
 cvs rdiff -u -r1.6.2.1 -r1.6.2.2 src/usr.sbin/sysinst/arch/amd64/md.h
 cvs rdiff -u -r1.2 -r1.2.2.1 src/usr.sbin/sysinst/arch/ews4800mips/Makefile
 cvs rdiff -u -r1.20.2.1 -r1.20.2.2 src/usr.sbin/sysinst/arch/i386/md.c
 cvs rdiff -u -r1.2 -r1.2.2.1 src/usr.sbin/sysinst/arch/i386/menus.md
 cvs rdiff -u -r1.1 -r1.1.24.1 src/usr.sbin/sysinst/arch/i386/msg.md.de \
     src/usr.sbin/sysinst/arch/i386/msg.md.en \
     src/usr.sbin/sysinst/arch/i386/msg.md.es \
     src/usr.sbin/sysinst/arch/i386/msg.md.fr \
     src/usr.sbin/sysinst/arch/i386/msg.md.pl
 cvs rdiff -u -r1.2 -r1.2.30.1 \
     src/usr.sbin/sysinst/arch/playstation2/msg.md.de \
     src/usr.sbin/sysinst/arch/playstation2/msg.md.en \
     src/usr.sbin/sysinst/arch/playstation2/msg.md.es \
     src/usr.sbin/sysinst/arch/playstation2/msg.md.fr \
     src/usr.sbin/sysinst/arch/playstation2/msg.md.pl

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Tue, 21 Apr 2020 17:25:41 +0000
State-Changed-Why:
I assume this issue is fixed. Do you agree? :-)


State-Changed-From-To: feedback->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Tue, 21 Apr 2020 18:31:43 +0000
State-Changed-Why:
Yes, fixed + pulled up


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.