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: Tue, 01 May 2018 19:57:58 +0700

     Date:        Tue,  1 May 2018 09:25:01 +0000 (UTC)
     From:        Martin Husemann <martin%duskware.de@localhost>
     Message-ID:  <20180501092501.9703B7A219%mollari.NetBSD.org@localhost>
 
   |  OK, you are using the ram disk based installers, while I tested with the
   |  CD image.
 
 Yes, the original PR text from Lars-Johan Liman says:
 
 3. Boot a Xen virtual machine with the 8.0_RC1
    netbsd-INSTALL_XEN3_DOMU kernel.
 
 And then,  when I repeated it:
 
  Boot netbsd-INSTALL kernel from
         ${RELEASE}/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
 
 though any netbsd-INSTALL kernel does the same (my earlier bare
 metal test did not use the XEN3_DOMU kernel, obviously.)
  
   |  >  	gpt [-q] query dev
   |  I did a very lazy poor man's version of that.
 
 That should be fine.   I had in the back of my mind the potential to
 add options to "gpt query" to test other things which a script might
 want to know, but if that need ever eventuates, it can be done then,
 and the "header" command can continue exit(1) for no GPT.
 
   |  >  Of course, the same recipe for disaster (not potential) exists when
   |  >  there is no insalled vnconfig (or vndconfig) program at all - which is
   |  >  the case on the MFS mini-roon that's embedded in the INSTALL
   |  >  kernel.
   |  
   |  We have the "have_vnd" variable to note that.
 
 We do, so when have_vnd is false, the code does...
 
                  if (!have_vnd)
                          (void)0();
 
 If someone was looking for a way to manufacture a core file
 in a way that gdb would fail to be of much help, I can't think of
 many easier strategies...
 
   |  Indeed, but I'm not quite sure what menus exactly you want to remove
   |  in this case.
 
 No idea, I did not look that deeply, but if there are none, then just not
 removing the not existing menus would be better than what it is doing now.
 
 That is, change:
 
                 if (!have_vnd)
                         remove_vnd_options();
                 else if (!(vnds = calloc(MAX_VND, sizeof(*vnds))))
                         have_vnd = 0;
 
 into
 	if (have_vnd && !(vnds = calloc(MAX_VND, sizeof(*vnds))))
 		have_vnd = 0;
 
 
 It is worth noting that that small segment is the only use of have_vnd
 anywhere, so why it sets have_vnd = 0 when it fails I have no idea.
 
 The
 	 if (firstrun) { 
 		/* ... */
 		firstrun = 0;
 	}
 
 block makes sure it is never done again, so that "have_vnd = 0"
 is assigning to a variable that is never examined again.    The
 other have_xxx variables are (well, some of them at least, I did
 not do an exhaustive search) also used elsewhere.
 
 That is, it sure looks as if the remove_xxx_options() code is really
 intended to remove stuff from the menus, so that other code which
 will not work wiuthout vndconfig  can never later attempt to execute it.
 
 And I do see ...
 
         if (have_lvm) { 
                 pm_upddevlist_adv(m, arg, &i,
                     &(pm_upddevlist_adv_t) {MSG_create_cnd, PM_VND_T, &vnds_t_in
 fo, 0, NULL});
                 pm_upddevlist_adv(m, arg, &i,
                     &(pm_upddevlist_adv_t) {MSG_create_vg, PM_LVM_T, &lvms_t_inf
 o, 0,                   
                     &(pm_upddevlist_adv_t) {MSG_create_lv, PM_LVMLV_T, &lv_t_inf
 o, 0, NULL}});  
         }               
 
 and also:
 
                 case PM_VND_T:
                         return pm_edit(PMV_MENU_END, pm_vnd_edit_menufmt,
                                 pm_vnd_set_value, pm_vnd_check, pm_vnd_init,
                                 NULL, ((part_entry_t *)arg)[m->cursel].dev_ptr, 
 
 
 and in pm_menufmt()
 
                 case PM_VND_T:          
                         pm_vnd_menufmt(m, opt, arg);
                         break; 
 
 all of which might be related.
 
 At a minimum, if vnds are needed for lvm config (why?  I thought lvm
 used vg not vnd ?) then perhaps
 
         have_lvm = binary_available("lvm");
 should become
         have_lvm = have vnd && binary_available("lvm");
 
 But I suspect that things are just more messed up than that.
 
 kre
 
 ps: aside: I also don't understand why from msg.mi.en the
 message "Create virtual disk image (VND)" (or from msg.mi.de
 "Erstellen Sie virtuelle Disk-Image (VND)" etc) is "message create_cnd"
 instead of "message create_vnd" - looks weird - but that's just a name.