Re: install/53220: sysinst dumps core with extended partitioning.

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR install/53220; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: install/53220: sysinst dumps core with extended partitioning.
Date: Mon, 30 Apr 2018 02:25:27 +0700

     Date:        Sun, 29 Apr 2018 16:25:01 +0000 (UTC)
     From:        Robert Elz <kre%munnari.OZ.AU@localhost>
     Message-ID:  <20180429162501.76E3D7A261%mollari.NetBSD.org@localhost>
 
   |  I will see if I can set up the conditions that cause the problem.
 
 OK, done.   core dump from sysinst easy to make...
 
 total 3136                                                                      
 -r--r--r--   1 root  wheel     2646 Mar 30 14:24 .profile                       
 drwxr-xr-x   2 root  wheel      512 Mar 30 14:24 bin
 drwxr-xr-x   9 root  wheel   115968 Apr 30 02:02 dev
 drwxr-xr-x   2 root  wheel        0 Apr 30 02:02 etc
 drwxr-xr-x   2 root  wheel      512 Mar 30 14:24 kern
 drwxr-xr-x   3 root  wheel      512 Mar 30 14:24 libexec
 drwxr-xr-x   2 root  wheel      512 Mar 30 14:24 mnt
 drwxr-xr-x   2 root  wheel      512 Mar 30 14:24 mnt2
 drwxr-xr-x   2 root  wheel     1024 Mar 30 14:24 sbin                           
 -r-xr-xr-x  75 root  wheel  2485376 Mar 30 14:24 sysinst                        
 -rw-------   1 root  wheel   435904 Apr 30 02:03 sysinst.core                   
 -r--r--r--   1 root  wheel    36898 Mar 30 14:24 sysinstmsgs.de                 
 [...]
 
 
 I used an 8.0_RC1 build I made on April 21, but I think anything recentish
 would do (the previous time it happened for me was a NetBSD-current (8.99.?)
 from (very) late January.
 
 This time I booted a XEN DomU (as that's the easied to play in), the
 previous time was bare metal booting from an install CD (an install
 CD in a format I make it, which might not be quite the same as the
 normal one, but which has the same sysinst, ... there was no
 problem booting it - at least when the UEFI firmware was switched
 to legacy mode - it was made before the code to allow UEFI booting
 from cd was added - I have not yet tried that)
 
 The procedure I used just now was:
 
 First set up the disk (in my bare metal test this was done, despite my
 request that it not be) by the people who sold me the system...
 
 Boot netbsd-INSTALL kernel from
 	${RELEASE}/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
 
 exit sysinst, and in the root shell that appears:
 
 gpt create -A xbd0
 gpt add -b 2048 -s 204800 -l EFI -t efi xbd0
 gpt add -s 1576960 -t windows -l w^HWindows xbd0 
 gpt add -b 1783808 -l windows_data -t windows xbd0 
 shutdown
 
 That leaves the disk looking like:
 
     start     size  index  contents
         0        1         PMBR (active)
         1        1         Pri GPT header
         2       32         Pri GPT table
        34     2014         Unused
      2048   204800      1  GPT part - EFI System
    206848  1576960      2  GPT part - Windows basic data
   1783808  3144467      3  GPT part - Windows basic data
   4928275       32         Sec GPT table
   4928307        1         Sec GPT header
 
 Any method that leaves the drive (real or virtual) looking like
 that should be OK.   Note there's no free space (well, 2014 blocks...)
 There's also (in my case) no NetBSD partitions.
 
 My bare metal install looked just the same - the drive (well drives)
 were much bigger, but full of windows crap filesystems (mostly
 just empty).
 
 Then attempt a NetBSD install:
 
 Boot netbsd-INSTALL kernel
 In Sysinst
         a - messages in English
         a - Install NetBSD to hard disk
         b - yes
         b - extended partitioning
  
 (BOOM)
 
 I then repeated that, using the same (untouched) drive, using a
 NetBSD-current (8.99.14) from late March (the latest one I had
 lying around without doing a rebuild.)   Same steps in sysinst,
 same result.
 
 If you're still unable to reproduce this, let me know, and I'll build
 a version of this that includes a sysinst that's built wwith debug
 symbols,  and see if I can see what is up in the core file.
 
 And from Martin's message:
   | Robert is correct, this is supposed to be done on the installed
   |  domU, as sysinst will insist 
 
 That's not quite what I said, I said it can be done in the installed
 DomU (as I did just above) not that it should be.   What sysinst
 insists on is irrelevant, as once it is unable to proceed, it simply
 isn't used any more - I almost never use it, when I am doing
 DomU builds (my must common type) I simply have DESTDIR be
 the filesystem that is to be the DomU filesystem, and build
 directly into it.  Then I populate /dev fix up what needs to be
 fixed in /etc, and boot it.
 
 If I was going to go ahead and install the system just above, I'd
 do it the same way - either in the DomU after sysinst has crashed,
 I'd gpt remove gpt remove ... then gpt add gpt add ... to set up
 the filesystems, mount them, and then fetch and untar the install
 sets (which is exactly what I did on the bare metal system,
 except for the "fetch" part as they were on the CD already waiting
 to be unpacked).
 
 Alternatively, when using XEN, the whole install can be done my
 mounting the (to be) DomU filesystem(s) in the Dom0 and then
 doing the set unpacks there (where the tooks are better as a
 full running NetBSD is available).
 
 Either way works - which is better just depends what you prefer
 (the Xen Dom0 way means all the doc is also easily available.)
 
 kre