Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Chris

On 2021-04-24 16:02, Reginald Beardsley via openindiana-discuss wrote:
FWIW I saw the messages that Nelson posted at the start of this discussion 
on
systems that booted. However, they very likely had relic zfs labels. I've 
had
mysterious "corrupted pools" appear which I was only able to fix by using 
dd(1) to

wipe out the old label.
If it's anything like gpt, you're right. With gpt it's always best to perform 
a
gpart destroy prior to writing a new disk. If you don't delete the indices 
first

than a gpart destroy -F is often required. As memory serves; zfs also has the
destroy option. Which will clear the tables so you don't end up with 
"foreign"

un-referenced labels.

--Chris


I've come to the conclusion that zfs is saving information in places I don't 
know

about and which may or may not get cleared by "zpool labelclear".

Once I recover from the ordeal of this past week I'll go back and conduct 
some
experiments such as creating a slice, creating a pool and then modifying the 
slice

and creating a new pool to see if I can sort out what is happening.

I am very sorry that some of the developers took offense to my posts, but I 
am
very pleased that there is more engagement by the users in testing. "It is 
meet,

right and our bounden duty..."

Reg


 On Saturday, April 24, 2021, 05:16:59 PM CDT, Toomas Soome via
openindiana-discuss  wrote:




On 25. Apr 2021, at 00:53, Nelson H. F. Beebe  wrote:

Toomas Soome mailto:tso...@me.com>> responds today:


...
On 24. Apr 2021, at 23:56, Nelson H. F. Beebe  
wrote:


Thanks for the additional suggestions to get the CentOS-7 based
OpenIndiana to boot.  Here is what I get:

      boot: status
      disk device:
          disk0:  BIOS driver C (167772160 X 512)
            disk0s1: Solaris 2            79GB
              disk0s1a: root              79GB
              disk0s1i: root            8032KB


Why there are two root slices? it should not disturb us but still weird. 
anyhow, can you mail

me full partition table, format -> verify or partition -> print.ole disk

Since this is VM and no dual-boot, I recommend to only do whole disk 
setup (that is, GPT
automatically prepared). But for now, I wonder how your current slices 
are defined:)


...


I booted the failing VM from the CD-ROM, ran "ssh-keygen -A", edited
/etc/ssh/sshd_config to change PermitRootLogin from no to yes, then
ran "/usr/lib/ssh/sshd &".  That let me login remotely from a terminal
window from which I can do cut-and-paste, and I could then do

    # zpool import -R /mnt rpoot

    # format
    Searching for disks...done

    AVAILABLE DISK SELECTIONS:
          0. c4t0d0 
          /pci@0,0/pci1af4,1100@6/disk@0,0
    Specify disk (enter its number): 0

    electing c4t0d0
    [disk formatted]
    /dev/dsk/c4t0d0s0 is part of active ZFS pool rpool. Please see 
zpool(1M).


    FORMAT MENU:
        disk      - select a disk
        type      - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format    - format and analyze the disk
        fdisk      - run the fdisk program
        repair    - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect    - defect list management
        backup    - search for backup labels
        verify    - read and display labels
        save      - save new disk/partition definitions
        inquiry    - show vendor, product and revision
        volname    - set 8-character volume name
        !    - execute , then return
        quit
    format> verify
    Warning: Primary label on disk appears to be different from
    current label.

    Warning: Check the current partitioning and 'label' the disk or use the
        'backup' command.

    Primary label contents:

    Volume name = <        >
    ascii name  = 
    pcyl        = 10442
    ncyl        = 10440
    acyl        =    2
    bcyl        =    0
    nhead      =  255
    nsect      =  63
    Part      Tag    Flag    Cylinders        Size            Blocks
      0      root    wm      1 - 10439      79.97GB    (10439/0/0) 
167702535
      1 unassigned    wm      0                0        (0/0/0)            
0
      2    backup    wu      0 - 10439      79.97GB    (10440/0/0) 
167718600
      3 unassigned    wm      0                0        (0/0/0)            
0
      4 unassigned    wm      0                0        (0/0/0)            
0
      5 unassigned    wm      0                0        (0/0/0)            
0
      6 unassigned    wm      0                0        (0/0/0)            
0
      7 unassigned    wm      0                0        (0/0/0)            
0

      8      boot    wu      0 -    0        7.84MB    (1/0/0)        16065
      9 unassigned    wm      0                0        (0/0/0)            
0


*this* label does make sense. That warning above, what is it about, what 
does

partition -> print tell?

rgds,

Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Reginald Beardsley via openindiana-discuss
 FWIW I saw the messages that Nelson posted at the start of this discussion on 
systems that booted. However, they very likely had relic zfs labels. I've had 
mysterious "corrupted pools" appear which I was only able to fix by using dd(1) 
to wipe out the old label.

I've come to the conclusion that zfs is saving information in places I don't 
know about and which may or may not get cleared by "zpool labelclear".

Once I recover from the ordeal of this past week I'll go back and conduct some 
experiments such as creating a slice, creating a pool and then modifying the 
slice and creating a new pool to see if I can sort out what is happening.

I am very sorry that some of the developers took offense to my posts, but I am 
very pleased that there is more engagement by the users in testing. "It is 
meet, right and our bounden duty..."

Reg


 On Saturday, April 24, 2021, 05:16:59 PM CDT, Toomas Soome via 
openindiana-discuss  wrote:  
 
 

> On 25. Apr 2021, at 00:53, Nelson H. F. Beebe  wrote:
> 
> Toomas Soome mailto:tso...@me.com>> responds today:
> 
>>> ...
 On 24. Apr 2021, at 23:56, Nelson H. F. Beebe  wrote:
 
 Thanks for the additional suggestions to get the CentOS-7 based
 OpenIndiana to boot.  Here is what I get:
 
      boot: status
      disk device:
          disk0:  BIOS driver C (167772160 X 512)
            disk0s1: Solaris 2            79GB
              disk0s1a: root              79GB
              disk0s1i: root            8032KB
>>> 
>>> Why there are two root slices? it should not disturb us but still weird. 
>>> anyhow, can you mail
>>> me full partition table, format -> verify or partition -> print.ole disk
>>> 
>>> Since this is VM and no dual-boot, I recommend to only do whole disk setup 
>>> (that is, GPT
>>> automatically prepared). But for now, I wonder how your current slices are 
>>> defined:)
>>> 
>>> ...
> 
> I booted the failing VM from the CD-ROM, ran "ssh-keygen -A", edited
> /etc/ssh/sshd_config to change PermitRootLogin from no to yes, then
> ran "/usr/lib/ssh/sshd &".  That let me login remotely from a terminal
> window from which I can do cut-and-paste, and I could then do
> 
>     # zpool import -R /mnt rpoot
> 
>     # format
>     Searching for disks...done
> 
>     AVAILABLE DISK SELECTIONS:
>           0. c4t0d0 
>           /pci@0,0/pci1af4,1100@6/disk@0,0
>     Specify disk (enter its number): 0
> 
>     electing c4t0d0
>     [disk formatted]
>     /dev/dsk/c4t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M).
> 
>     FORMAT MENU:
>         disk      - select a disk
>         type      - select (define) a disk type
>         partition  - select (define) a partition table
>         current    - describe the current disk
>         format    - format and analyze the disk
>         fdisk      - run the fdisk program
>         repair    - repair a defective sector
>         label      - write label to the disk
>         analyze    - surface analysis
>         defect    - defect list management
>         backup    - search for backup labels
>         verify    - read and display labels
>         save      - save new disk/partition definitions
>         inquiry    - show vendor, product and revision
>         volname    - set 8-character volume name
>         !    - execute , then return
>         quit
>     format> verify
>     Warning: Primary label on disk appears to be different from
>     current label.
> 
>     Warning: Check the current partitioning and 'label' the disk or use the
>         'backup' command.
> 
>     Primary label contents:
> 
>     Volume name = <        >
>     ascii name  = 
>     pcyl        = 10442
>     ncyl        = 10440
>     acyl        =    2
>     bcyl        =    0
>     nhead      =  255
>     nsect      =  63
>     Part      Tag    Flag    Cylinders        Size            Blocks
>       0      root    wm      1 - 10439      79.97GB    (10439/0/0) 167702535
>       1 unassigned    wm      0                0        (0/0/0)            0
>       2    backup    wu      0 - 10439      79.97GB    (10440/0/0) 167718600
>       3 unassigned    wm      0                0        (0/0/0)            0
>       4 unassigned    wm      0                0        (0/0/0)            0
>       5 unassigned    wm      0                0        (0/0/0)            0
>       6 unassigned    wm      0                0        (0/0/0)            0
>       7 unassigned    wm      0                0        (0/0/0)            0
>       8      boot    wu      0 -    0        7.84MB    (1/0/0)        16065
>       9 unassigned    wm      0                0        (0/0/0)            0

*this* label does make sense. That warning above, what is it about, what does 
partition -> print tell?

rgds,
toomas


> 
> I have to leave soon for the weekend, so likely cannot respond before Monday.
> 
> ---
> - Nelson H. F. Beebe               

Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Toomas Soome via openindiana-discuss



> On 25. Apr 2021, at 00:53, Nelson H. F. Beebe  wrote:
> 
> Toomas Soome mailto:tso...@me.com>> responds today:
> 
>>> ...
 On 24. Apr 2021, at 23:56, Nelson H. F. Beebe  wrote:
 
 Thanks for the additional suggestions to get the CentOS-7 based
 OpenIndiana to boot.  Here is what I get:
 
  boot: status
  disk device:
  disk0:   BIOS driver C (167772160 X 512)
disk0s1: Solaris 2 79GB
  disk0s1a: root   79GB
  disk0s1i: root 8032KB
>>> 
>>> Why there are two root slices? it should not disturb us but still weird. 
>>> anyhow, can you mail
>>> me full partition table, format -> verify or partition -> print.ole disk
>>> 
>>> Since this is VM and no dual-boot, I recommend to only do whole disk setup 
>>> (that is, GPT
>>> automatically prepared). But for now, I wonder how your current slices are 
>>> defined:)
>>> 
>>> ...
> 
> I booted the failing VM from the CD-ROM, ran "ssh-keygen -A", edited
> /etc/ssh/sshd_config to change PermitRootLogin from no to yes, then
> ran "/usr/lib/ssh/sshd &".  That let me login remotely from a terminal
> window from which I can do cut-and-paste, and I could then do
> 
>   # zpool import -R /mnt rpoot
> 
>   # format
>   Searching for disks...done
> 
>   AVAILABLE DISK SELECTIONS:
>  0. c4t0d0 
> /pci@0,0/pci1af4,1100@6/disk@0,0
>   Specify disk (enter its number): 0
> 
>   electing c4t0d0
>   [disk formatted]
>   /dev/dsk/c4t0d0s0 is part of active ZFS pool rpool. Please see 
> zpool(1M).
> 
>   FORMAT MENU:
>   disk   - select a disk
>   type   - select (define) a disk type
>   partition  - select (define) a partition table
>   current- describe the current disk
>   format - format and analyze the disk
>   fdisk  - run the fdisk program
>   repair - repair a defective sector
>   label  - write label to the disk
>   analyze- surface analysis
>   defect - defect list management
>   backup - search for backup labels
>   verify - read and display labels
>   save   - save new disk/partition definitions
>   inquiry- show vendor, product and revision
>   volname- set 8-character volume name
>   ! - execute , then return
>   quit
>   format> verify
>   Warning: Primary label on disk appears to be different from
>   current label.
> 
>   Warning: Check the current partitioning and 'label' the disk or use the
>'backup' command.
> 
>   Primary label contents:
> 
>   Volume name = <>
>   ascii name  = 
>   pcyl= 10442
>   ncyl= 10440
>   acyl=2
>   bcyl=0
>   nhead   =  255
>   nsect   =   63
>   Part  TagFlag Cylinders SizeBlocks
> 0   rootwm   1 - 10439   79.97GB(10439/0/0) 
> 167702535
> 1 unassignedwm   00 (0/0/0)   
>   0
> 2 backupwu   0 - 10439   79.97GB(10440/0/0) 
> 167718600
> 3 unassignedwm   00 (0/0/0)   
>   0
> 4 unassignedwm   00 (0/0/0)   
>   0
> 5 unassignedwm   00 (0/0/0)   
>   0
> 6 unassignedwm   00 (0/0/0)   
>   0
> 7 unassignedwm   00 (0/0/0)   
>   0
> 8   bootwu   0 - 07.84MB(1/0/0) 
> 16065
> 9 unassignedwm   00 (0/0/0)   
>   0

*this* label does make sense. That warning above, what is it about, what does 
partition -> print tell?

rgds,
toomas


> 
> I have to leave soon for the weekend, so likely cannot respond before Monday.
> 
> ---
> - Nelson H. F. BeebeTel: +1 801 581 5254  
> -
> - University of UtahFAX: +1 801 581 4148  
> -
> - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu 
>   -
> - 155 S 1400 E RM 233   be...@acm.org 
>   be...@computer.org  -
> - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ 
>  -
> ---

___
openindiana-discuss mailing list

Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Nelson H. F. Beebe
Toomas Soome  responds today:

>> ...
>> > On 24. Apr 2021, at 23:56, Nelson H. F. Beebe  wrote:
>> >
>> > Thanks for the additional suggestions to get the CentOS-7 based
>> > OpenIndiana to boot.  Here is what I get:
>> >
>> >   boot: status
>> >   disk device:
>> >   disk0:   BIOS driver C (167772160 X 512)
>> > disk0s1: Solaris 2 79GB
>> >   disk0s1a: root   79GB
>> >   disk0s1i: root 8032KB
>> 
>> Why there are two root slices? it should not disturb us but still weird. 
>> anyhow, can you mail
>> me full partition table, format -> verify or partition -> print.ole disk
>> 
>> Since this is VM and no dual-boot, I recommend to only do whole disk setup 
>> (that is, GPT
>> automatically prepared). But for now, I wonder how your current slices are 
>> defined:)
>> 
>> ...

I booted the failing VM from the CD-ROM, ran "ssh-keygen -A", edited
/etc/ssh/sshd_config to change PermitRootLogin from no to yes, then
ran "/usr/lib/ssh/sshd &".  That let me login remotely from a terminal
window from which I can do cut-and-paste, and I could then do

# zpool import -R /mnt rpoot

# format
Searching for disks...done

AVAILABLE DISK SELECTIONS:
   0. c4t0d0 
  /pci@0,0/pci1af4,1100@6/disk@0,0
Specify disk (enter its number): 0

electing c4t0d0
[disk formatted]
/dev/dsk/c4t0d0s0 is part of active ZFS pool rpool. Please see 
zpool(1M).

FORMAT MENU:
disk   - select a disk
type   - select (define) a disk type
partition  - select (define) a partition table
current- describe the current disk
format - format and analyze the disk
fdisk  - run the fdisk program
repair - repair a defective sector
label  - write label to the disk
analyze- surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save   - save new disk/partition definitions
inquiry- show vendor, product and revision
volname- set 8-character volume name
! - execute , then return
quit
format> verify
Warning: Primary label on disk appears to be different from
current label.

Warning: Check the current partitioning and 'label' the disk or use the
 'backup' command.

Primary label contents:

Volume name = <>
ascii name  = 
pcyl= 10442
ncyl= 10440
acyl=2
bcyl=0
nhead   =  255
nsect   =   63
Part  TagFlag Cylinders SizeBlocks
  0   rootwm   1 - 10439   79.97GB(10439/0/0) 
167702535
  1 unassignedwm   00 (0/0/0)   
  0
  2 backupwu   0 - 10439   79.97GB(10440/0/0) 
167718600
  3 unassignedwm   00 (0/0/0)   
  0
  4 unassignedwm   00 (0/0/0)   
  0
  5 unassignedwm   00 (0/0/0)   
  0
  6 unassignedwm   00 (0/0/0)   
  0
  7 unassignedwm   00 (0/0/0)   
  0
  8   bootwu   0 - 07.84MB(1/0/0) 
16065
  9 unassignedwm   00 (0/0/0)   
  0

I have to leave soon for the weekend, so likely cannot respond before Monday.

---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Toomas Soome via openindiana-discuss



> On 24. Apr 2021, at 23:56, Nelson H. F. Beebe  wrote:
> 
> Thanks for the additional suggestions to get the CentOS-7 based
> OpenIndiana to boot.  Here is what I get:
> 
>   boot: status
>   disk device:
>   disk0:   BIOS driver C (167772160 X 512)
> disk0s1: Solaris 2 79GB
>   disk0s1a: root   79GB
>   disk0s1i: root 8032KB


Why there are two root slices? it should not disturb us but still weird. 
anyhow, can you mail me full partition table, format -> verify or partition -> 
print.ole disk 

Since this is VM and no dual-boot, I recommend to only do whole disk setup 
(that is, GPT automatically prepared). But for now, I wonder how your current 
slices are defined:)

rgds,
toomas

> 
>   illumos/x86 boot
>   Default: /boot/loader
>   boot: ?/
> 
>   illumos/x86 boot
>   Default: /boot/loader
> 
> I propose that we drop this one for now, unless someone has deeper
> insight into how to recover from this failed installation.
> 
> There is more information on the boot loader at
> 
>   https://illumos.org/man/5/loader
> 
> but none of the few commands documented there worked for me.
> 
> Next week, I'll retry an OpenIndiana installation with the OVirt
> alternative on CentOS 7; I may also play with different disk types on
> virt-manager.  The disk is currently SATA, but IDE, SCSI, USB, and
> VirtIO are also possible (though USB isn't a candidate).
> 
> I can also report that the big package update (300+) that I ran today
> on the OpenIndiana system on Ubuntu 20.04 was problem free, and the
> system has been rebooted twice since, to make a virt-manager snapshot,
> as well as a ZFS snapshot.  On this system, as on our many other
> ZFS-based O/Ses, I have cron jobs that take daily snapshots, and the
> VM disk images themselves are backed-up nightly to LTO-8 tape, and to
> a remote datacenter.
> 
> ---
> - Nelson H. F. BeebeTel: +1 801 581 5254  
> -
> - University of UtahFAX: +1 801 581 4148  
> -
> - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  
> -
> - 155 S 1400 E RM 233   be...@acm.org  be...@computer.org 
> -
> - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ 
> -
> ---


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Nelson H. F. Beebe
Thanks for the additional suggestions to get the CentOS-7 based
OpenIndiana to boot.  Here is what I get:

boot: status
disk device:
disk0:   BIOS driver C (167772160 X 512)
  disk0s1: Solaris 2 79GB
disk0s1a: root   79GB
disk0s1i: root 8032KB

illumos/x86 boot
Default: /boot/loader
boot: ?/

illumos/x86 boot
Default: /boot/loader

I propose that we drop this one for now, unless someone has deeper
insight into how to recover from this failed installation.

There is more information on the boot loader at

https://illumos.org/man/5/loader

but none of the few commands documented there worked for me.

Next week, I'll retry an OpenIndiana installation with the OVirt
alternative on CentOS 7; I may also play with different disk types on
virt-manager.  The disk is currently SATA, but IDE, SCSI, USB, and
VirtIO are also possible (though USB isn't a candidate).

I can also report that the big package update (300+) that I ran today
on the OpenIndiana system on Ubuntu 20.04 was problem free, and the
system has been rebooted twice since, to make a virt-manager snapshot,
as well as a ZFS snapshot.  On this system, as on our many other
ZFS-based O/Ses, I have cron jobs that take daily snapshots, and the
VM disk images themselves are backed-up nightly to LTO-8 tape, and to
a remote datacenter.

---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Toomas Soome via openindiana-discuss


> On 24. Apr 2021, at 22:52, Nelson H. F. Beebe  wrote:
> 
> [This is temporarily off the openindiana-discuss mailing list]
> 
> You wrote on Sat, 24 Apr 2021 11:58:06 -0400
> 
>>> That is after the boot loader menu.
>>> The second page of loader includes an option to boot from alt BEs.
> 
> If I use the virt-manager menu to send Ctl-Alt-Del, I get this output:
> 
>   Press ESC for boot menu.
> 
> I quickly press ESC, producing:
> 
>   1. AHCI/0: QEMU HARDDISK ...
>   2. DVD/CD ...
>   3. Legacy option rom
>   4. iPXE ...
> 
> I press 1 and get
> 
>   Booting from Hard Disk...
>   BIOS drive C: is disk0
>   ZFS: i/o error - all block copies unavailable
>   ZFS: can't read MOS of pool rpool
> 
>   Can't find /boot/loader
> 
>   Can't find /boot/zfsloader
> 
>   illumos/x86 boot
>   Default: /boot/loader
>   boot:
> 
> At that point, I no idea how to get to a ``second page of loader
> options.''
> 


At that point, you can’t. You got to boot loader stage1 program (gptzfsboot) 
and its prompt (boot: prompt). It is failing to read zfs pool to load and start 
next stage - /boot/loader). At this point, only simple diagnostics is possible 
- you can enter: status to get list of disks and ?path (like ?/) to get 
directory listing from path. Also you can enter alternate file name to be 
loaded and alternate disk device to load from. See also gptzfsboot(5).

I can not guess what does trigger this situation, but one option is to start 
from alternate media (usb/iso), and check out what is going on there - what 
does zpool scrub tell etc.

rgds,
toomas

> The boot prompt is opaque: it only prompts again when I try input like
> "?", "help", "boot", ESCape, F1, F2, ..., F12, PageUp, PageDown, 
> 
> I find it often aggravating that BIOS code is so low level and
> unusable without a separate manual.
> 
> ---
> - Nelson H. F. BeebeTel: +1 801 581 5254  
> -
> - University of UtahFAX: +1 801 581 4148  
> -
> - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  
> -
> - 155 S 1400 E RM 233   be...@acm.org  be...@computer.org 
> -
> - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ 
> -
> ---
> 
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread Nelson H. F. Beebe
[This is temporarily off the openindiana-discuss mailing list]

You wrote on Sat, 24 Apr 2021 11:58:06 -0400

>> That is after the boot loader menu.
>> The second page of loader includes an option to boot from alt BEs.

If I use the virt-manager menu to send Ctl-Alt-Del, I get this output:

Press ESC for boot menu.

I quickly press ESC, producing:

1. AHCI/0: QEMU HARDDISK ...
2. DVD/CD ...
3. Legacy option rom
4. iPXE ...

I press 1 and get

Booting from Hard Disk...
BIOS drive C: is disk0
ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool rpool

Can't find /boot/loader

Can't find /boot/zfsloader

illumos/x86 boot
Default: /boot/loader
boot:

At that point, I no idea how to get to a ``second page of loader
options.''

The boot prompt is opaque: it only prompts again when I try input like
"?", "help", "boot", ESCape, F1, F2, ..., F12, PageUp, PageDown, 

I find it often aggravating that BIOS code is so low level and
unusable without a separate manual.

---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] The kiss of death

2021-04-24 Thread John D Groenveld
In message , "Nelson H. F. 
Beebe" writes:
>in the Solaris family.  We tried to find a way to get past the boot
>failure on CentOS 7.9.2009, which I reported yesterday said
>
>Loading unix...
>Loading /platform/i86pc/amd64/boot_archive...
>ZFS: i/o error - all block copies available
>...
>No rootfs module provided, aborting
>
>That happens early in the boot process, well before there is any
>chance to try to revert to an earlier boot environment.  Despite Web

That is after the boot loader menu.
The second page of loader includes an option to boot from alt BEs.

John
groenv...@acm.org

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] April May snapshot

2021-04-24 Thread aurelien . larcher


Le Samedi 24 avril 2021, Andreas Wacknitz a écrit :
> Am 16.04.21 um 14:39 schrieb bscuk2:
> >
> >
> >
> >
> >  Forwarded Message 
> > Subject: April May snapshot
> > Date: Thu, 15 Apr 2021 14:58:45 +
> > From:
> > To: openindiana-discuss@openindiana.org
> >
> >
> >
> > Hello All,
> >
> > Wallpapers to be included in next snapshot. I have done a basic
> > wallpaper for the next snapshot. I was interested if it would be
> > included in the next snapshot. Usually it would be a png image but I am
> > unable to understand what size it should be.
> >
> > Let me know what you think.
> >
> > Robert
> >
> > https://wiki.openindiana.org/oi/Image+Gallery?preview=/1474670/70156307/VISION21.PNG
> >
> >
> > ___
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
> Which one do you want to be included? It would be helpful to create a PR
> for it.
> 
> Andreas

For reference the repository is at:

https://github.com/OpenIndiana/openindiana-backgrounds


> 
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] April May snapshot

2021-04-24 Thread Andreas Wacknitz

Am 16.04.21 um 14:39 schrieb bscuk2:





 Forwarded Message 
Subject: April May snapshot
Date: Thu, 15 Apr 2021 14:58:45 +
From:
To: openindiana-discuss@openindiana.org



Hello All,

Wallpapers to be included in next snapshot. I have done a basic
wallpaper for the next snapshot. I was interested if it would be
included in the next snapshot. Usually it would be a png image but I am
unable to understand what size it should be.

Let me know what you think.

Robert

https://wiki.openindiana.org/oi/Image+Gallery?preview=/1474670/70156307/VISION21.PNG


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Which one do you want to be included? It would be helpful to create a PR
for it.

Andreas

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Re: [OpenIndiana-discuss] mate desktop 1.25 release

2021-04-24 Thread Andreas Wacknitz

Am 24.04.21 um 11:24 schrieb bscuk2:

Dear All,

I was wondering if we should expect a new version of the mate desktop
1.25 sometime soon. This is about the right time of year all be it it
probably experienced a time delay due to CV19. I noted some snippets
labelled 1.25 for developers?

Has anyone a idea about the version schedule this year ?

Regards,


Robert

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Mate uses even version numbers for stable releases. So the next Mate
version will be 1.26. You can check
https://repology.org/repository/openindiana for outdated package
versions for OpenIndiana. And if you want something updated a PR is
quite helpful.

Andreas

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


[OpenIndiana-discuss] mate desktop 1.25 release

2021-04-24 Thread bscuk2

Dear All,

I was wondering if we should expect a new version of the mate desktop 
1.25 sometime soon. This is about the right time of year all be it it 
probably experienced a time delay due to CV19. I noted some snippets 
labelled 1.25 for developers?


Has anyone a idea about the version schedule this year ?

Regards,


Robert

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss