[OpenIndiana-discuss] [openindiana-discuss] new gparted release
In view of problems reported on this list with gparted on OpenIndiana, perhaps some list members would like to try the new version announced this past Monday: https://gparted.org/news.php?item=238 Its release notes are at https://sourceforge.net/projects/gparted/files/gparted/gparted-1.3.0/gparted-1.3.0-README.md/view --- - 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] OI-hipster-gui-20210430.iso progress report on 3 virtualization system
I've now made installation attempts with the OI-hipster-gui-20210430.iso image on these three virtualization systems: * CentoS 7.9virt-manager/QEMU * Ubuntu 20.04 virt-manager/QEMU * Ubuntu 20.04 VirtualBox Each VM is given 4GB DRAM, 4 CPUs, and 80GB disk; the latter is not partitioned, so ZFS uses the entire disk. The disk image file is newly created, and so should have nothing but zero blocks. On all three, the GUI installer worked as expected, and I selected a time zone (America/Denver), created one ordinary user account, and supplied a root password. Installation completed normally, and the systems rebooted. On the CentOS-based VM, the one on which I reported boot problems before, after the system rebooted, I logged in, used the network GUI tool to change to static IPv4 addressing, made one ZFS snapshot, ran "sync" (twice) then "poweroff", then took a virt-manager snapshot. On the next reboot, I again got a similar problem to what I reported previously. ZFS: i/o error - all block copies unavailable ZFS: failed to read pool rpool directory object On the Ubuntu virt-manager VM, reboots are problem free, and the VM is fully configured with a large number of installed packages, and is working nicely as part of our test farm. The Ubuntu VirtualBox VM built normally. and rebooted normally, so I took a ZFS snapshot, rebooted, and started to install packages: it seems normal so far. I'm not going to spend time trying to resurrect the VM on CentOS 7, but I'm still willing to try building on that system additional VMs from newer ISO releases for OpenIndiana Hipster. One might be inclined to consider the CentOS-based VM as an example of failure, or bugs, inside the host O/S, or inside QEMU, or perhaps even the physical workstation (a 2015-vintage HP Z440 with 128GB DRAM, and several TB of disk storage, both EXT4 and ZFS). However, that machine runs 80 to 100 simultaneous VMs with other O/Ses, and has been rock solid in its almost six years of service. That would tend to exonerate the hardware, and virt-manager/QEMU, suggesting that something inside OpenIndiana is causing the problem. However, the success of two other VMs from the same ISO image indicates that OpenIndiana is solid. My workstation is essentially one-of-a-kind, so there is no way for me to see whether an apparently identical box from the same vendor would also experience failure of an OpenIndiana VM. --------------- - 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] Why networking not work?
"L. F. Elia" asks about networking on VirtualBox. We too found its behavior different from other virtualization systems, and I tend to write copious notes about machine issues. Here is a fragment of those notes, with generalized hostnames: The network setup on VirtualBox on vboxhost.example.com is unusual: its initial network is not bidirectional! It only connects outbound. In order to get inbound connections for ssh, it is necessary to add a second network adapter, which can only be down in powered-off state: VirtualBox control panel -> Settings -> Network -> Adapter2 -> Attached-to -> Host-only adapter Name: vboxnet0 plus Advanced -> Adapter Type -> Intel PRO/1000 MT + Promiscuous Mode: Deny + Cable Connected For the original Adapter1, we have VirtualBox control panel -> Settings -> Network -> Adapter1 -> Attached-to -> NAT plus Advanced -> Adapter Type -> Intel PRO/1000 MT + Promiscuous Mode: Deny + Cable Connected + Port Forwarding On a reboot, the VM will have two networks, like this example for guest.example.com: % ifconfig -a em0: flags=8843 metric 0 mtu 1500 options=85059b ether 08:00:27:f2:0b:cc inet 10.0.2.15 netmask 0xff00 broadcast 10.0.2.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=85059b ether 08:00:27:36:0b:70 inet 192.168.56.101 netmask 0xff00 broadcast 192.168.56.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active ... sshd normally listens on all network interfaces, so from the VirtualBox host, vboxhost.example.com, I can now do ssh USER@192.168.56.101 and with suitable $HOME/.ssh/config settings, such as this on anotherhost.example.com, Host = guest.example.com guest User = jones HostName = 192.168.56.101 ProxyJump vboxhost.example.com I can now ssh from anotherhost to the VM on VirtualBox on vboxhost. --------------- - 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] TeX Live 2021 available for OpenIndiana
I'm pleased to announce that the progress of the last couple of weeks in creating new OpenIndiana virtual machines on VirtualBox, virt-manager/QEMU, and OVirt/QEMU, has made it possible to do complete builds, both 32-bit and 64-bit, of TeX Live 2021. They are available at these equivalent sites: http://www.math.utah.edu/pub/texlive-utah/ https://www.math.utah.edu/pub/texlive-utah/ ftp://ftp.math.utah.edu/pub/texlive-utah/ The ftp:// one, however does not display the README.html file that the other two do. The first section gives instructions on installing TeX Live 2021, with links to another page on how to validate the download. Later sections describe the build procedures and reports for various systems. The direct link https://www.math.utah.edu/pub/texlive-utah/#openindiana-i86pc takes you to the subsections for OpenIndiana. This year, because of decreasing desktop demand for the Solaris family, the DVDs and ISO image are not likely to include binary executables for those systems, but they are trivial to fetch and install from our site, which is also the North American master mirror for both CTAN (Comprehensive TeX Archive Network) and for TeX Live. If you decide to install TeX Live 2021 on your system, be forewarned that you must pick at least one binary platform in the B menu produced by install-tl; any one will do. You can pre- or post-populate the $prefix/texlive/2021/bin directory with either, or both, OpenIndiana directories. After installation, you can remove any directories under the bin directory that your system cannot use. The OpenIndiana package system does not have TeX Live at all, and the OpenCSW package system (in /opt/csw) has only an ancient one, from 2012. There have been yearly releases of TeX Live since at least 2003, and there are a lot of changes each year, although TeX and METAFONT remain quite stable. This year, both programs, and their five-volume book series, have had updates: see https://tug.org/TUGboat/tb42-1/tb130knuth-tuneup21.pdf The changes, however, deal with rare corner cases that almost no real document would ever hit, so the new TeX's output should not differ from that from older versions. --- - 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] OI-hipster-gui-20210405.iso and OVirt/QEMU status report
This report follows earlier ones under the subject "The kiss of death" that supplied installation reports for virt-manager/QEMU on CentOS 7 and Ubuntu 20.04, and VirtualBox on another Ubuntu 20.04 system. This one is fairly positive, so I felt it deserved a new subject line. Today, I successfully installed OpenIndiana Hipster from http://dlc.openindiana.org/isos/hipster/test/OI-hipster-gui-20210405.iso on OVirt/QEMU running on CentOS Linux release 7.6.1810 (Core). As I noted in an earlier report, this virtualization system has the advantage of live VM migration, at a cost of considerably more complex VM creation and management. However, once a VM has been successfully installed, the platform has been rock solid, and we routinely use the VM migration feature to move VMs off one server to another, run system updates on the first, reboot, and move back its VMs, without the VMs even noticing their two moves. I took both OVirt snapshots and ZFS snapshots during the installation steps, with multiple reboots, and have now successfully copied over /var/opt, /opt/csw, and $prefix/texlive/2021 trees from other systems. No boot problems have been observed this time. However, there are a few other problems with OpenIndiana Hipster on OVirt: (1) Ovirt offers three console types: QXL (default), VGA, and CIRRUS. With QXL, the GUI desktop is too high to fit on the screen. Moving the mouse near the bottom edge slides up the display to make the bottom task bar visible. Moving the mouse near the top edge makes the top menu bar only partly visible. However, in neither case can the mouse select icons. I shut down the system, changed to VGA, and found the same behavior as with QXL. I again shut down the system, changed to CIRRUS, rebooted, logged in, and now the screen is fully visible, but the mouse cannot select actions from the menu bar or tool bar. Curiously, moving the mouse over a toolbar item, such as the network icon, produces a yellow popup window that describes the button. One just cannot select it. With all three video types, there are generally two mouse cursors on the screen, but with CIRRUS, they remain within 5mm of each other. Those mouse problems make the desktop almost unusable. With the mouse in the central region of the screen, I can get a popup menu from which I can start a terminal. However, the Applications / Places / System / Network / ... menu bar items are unusable. Unlike VirtManager and VirtualBox, which have menu buttons to send Ctl-Alt-Fn and Ctl-Alt-DELete input to the VM, the OVirt button can only send Ctl-Alt-DELete, so there is no way to select alternate consoles that are supported by most operating systems. With another VM installed on virt-manager/QEMU on Ubuntu 20.04, there were no such icon selection problems, and I was able to reconfigure that system for static IPv4 addressing. If someone knows what program is started by clicking on the network menubar icon, please report it; I've never had much success with manual changes to files in the /etc/ tree on Solaris family systems to switch between DHCP-assigned and static IP addresses. (2) During the installation, I selected Denver, CO, USA, from the world map, and it definitely showed that choice in the text bar under the map. However, when the system rebooted, the timezone was still UTC, the clock was off by hours, and /etc/localtime did not exist. The OVirt control panel shows the clock should be a hardware clock set to "(GMT-00:00) GMT Standard Time". I fixed that problem by # ln -s /usr/share/lib/zoneinfo/America/Denver /etc/localtime # ntpdate time1.google.com After fixing those issues, creating users accounts (more snapshots), I ran # pkg install build-essential # pkg update # sync # sync # poweroff I made another OVirt snapshot, powered on, and the system is now ready for use. ----------- - 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
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 unassigned wm 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
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
[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
[OpenIndiana-discuss] OI-*20210405.iso installer difference
I reported yesterday on the 15-character limit in the text installer's domain name question, and easily fixed affected files in the /etc tree. I noticed another difference today. The GUI installer asks nothing about networking, and just assumes DHCP, whereas the text installer asks whether dynamic or static IP addressing is desired. At our site, we always assign static addresses, so we have two-way communication with all machines, and can record $HOME/.ssh/config entries with known addresses, even if there are one or more ProxyJump steps needed to reach one machine from another. We have several isolated private networks that otherwise are invisible to one another, except through strictly regulated gateway machines. Once the OpenIndiana GUI installer completed, I logged in, run the network configuration tool from the top toolbar icon, and switched to static addressing. When the tool exited, the IP address was instantly correct. By contrast, on most Linux systems, in my experience, a reboot is normally required after a similar change. Still, it would be nice if an optional network configuration step could be added to the OpenIndiana GUI installer ISO image. --- - 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/ - --- --- - 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
e all of the Solaris family O/Ses. In 15+ years of ZFS and hundreds of TB of storage, we have never lost data from filesystem corruption or disk failures. We would like to see that record of solidity continue with OpenIndiana. --------------- - 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/ - --- --------------- - 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
Following my report a few minutes ago of a failure to reboot after package updates, Volker A. Brandt kindly suggested a recovery attempt like this: # zfs list -tall # mkdir /tmp/mypool # zpool import -R /tmp/mypool rpool That showed that the installed files from the pkg system are there, so I ran # zpool export # reboot However, that brings me back to the boot prompt with the old complaint 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 I forgot to mention in my earlier report that in the text-mode install, I chose MBR booting, rather than UEFI; the latter does not work on the QEMU version available on CentOS 7. Ideas of what to do next? ----------- - 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
After my last message, I ran "pkg install" on the OpenIndiana VM created from the text-mode installer on CentOS 7.9.2009, to get gcc, build-essential, and a few other packages installed. That went as expected. I then ran # pkg update # pkg upgrade That updated 347 packages and 8074 files, then reported A clone of openindiana exists and has been updated and activated. On the next boot the Boot Environment openindiana-2021:04:22 will be mounted on '/'. Reboot when ready to switch to this updated BE. I typed # reboot and the system came partly up with Loading unix... Loading /platform/i86pc/amd64/boot_archive... ZFS: i/o error - all block copies available ... No rootfs module provided, aborting The VM was allocated an 80GB disk, 2GB DRAM, and 2 CPUs, and the physical CentOS 7.8.2009 host has 1.8TB free space. I powered off the VM, increased the DRAM from 2GB to 8GB, and retried, but behavior is identical. Another attempt with 1 CPU and 32GB DRAM got the same failure. I powered off, rebooted from the ISO image, logged in as root/openindiana, and ran # zpool import # df -h /rpool FilesystemSize UsedAvailable Capacity Mounted on rpool 77.02G 33K70.01G1% /rpool # ls /rpool boot # ls /rpool/boot grub menu.lst So, the disk looks like it has almost been wiped clean, which should not be the case after all of the package updating. Things were not this bad with earlier OpenIndiana releases over the last almost 11 years, back to my first VM for this O/S created on 14-Sep-2010 from oi-dev-147-x86.iso. ----------- - 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
Following my report earlier today of problems installing the latest OpenIndiana ISO GUI installer on CentOS 7.9.2009, I next downloaded http://dlc.openindiana.org/isos/hipster/test/OI-hipster-text-20210405.iso and that led to a successful installation on CentOS 7.9.2009 with virt-manager 1.5.0 and qemu-system-x86_64 2.0.0. There was one nit: at the point that it asks for a domain name, it cuts it off at 15 characters, which is way too small. See https://www.ietf.org/rfc/rfc1035.txt https://en.wikipedia.org/wiki/Hostname https://web.archive.org/web/20190518124533/https://devblogs.microsoft.com/oldnewthing/?p=7873 The limit for the domain name field should be 252 (allowing a one-byte count, one-byte hostname, and dot for the unqualified hostname), so the total fully-qualified domain name string is less than 256 bytes. In my case, my required domain name is "vm.math.utah.edu", one longer than the OpenIndiana installer permits. Presumably I can fix this trivially in files in the /etc tree after installation. During installation, I assigned a static IPv4 address, and when the system later rebooted, it gave me a text console, but no startx or xstart or xinit to bring up a window system. I can successfully login to the new VM via ssh from another system. Presumably, I could continue to configure this system, and perhaps later, add enough X11 packages to get a desktop. However, I'm delaying that for now. Next, I ran the GUI installer from http://dlc.openindiana.org/isos/hipster/test/OI-hipster-gui-20210405.iso on Ubuntu 20.04, which has virt-manager 2.2.1 and qemu-system-x86_64 4.2.1, considerably newer than available on CentOS 7.9.2009. The GUI installation proceeded as expected, with no mouse problems like I met on CentOS, but it quickly reached a panel complaining about two missing device drivers, highlighting them in pink: Audio Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio ControllerMisconfigured:[audiohd] Red Hat, Inc. Virtio consoleUNK Info It will not proceed when I press the Install button, reporting in a popup: Add Driver Driver not installed The driver package is empty Close I have no idea what driver package is expected there, so there is nothing to do but abort the installer. I don't have audio on any of my 500+ VMs, and given that the installer desktop screen looks normal, it is puzzling why the GUI installer thinks a console driver is missing. I may be able to repeat these experiments next week on VirtualBox on another system on campus; this week, I working from home. ----------- - 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
Today, I downloaded http://dlc.openindiana.org/isos/hipster/test/OI-hipster-gui-20210405.iso and attempted to create a new VM on CentOS 7.9.2009 with virt-manager 1.5.0 and qemu-system-x86_64 2.0.0. The initial BIOS screen comes up, asks for a keyboard type, and proceeds to display a nice GUI. However, I have two cursors on the display: one frozen (and the one needed to do selections), and the other movable, but whose selection clicks are ignored. No progress is possible. I'm next going to try the text mode installer, and the GUI mode on an Ubuntu 20.04 system. More later... --- - 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
John D Groenveld asks today >> Can you install from the latest installation media on that PC? >> http://dlc.openindiana.org/isos/hipster/test/> There are a lot of recent discussions on this list about installation problems on particular hardware systems, but not a much mention of routine test installations on virtualization hypervisors, like bhyve, Parallels, OVirt/QEMU, virt-manager/QEMU, VirtualBox, VMware ESX, and Xen. At my site, we have a test farm with hundreds of VMs, primarily on OVirt and virt-manager, with one small system capable of supporting just one or two simultaneous VMs on VirtualBox. I have had at least 8 instances of various releases of OpenIndiana and Hipster, plus more VMS with the relatives OmniOS, OmniTribblix, Sun/Oracle Solaris, Tribblix, Unleashed, and XstreamOS, mostly on the QEMU-based hypervisors. Several classes of installer bugs have afflicted some of the VMs that we run, or have tried to install: (a) uncontrollable streaming garbage input on the console device, making correct typein almost impossible; (b) black screen-of-death on the console at boot time; (c) random patterns of green and red lines on the console (hiding all text); (d) failure of the mouse to track the screen cursor, sometimes showing two cursors, one of which cannot reach certain portions of the screen; (e) installer screens with critical buttons lying off the visible console screen, and no resizing possible; (f) boot wait times that are too short to get to the BIOS setup before booting starts (on OVirt, it can take 20 to 30 seconds after a power-on before the console is visible, by which time a lot of early output is lost). Are openindiana developers on this list willing to post a list of VMs on which candidate ISO images have been tested before end users try to install them on physical machines? It seems to me that such testing should be normal these days, given the extreme low cost of virtualization --- I personally run more than 80 VMs simultaneously on each of my home and campus office workstations. I will make an effort over the next few days to try some of the latest ISO images from the Web site above on some of our virtualization platforms. ----------- - 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] SMF and X11 startup problem
Reginald Beardsley asks on the list today: >> Does anyone know what the missing environment variable is or >> where the reference to >> /usr/X11/lib/modules/extensions//libglx.so >> is located? On a Fedora 33 Linux system, I find that library in /usr/lib64/xorg/modules/extensions/libglx.so On an Oracle Solaris 11 systems, I find it in two locations: /usr/lib/mesa/modules/extensions/libglx.so /usr/lib/xorg/modules/extensions/libglx.so On a Sun Solaris 10 system, I find several copies /usr/X11/lib/modules/extensions/amd64/libglx.so /usr/X11/lib/modules/extensions/libglx.so /usr/X11/lib/modules/extensions/mesa/amd64/libglx.so /usr/X11/lib/modules/extensions/mesa/libglx.so /usr/X11/lib/modules/extensions/NVIDIA/amd64/libglx.so /usr/X11/lib/modules/extensions/NVIDIA/amd64/libglx.so.1 /usr/X11/lib/modules/extensions/NVIDIA/libglx.so /usr/X11/lib/modules/extensions/NVIDIA/libglx.so.1 /var/run/opengl/server/amd64/libglx.so /var/run/opengl/server/libglx.so Thus, I suspect that the double slash that you reported is innocuous, and valid, because in the V6 Unix kernel documented in John Lyons' book, the path traveral has something like while (*s == '/') s++; instead of if (*s == '/') s++; I found that snippet several years ago when we were writing Classic Shell Scripting, and we wanted to know if adjacent slashes in a pathname are legal: the V6 code shows that the answer is yes. Of course, the Solaris 10 system also shows intervening mesa and NVIDIA components, so it certainly is worth checking whether a simple symlink will allow the library to be found. ----------- - 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 name of a new (?) OS
Apostolos asks about a recent posting about an operating system that begins with R: I think he is searching for ReactOS, which is an independent clean-room implementation of Microsoft Windows: https://reactos.org/what-is-reactos/ I have created a couple of VMs for it, but do not run it regularly. --- - 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] Vbox and nwam -no vboxnet0 ?
Tony Brian Albers asks today about networking problems on VirtualBox on OpenIndiana. I've only run VirtualBox on Ubuntu systems, but the following comments should still apply. I found that VirtualBox behaves differently compared to other virtualization systems, like OVirt, VirtManager/QEMU, and VMware/ESX, in that VirtualBox needs separate connections for inbound and outbound networking. From notes I recorded over the last two years: >> ... >> The network setup on VirtualBox on is unusual: its initial network >> is not bidirectional! It only connects outbound. >> >> In order to get inbound connections for ssh, it is necessary to add a >> second network adapter, which can only be down in powered-off state: >> >> VirtualBox control panel -> >> Settings -> Network -> Adapter2 -> Attached-to -> Host-only >> adapter >> Name: vboxnet0 >> >> plus >> Advanced -> >> Adapter Type -> Intel PRO/1000 MT + >> Promiscuous Mode: Deny + >> Cable Connected >> >> For the original Adapter1, we have >> >> VirtualBox control panel -> >> Settings -> Network -> Adapter1 -> Attached-to -> NAT >> plus >> Advanced -> >> Adapter Type -> Intel PRO/1000 MT + >> Promiscuous Mode: Deny + >> Cable Connected + >> Port Forwarding >> >> On a reboot, the VM will have two networks, like this for >> yyy.vm.example.com: >> >> % ifconfig -a >> em0: flags=8843 metric 0 mtu >> 1500 >> >> options=85059b >> ether 08:00:27:f2:0b:cc >> inet 10.0.2.15 netmask 0xff00 broadcast 10.0.2.255 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> em1: flags=8843 metric 0 mtu >> 1500 >> >> options=85059b >> ether 08:00:27:36:0b:70 >> inet 192.168.56.101 netmask 0xff00 broadcast >> 192.168.56.255 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> ... >> >> sshd normally listens on all network interfaces, so from the >> VirtualBox host, xxx.example.com, I can now do >> >> ssh USER@192.168.56.101 >> >> The VirtualBox File -> Host Network Manager -> Properties display show >> >> vboxnet0192.168.56.1/24 >> >> with a DHCP Server panel at the screen bottom that says >> >> Server address 192.168.56.100 >> Server mask 255.255.255.0 >> Lower Address Bound 192.168.56.101 >> Upper Address Bound 192.168.56.254 >> >> The first Ethernet adapter should be a DHCP-assigned value, and the >> second for VirtualBox VMs should be a STATIC address of the form >> 192.168.56.x, where x is in [2,99]. >> >> The default router is set by DHCP to 10.0.2.2, so it should NOT be set >> in /etc configuration files. >> ... --- - 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] Tasks to focus on
Aurelien Larcher kindly posted his OpenIndiana project list from last spring in e-mail on this list of Thu, 7 Jan 2021 22:39:12 +0100. Among your projects from March 2020, I believe strongly that the most important BY FAR is getting gcc-10 to build itself and all of the OpenIndiana / Omnios software suite. Once that is done, then gcc-11 should be a breeze (I've personally done several thousand builds of gcc-x for x in 2--11). Those compilers can then bootstrap LLVM / Clang compilers. Absolutely EVERYTHING ELSE is contingent on having reliable and modern C and C++ compilers (and also Ada, D, Java (gcc-6 and earlier only), Fortran, Objective C/C++, Pascal, ). Those can then build new gcc-go, Rust, awk / mawk / gawk, Javascript, pcc, Python, tcc, releases. Google Go was originally written in C, but two or three years ago, it was rewritten in Go, with a C-based bootstrap compiler used to get the process rolling. The GNU Ada translator (gnat) has a similar bootstrap problem, because part of gnat after gcc-4.x was foolishly rewritten in Ada itself, instead of being kept in portable Standard C that can be built pretty much anywhere, and also made available in new CPU environments as new compiler backends are written (e.g,, ARM and RISC-V in recent years). That makes porting software and O/Ses to new CPU platforms much easier. I've been using Unix systems for almost 40 years, and have a farm of more than 500 flavors of such for most of the main CPU families. Old vendor-supplied compiler versions have caused huge pain in Red Hat, CentOS, Solaris, and OpenBSD, because they make it impossible to build a lot of newer software. While I'm often able to build newer gcc and clang releases, most computer users are completely stuck with what the vendor or O/S distribution provides, and could not possibly build gcc or clang on their own. ----------- - 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] Installation in KVM for OSS porting
Gerhard reports on Mon, 19 Oct 2020 13:39:35 +0200: >> I installed OI-Hipster 2020.04 from DVD image in a KVM on Ubuntu-18.04. >> this was tricky because something poisoned the text fields with escape >> sequence ^[[210z every two seconds or so - challenging in the password >> fields... I too have seen that on several Solaris-family systems installed on VMs, and I later found a workaround that I recorded about four years ago in my system notes: >> ... >> One thing that plagued me during the initial console installation was >> the bogus, and rapid, generation of unwanted ESC-[210z input >> characters interspersed with normal keyboard input. That made it >> EXTREMELY difficult to type commands in the console window, or even to >> login. >> >> We later found identical problems with other OpenSolaris-based systems >> (Dyson, Illumian, Tribblix, and XStreamOS), and we found a workaround >> that changes the virtual display device: select the QEMU virt-manager >> Display Spice button in the white left panel, and change the Type >> field from "Spice server" to "VNC server". Then reboot: the unwanted >> input no longer appears. >> ... --- - 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] SPARC project Dilios
Robert Jones asks on Wed, 1 Jul 2020 14:08:40 +0100 about the status of >> SPARC project Dilios I have VMs running various versions of DilOS; the most recent is version 2.0.9 (stretch/sid), and as of today, the last updates in /bin are dated 2020.05.06. My VMs are running on x86_64, not SPARC, however. --- - 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
