8129 bootadm: add support for non-zfs boot entries in menu.lst

Review Request #453 — Created April 30, 2017 and submitted

tsoome
illumos-gate
8129, 8226
dc7c552...
general
8129 bootadm: add support for non-zfs boot entries in menu.lst

tsoome@test:~$ ./bootadm list-menu
the location for the active menu is: /rpool/boot/menu.lst
INDEX NAME            DEVICE                     TYPE   DEFAULT
0     Disk1           disk1:                     chain     -
1     Disk2           disk2:                     chain     -
2     Disk3           disk3:                     chain     -
3     Disk3_ufs       disk3s1a:                  bootfs    -
4     oi-431          rpool/ROOT/oi-431          bootfs    -
5     oi-432          rpool/ROOT/oi-432          bootfs    -
6     oi-433          rpool/ROOT/oi-433          bootfs    -
7     oi-434          rpool/ROOT/oi-434          bootfs    -
8     oi-435          rpool/ROOT/oi-435          bootfs    -
9     oi-436          rpool/ROOT/oi-436          bootfs    -
10    oi-437          rpool/ROOT/oi-437          bootfs    -
11    oi-438          rpool/ROOT/oi-438          bootfs    -
12    oi-438-backup-1 rpool/ROOT/oi-438-backup-1 bootfs    -
13    oi-439          rpool/ROOT/oi-439          bootfs    -
14    oi-440          rpool/ROOT/oi-440          bootfs    *
tsoome@test:~$
  • 0
  • 0
  • 0
  • 1
  • 1
Description From Last Updated
rm
  1. Should there be updates to bootadm or some other manual pages to better describe how these non-ZFS boot entries function in the broader system? I haven't looked through all the code yet, but was trying to get a sense of how management, etc. was expected to function.

    1. Eventually yes; there is a little but - right now the bootadm does not really let to create such entries, and frankly, is quite an mess with all those undocumented commands etc. I think the best place to start with would be with menu.lst to get documented, but I am hoping to get some feedback first:D

  2. 
      
hans
  1. Ship It!
  2. 
      
yuripv
  1. 
      
  2. Could you make the header all in caps, pretty please? Makes the output so much easier to read, IMO.

  3. 
      
tsoome
tsoome
yuripv
  1. 
      
  2. Thanks, though the order seems to be a bit strange (in order of importance). I'd sort them as:

    INDEX
    NAME (instead of MENU)
    DEVICE (or DEVICE/FS?)
    TYPE
    DEFAULT

  3. 
      
tsoome
tsoome
yuripv
  1. 
      
  2. I guess you could use OFMT_RIGHTJUST for this field instead.

    1. The problem is that OFMT_RIGHTJUST is global state flag and will apply to all fields - which is actually an limit of the ofmt facility.

    2. Doh, sorry, looks like something that really should be improved.

  3. 
      
yuripv
  1. Ship It!
  2. 
      
aeon
  1. (Maybe order columns according to whatever FDISK shows.)

    As you know, it does not matter as long as all the information can always
    fit on the same screen page. But you can't guarantee that happening.

    The bootadm tool is not the main issue to me because most users will be
    dealing with the boot menu layout and far fewer with the bootadm tool.

    But I assume the bootadm layout will be used in the boot menu list also.

    1)
    I am not trying to nit pick but is the DEFAULT column always the least
    important or even necessary?

    I think it to be most important if the choice often changes over time
    such as for a portable live OS on USB pen.

    Ideally, historically order the entries having the most recently used
    in first place for a simple time slider. This eliminates the
    requirement to indicate the Default with its own column because it is
    always the first row.

    2)
    My main issue stems from your March or April test release where the boot
    menu listing showed my backup BE entry extending past the right hand side
    of the box frame. Although, the boot information was not truncated so it
    was really only a matter of looks.

    I suggest changing the menu box to either expand for contents length or
    else remove all frames except the report header frame. Then put the
    column titles within the header, and append a "Page " current#"/"total#
    column title when there is more than one page, and eliminate the
    "DEFAULT" column.

    3)
    You can see how a user choice of larger text can adversely affect the menu
    list. Anticipate people using a framebuffer VESA mode for less than the
    maximum resolution in order to share a standardized aspect ratio for a
    GUI. For example, allow the same usecase requirement as the FreeBSD
    Video Graphics Library (VGL) for console applications. Your VGAText gfx
    module essentially replaces their VGL except we can't programmatically
    change the graphic mode because you let the user choose it during boot.
    Simply consider X11 not being a universal requirement.

    Just my 3 cents here. It is ready to ship AS IS.

    -- John

    1. aye, I am quite aware of the frame issue - the same problem is also in fbsd; the problem is that the menu framework is from the time before BE's and has quite static layout. However as there are more pressing matters, it just has to wait in queue for some time:)

  2. 
      
hans
  1. Ship It!
  2. 
      
tsoome
andy_js
  1. Ship It!
  2. 
      
tsoome
tsoome
tsoome
yuripv
  1. Ship It!
  2. 
      
hans
  1. Ship It!
  2. 
      
tsoome
Review request changed

Status: Closed (submitted)

Loading...