Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
cretin1997 via openindiana-discuss wrote on 02/03/2021 04:43: Don't admire something too easily only because you read the hype from other people. Don't ride the hype. It's all advertisements anyway! Most of the hypes about the superiority of Solaris over Linux are outdated. Modern Linux beats Solaris, the real Oracle Solaris, let alone a fake Solaris like we are. We are outdated and lagged behind Linux a very long distance, in some ways we even lagged behind FreeBSD. Just count the numbers of Solaris admin refugees go to FreeBSD and you will know. Even though they still praise Solaris occasionally on the FreeBSD forums, they are no longer use any instance of it or converting to FreeBSD completely. My company (perhaps a rare bird), did the opposite, moved from FreeBSD to illumos (both SmartOS and OmniOS, some engineers use OI as desktop). I have been FreeBSD sysadmin for 20 years. I was originally quite reluctant at the move, but, frankly, there is not a single day I am not in awe of the sheer genius of original Solaris engineering. I guess it depends on one's Weltanschauung. Even looking at the contributions to illumos gate, OI and OmniOS I am in awe at the quantity and outstanding quality of the work. Coming from FreeBSD, with all due respect to the FreeBSD brilliant people, I feel like we are still infants. I am deeply grateful to OI, OmniOS and SmartOS developers for keeping ilumos alive and thriving. Han ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!
> On 2. Mar 2021, at 02:45, Reginald Beardsley wrote: > > > It is with deep regret that I say this. > > I shall not be working on Illumos/OI. Below is the terminal output using the > Hipster 2020.10 GUI install disk. I've always been amused by the enthusiasm > for threads. I bought John Lakos' book when it came out and unlike most > actually read much of it. I even posted a page on my office door. Many months > after I'd taken it down the entire project ground to a complete halt while > they refactored the sysem to address the linker issue I'd highlighted on my > office door. I've also read many books on operating systems and all the > issues that must be handled 100% correctly to make multiple processes running > in the same address space work reliably. Can you state the "Dining > Philospher's" problem? I can. This stuff is hard. That's why protected memory > is so important to a robust system. Threads, like shared memory are valuable > tools, but are best used with discretion. And only when there is no suitable > alternative. > > Rather well known, at least to my generation, is something called "Amdahl's > law". It's not particularly insightful. It just makes the observation that > pefectly optimizing something which does not take a lot of time has > neglegible benefit. > > That a seldom used admin utility would be rewritten as a threaded application > says that those responsible for this idiocy were solely interested in adding > "threaded programming" to their resumes. I neither know nor care if the > programmer was at fault or the manager who permitted it was at fault. In any > case it is so stupid as to begger belief. Sadly I have seen many people do > something similar. > > I have *never* written a program using pthreads or any other threading > library. I dealt with things like seismic imaging problems which ran on > 10,000 -20,000 cores or more for 8-10 days processing 10-30 TB of input and > generating similar output volumes. Fortunately these were trivially parallel > and could be broken up into separate jobs for each core. With that many > machines running, checkpointing and restarting was a critical issue. You > *were* going to lose a few machines during a run. So robust recovery was a > big deal. That much compute costs a lot of money and starting the whole thing > over simply not viable. If you did, you went out of business. The only upside > was because such users were running 50,000 cores 24x7 in a single location, > they got baseload electrical rates. Though it was not uncommon to have to > find additonal locations because the electrical power feed to that location > had been exceeded. In Houston, the AC costs as much or more than the > computers to run. > > I've seen an inappropriate tool used far too many times for the sole reason > that some one wanted to put something on their resume. For many years I'd > never written an IP based client server application. I'd taught other people > how to do it, but I had not done it myself for the simple reason that it was > not an appropriate tool for my assigned tasks. I did eventually get to write > a UDP usage logger that tracked usage statistics for the package we were > fielding. That was fun. I generated graphics that showed where each business > affiliate was in the exploration cycle from what programs they were running. > > Much too my surprise and some dismay, Mac OS X is the best supported > commercial Unix today. So I may well become a Mac user. > > A not very happy, > Reg > > jack@openindiana:/jack$ sudo /bin/su > root@openindiana:/jack# format -e > Searching for disks...done > > > AVAILABLE DISK SELECTIONS: > 0. c4d0 > /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0 > Specify disk (enter its number): 0 > For some unknown reason, your disks are recognized as PATA (IDE) disks and not SATA/AHCI. That alone is bad because IDE is slow and cmdk driver is not the fastest one either. You should start with checking out if AHCI (SATA) is available. That alone should not get to the crash but bad things happen. > Error: can't open disk '/dev/rdsk/c4d0p0'. Now this line is actual error - we do try to open whole disk device (*p0 is special device which does allow access to entire disk surface), but we fail. The bug there is obviously about this error - we failed to open the disk, we should not continue from this point, but we still do and the punishment is segmentation fault because some needed data structures are not properly set. It is not obvious why the disk open is failing there, the error code is not printed and you seem to have root rights. From this point, I’d run truss format and would seek out the failing open() to get the error code, perhaps it would explain. Yes, the code of format command is mess (I have been in it more than I would like to;), also we would need better tooling to handle disk partitioning, allowing easy scripting etc, something *like* freebsd gpart has bee
Re: [OpenIndiana-discuss] [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!
‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 3:35 PM, Toomas Soome via openindiana-discuss wrote: > > Yes, the code of format command is mess (I have been in it more than I would > like to;), also we would need better tooling to handle disk partitioning, > allowing easy scripting etc, something like freebsd gpart has been in my mind > for a long time, but I haven't had time to think about it more… > > rgds, > toomas > Too bad FreeBSD's gpart seemed to depend on FreeBSD's GEOM framework. Porting it from FreeBSD seemed to not easy. Luckily, we have a snapshot of FreeBSD before they switched to GEOM, DragonflyBSD. Do you think DragonflyBSD's gpt tool is easier to port, sir? https://man.dragonflybsd.org/?command=gpt§ion=8 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 2:58 PM, Han Sapta wrote: > > Coming from FreeBSD, with all due respect to the FreeBSD > brilliant people, I feel like we are still infants. > > I am deeply grateful to OI, OmniOS and SmartOS developers for > keeping ilumos alive and thriving. > > Han > > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss I don't know why every Solaris refugees I met on the FreeBSD forums praise Solaris, too. I think they are sincere. But the fact is they are migrating/already migrated from Solaris to FreeBSD, I think it's more to do with emotion rather than real quality of the OS. Yours should be a rare case IMHO. And yeah, FreeBSD's tools are not as sophisticated as Solaris. As I said, FreeBSD embraces the KISS principle, but Solaris and now modern Linux choose more integrated and functionalities, this lead to over-engineering with all in one tools like SystemD emerging. It's all depends on personal opinion. Check of man page of FreeBSD's pkg, a fake clone of IPS pkg: https://www.freebsd.org/cgi/man.cgi?query=pkg&sektion=&n=1 and the real IPS pkg: https://docs.oracle.com/cd/E36784_01/html/E36870/pkg-1.html you could easily tell who is the beast in term of complexity and functionalities. I personally prefer the simpler tool that just done it job. Another weakness of FreeBSD is the init system of it that has to be mitigated by tools like daemontools. Some embrace the KISS principle praise it for it deterministic and simplicity. But when comparing with Solaris' SMF and FMA, FreeBSD's RC init system is a joke. That's real. FreeBSD's RC init system loses to SystemD, too, even though they don't want to admit it. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Tribblix and Pale Moon
I don't know the email address of Peter Tribble so I post here hopefully he will see it. Just tried your OS on VirtualBox. It's amazing, a full desktop that's only 2GB in total. The OI's VM should be 4x than that. I installed the Pale Moon browser and I noticed you did build it with official branding. If you were granted by the Pale Moon developers to use their official branding, please dismiss the following part of this mail. If you weren't, you are in trouble. Please build Pale Moon with official branding off. Please have a look at this: https://forum.palemoon.org/viewtopic.php?f=65&t=26065 In short, remove these lines: # Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding. ac_add_options --enable-official-branding export MOZILLA_OFFICIAL=1 from the .mozconfig file describe here: https://developer.palemoon.org/build/sunos/ and you will save yourself a lot of trouble. Sincere. Sent with ProtonMail Secure Email. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!
> On 2. Mar 2021, at 13:08, cretin1997 wrote: > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, March 2, 2021 3:35 PM, Toomas Soome via openindiana-discuss > wrote: >> >> Yes, the code of format command is mess (I have been in it more than I would >> like to;), also we would need better tooling to handle disk partitioning, >> allowing easy scripting etc, something like freebsd gpart has been in my >> mind for a long time, but I haven't had time to think about it more… >> >> rgds, >> toomas >> > > Too bad FreeBSD's gpart seemed to depend on FreeBSD's GEOM framework. Porting > it from FreeBSD seemed to not easy. Luckily, we have a snapshot of FreeBSD > before they switched to GEOM, DragonflyBSD. Do you think DragonflyBSD's gpt > tool is easier to port, sir? > > https://man.dragonflybsd.org/?command=gpt§ion=8 no, it is not about porting it, but the command line logic and functionality. we do have format, fdisk, prtvtoc, fmthard, all doing some subset of tasks and even if you can feed some input data, the customization would need awk/sed and fancy scripting:D See /bin/usbgen for example;) rgds, toomas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Identify type of disk
Hi Team, I need to find out the type of disk(HDD,SSD and NVM) which is attached. any command or any logic to find the disk type. preferred solution: command or logic ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Identify type of disk
‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 8:13 PM, Thebest videos wrote: > Hi Team, > > I need to find out the type of disk(HDD,SSD and NVM) which is attached. any > command or any logic to find the disk type. > preferred solution: command or logic > > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss cfgadm -al Sent with ProtonMail Secure Email. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Identify type of disk
On 03/02/21 02:18 PM, cretin1997 via openindiana-discuss wrote: ‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 8:13 PM, Thebest videos wrote: Hi Team, I need to find out the type of disk(HDD,SSD and NVM) which is attached. any command or any logic to find the disk type. preferred solution: command or logic openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss cfgadm -al Sent with ProtonMail Secure Email. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss Hello! cfgadm -al is not complete. try as root or sudo # diskinfo # nvmeadm list Greetings, Stephan ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Tribblix and Pale Moon
On Tue, Mar 2, 2021 at 11:31 AM cretin1997 via openindiana-discuss < openindiana-discuss@openindiana.org> wrote: > I don't know the email address of Peter Tribble so I post here hopefully > he will see it. > > Just tried your OS on VirtualBox. It's amazing, a full desktop that's only > 2GB in total. The OI's VM should be 4x than that. > > I installed the Pale Moon browser and I noticed you did build it with > official branding. The terms under which this is permitted are covered by the redistribution license http://www.palemoon.org/redist.shtml If you can point to something that violates this (specifically Point 8) then let me know and I'll fix it to bring it into compliance. > If you were granted by the Pale Moon developers to use their official > branding, please dismiss the following part of this mail. > > If you weren't, you are in trouble. Please build Pale Moon with official > branding off. Please have a look at this: > > https://forum.palemoon.org/viewtopic.php?f=65&t=26065 > > In short, remove these lines: > > # Please see https://www.palemoon.org/redist.shtml for restrictions when > using the official branding. > ac_add_options --enable-official-branding > export MOZILLA_OFFICIAL=1 > > from the .mozconfig file describe here: > > https://developer.palemoon.org/build/sunos/ > > and you will save yourself a lot of trouble. > > Sincere. > > > Sent with ProtonMail Secure Email. > > > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss > -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer FAIL #3
In message <20210302014545.ga6...@imap.fastmail.com>, Gary Mills writes: >These are Solaris partions, now called slices. They are within a >single FDISK partition. You can use the partition command within >format to see the slices. You can use the fdisk command within format >to see the FDISK partitions. They are GPT partitions, not Solaris slices within a legacy MBR fdisk partition. There may be nomenclature byg here: # zpool create -f -B -d weetest c4t0d0 # fdisk /dev/rdsk/c4t0d0 If you run fdisk /dev/rdsk/c4t0d0, you will see a single EFI partition, but fdisk is just reporting that its a GPT labeled disk. format -e /dev/rdsk/c4t0d0 -> partition will allow to create GPT partitions, including the EFI GPT partition type only required if booting UEFI, though I find FreeBSD's gpart(8) easier for the OP's use case of multiple pools and filesystems on a single disk. John groenv...@acm.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Tribblix and Pale Moon
‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 8:39 PM, Peter Tribble wrote: > > The terms under which this is permitted are covered by the redistribution > license > > http://www.palemoon.org/redist.shtml > > If you can point to something that violates this (specifically Point 8) > then let me know and > I'll fix it to bring it into compliance. > Ah, you are there! I'm not the Pale Moon owner, just a normal user concerned about this. I'm the user djgpp asked the question on the given Pale Moon forum topic. My experience with the Pale Moon people is they are good people but not friendly at all, especially when it comes to their "copyright". I don't want you, and me, the user, in trouble with these people. If you are sure about the redistribution license I have nothing to say. I'm very bad at reading formal English texts like a license and in no way my knowledge about legal thing is better than you. I will trust you and continue to enjoy both Tribblix and Pale Moon. I build Pale Moon without official branding to use on OpenIndiana. Too bad I think the OI people will never package Pale Moon as you do. BTW, you just better contact them to be sure they will not cause any trouble for you. If you received the rights directly from them, you could even ditch Firefox 52 and ship Pale Moon as the default browser without worrying anything. Just my 2 cents. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Identify type of disk
sorry stephan! This is not solving my problem on my freebsd. any alternative? On Tue, Mar 2, 2021 at 7:09 PM Stephan Althaus < stephan.alth...@duedinghausen.eu> wrote: > On 03/02/21 02:18 PM, cretin1997 via openindiana-discuss wrote: > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, March 2, 2021 8:13 PM, Thebest videos < > sri.chityala...@gmail.com> wrote: > > > >> Hi Team, > >> > >> I need to find out the type of disk(HDD,SSD and NVM) which is attached. > any > >> command or any logic to find the disk type. > >> preferred solution: command or logic > >> > >> openindiana-discuss mailing list > >> openindiana-discuss@openindiana.org > >> https://openindiana.org/mailman/listinfo/openindiana-discuss > > cfgadm -al > > > > Sent with ProtonMail Secure Email. > > > > ___ > > openindiana-discuss mailing list > > openindiana-discuss@openindiana.org > > https://openindiana.org/mailman/listinfo/openindiana-discuss > > Hello! > > cfgadm -al > is not complete. > > try as root or sudo > > # diskinfo > > # nvmeadm list > > > Greetings, > > Stephan > > > > ___ > 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] Why OpenIndiana online package search still query something from opensolaris.org?
If you want speed, I recommend searching Repology. On Mon, Mar 1, 2021 at 11:16 PM cretin1997 via openindiana-discuss < openindiana-discuss@openindiana.org> wrote: > This site here: > > https://pkg.openindiana.org/hipster/en/index.shtml > > It's very slow. Sometimes it's even slower because it waiting for > something from opensolaris.org. > > But opensolaris.org was closed, wasn't it? > > So you query from a non-existing domain, this is the reason why it's that > slow. > > Don't say it's another legacy leftover from your Open Solaris days! > > Time to fix it? Open Solaris was dead for so long. > > > Sent with ProtonMail Secure Email. > > > > ___ > 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] Identify type of disk
In message , Thebest videos writes: >sorry stephan! This is not solving my problem on my freebsd. any >alternative? freebsd-questions. https://docs.freebsd.org/en/books/handbook/eresources/#eresources-mail> John groenv...@acm.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Identify type of disk
You can use smartmontools for this on almost any distribution. On Tue, Mar 2, 2021 at 7:14 AM Thebest videos wrote: > Hi Team, > > I need to find out the type of disk(HDD,SSD and NVM) which is attached. any > command or any logic to find the disk type. > preferred solution: command or logic > ___ > 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] Identify type of disk
NVMe "disks" are managed (only?) using nvmeadm: nvmeadm namespace -v should list them. (apparently "nvmeadm list" lists controllers, which can have one or more namespaces (sections of its total storage which more or less correspond to disks)) I don't know if any sort of NVM drive that doesn't meet the NVMe standard would be recognized. If you see "ssd" on Solaris etc, it usually refers to a Fibre Channel connected disk, NOT to a Solid-State Drive (flash) using an otherwise conventional interface (IDE, SATA, SCSI, SAS, USB, etc). I can't think of a way to tell a spinning drive from a solid-state drive that would give a simple answer without having to decide based on the drive make and model (which you typically can find out). I don't have anything running Solaris on bare metal on x86, nor anything on SPARC at home that's new enough for nvmeadm to apply or with flash drives, so I can't actually try anything except google or RTFM (or read code, if I wanted to spend the time). (I have some older SPARC at home, the newest of which being a T5240; that sort of thing has to be old enough that it can be obtained from eBay at a reasonable price, and not need 220V or otherwise special power; and I don't have much space left for more toys anyway). > On Mar 2, 2021, at 08:13, Thebest videos wrote: > > > Hi Team, > > I need to find out the type of disk(HDD,SSD and NVM) which is attached. any > command or any logic to find the disk type. > preferred solution: command or logic > ___ > 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] [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!
Toomas, Thank you again. Very helpful. The Z400 will only support IDE mode. ACHI+RAID is the other option which I think only works with Windows. I know it will not work with Solaris and feel fairly certain it doesn't work with Linux or *BSD either. As pstack is not familiar to me I didn't interpret the output properly. It certainly would make good sense in a multicore world for system calls to be implemented in threads. That's a very different matter from what I assumed from the ptrace output. As the 4k sector size has been buried behind some layer of software in current drives I'm not sure how disks >2TB actually communicate the size of the disk. I'm curious and am going to try to obtain a fresh drive to determine what I clobbered. However, if the label information for the disk geometry is in the first 20K I think I can reconstruct the geometry from a dump I made of that. In any case it's an interesting technical challenge. I'm sure the format code is a mess. Old code usually is, and the last time I was asked for a disk speed was almost 30 years ago. In the intervening time I was the sole support for an aggregate of 2.5 million lines of scientific code. One especially lovely piece of work was about 400,000 lines in which the sole comment was the author's name. Fortunately, he had taken a software engineering course and chose good names for for functions and variables and I knew the science well. But he wrote about a dozen copy, paste, modify programs and I had to fix the exact same bug in many places with different names. I shall be reasonably conversant with the on disk structure of ZFS shortly as the books are due to arrive on Thursday. There clearly is a need for a "zfs unlabel " option to remove label cruft. I ran into the problem with a 3 TB disk 7-8 years ago. On that occasion I was a bit more thoughtful and searched for the pool label and did a more surgical elimination. That was actually because the problem was the duplicate label at the end of the disk. I came along just after SMD disks had disappeared from the landscape. Reading instructions for setting those up made me very glad that they were gone. I'm fairly sure the geometry stuff I ran into was part of that process and came from BSD. Have Fun! Reg On Tuesday, March 2, 2021, 02:35:33 AM CST, Toomas Soome wrote: For some unknown reason, your disks are recognized as PATA (IDE) disks and not SATA/AHCI. That alone is bad because IDE is slow and cmdk driver is not the fastest one either. You should start with checking out if AHCI (SATA) is available. That alone should not get to the crash but bad things happen. > Error: can't open disk '/dev/rdsk/c4d0p0'. Now this line is actual error - we do try to open whole disk device (*p0 is special device which does allow access to entire disk surface), but we fail. The bug there is obviously about this error - we failed to open the disk, we should not continue from this point, but we still do and the punishment is segmentation fault because some needed data structures are not properly set. It is not obvious why the disk open is failing there, the error code is not printed and you seem to have root rights. From this point, I’d run truss format and would seek out the failing open() to get the error code, perhaps it would explain. Yes, the code of format command is mess (I have been in it more than I would like to;), also we would need better tooling to handle disk partitioning, allowing easy scripting etc, something *like* freebsd gpart has been in my mind for a long time, but I haven't had time to think about it more… rgds, toomas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Does OI compress the zpool by default?
On 2021-02-28 07:38, cretin1997 via openindiana-discuss wrote: zfs get compression and zfs get compressratio results seemed to tell that it's not on by default. But, why? The reason is or should be, because of its potential cost. That is; compression can consume a great deal more CPU cycles. So if the host has limited resources, either outright or because of work load. Then compression will not be an advantage, and may swamp the system. Further, in several implementations several of the settings are somewhat dynamic, and can be "tuned". Compression being one of them. Apologies in advance if this question has already been answered. I'm in the process of getting caught up on my mail. :-) --Chris -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] gparted stack trace from 2020.10 GUI installer disk on HP Z400
FWIW I invoked it from the desktop. It should either work or not be there. BTW I'm going to install FreeBSD 12.2 and run a script that walks the port tree just to see how much actually will build without manual intervention. I suspect that will produce a bit of a stir. root@openindiana:/jack# pstack core core 'core' of 3915:/usr/sbin/gpartedbin - thread# 1 / lwp# 1 - fee2b615 __nanosleep (8046f88, 0, 8046f98, fe187618, 0, 0) + 15 fee1729f usleep (2710) + 48 081080d3 _ZN7GParted11Win_GParted13show_pulsebarERKN4Glib7ustringE (80474b0, 80470ac, 11ae, 546cd55, 171c, fe8596dc) + f3 081116b0 _ZN7GParted11Win_GParted28menu_gparted_refresh_devicesEv (80474b0, 8177740, 81776b8, , 804723c, 1) + 80 fea82f68 _ZN3Gtk12Widget_Class13show_callbackEP10_GtkWidget (81d1228, 81eaef0, 1, 8047290, 804723c, fea82e90) + d8 fdfa5d61 g_closure_invoke (81b3e80, 0, 1, 8047290, 804723c, 827c260) + 171 fdfb95a3 signal_emit_unlocked_R (8203728, 0, 81d1228, 0, 8047290, 81d1228) + f93 fdfc316d g_signal_emit_valist (81d1228, c, 0, 80473dc) + b5d fdfc3a34 g_signal_emit (81d1228, c, 0, fe2ace18, feabd000, 80474b0) + 24 fe2acea9 gtk_widget_show (81d1228, fed30018, fe872adc, 806376e) + a9 fea890a3 _ZN3Gtk6Widget4showEv (80474b0, 80593a8, 8040100, 0, 0, 3) + 23 fe9fe57f _ZN3Gtk4Main3runERNS_6WindowE (80474b0, 8047498, fee2bea5, 8129ba6, fe470118, feffb0a8) + 1f 08129c88 main (8047d3c, feea85c8, 8047d78, 807e6c7, 1, 8047da0) + 158 0807e6c7 _start_crt (1, 8047da0, fefd0c6f, 0, 0, 0) + 96 0807e59a _start (1, 8047e7c, 0, 8047e91, 8047eae, 8047eb9) + 1a - thread# 2 / lwp# 2 - root@openindiana:/jack# ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Why OpenIndiana online package search still query something from opensolaris.org?
Hi It doesn't do that for me. Can you send me the output of the Network connections in devtools when you are opening the page? Greetings Till On 02.03.21 02:15, cretin1997 via openindiana-discuss wrote: This site here: https://pkg.openindiana.org/hipster/en/index.shtml It's very slow. Sometimes it's even slower because it waiting for something from opensolaris.org. But opensolaris.org was closed, wasn't it? So you query from a non-existing domain, this is the reason why it's that slow. Don't say it's another legacy leftover from your Open Solaris days! Time to fix it? Open Solaris was dead for so long. Sent with ProtonMail Secure Email. ___ 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] Why OpenIndiana online package search still query something from opensolaris.org?
I don't see it waiting, but I do see in the page source, at the bottom of https://pkg.openindiana.org/hipster/en/index.shtml :
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Tue, Mar 02, 2021 at 03:37:23PM +, Reginald Beardsley via oi-dev wrote: >Thank you again. Very helpful. The Z400 will only support IDE mode. >ACHI+RAID is the other option which I think only works with Windows. I >know it will not work with Solaris and feel fairly certain it doesn't >work with Linux or *BSD either. ACHI+RAID does work with Solaris and OI, but you have to do some preparation first. I know because I have done that with my Z400 and installed OI on it. The instructions are here: https://superuser.com/questions/635829/how-do-i-install-solaris-on-a-fake-raid-a-k-a-ahciraid-sata-sas-controller/635830#635830 -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
Gary,
Thanks. That's *very* nteresting. I shall have to study that closely.
I ran "truss -f -o truss.out format -e /dev/rdsk/c4d0"
down at the end of a *very* long output is this tidbit. Note the ENOENTs. The
libraries being sought are in /lib and were found previously. I'm rather
puzzled that with the device specified on the command line, format(1m) walked
the entire /dev/rdsk tree and then some including sections of the filesysem I'd
never heard of.
At present I'm trying to sort out how to fix access to the libraries. /mnt/misc
is a RO filesystem mounted from the DVD, so the obvious solution is not
possible. This machine only has 8 GB of RAM so I might not be able to create a
copy of /mnt/misc in ramfs, but I'll give it a try.
I'm unclear about the relationship of c4d0, c4d0p0, etc. I can R/W
/dev/rdsk/c4d0p0:c but not without the ":c"
3994/1: open("/dev/rdsk/c4d0s0", O_RDONLY|O_NDELAY) = 4
3994/1: stat64("/opt/VRTSvxvm/lib/libadm.so.1", 0x08046968) Err#2 ENOENT
3994/1: ioctl(4, DKIOCGEXTVTOC, 0x080477A8) Err#48 ENOTSUP
3994/1: stat64("/opt/VRTSvxvm/lib/libefi.so.1", 0x08046968) Err#2 ENOENT
3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047310) = 0
3994/1: ioctl(4, DKIOCGMBOOT, 0x080979D0) = 0
3994/1: ioctl(4, DKIOCINFO, 0x080472A4) = 0
3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047300) = 0
3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
3994/1: close(4) = 0
3994/1: stat("/dev/rdsk/c4d0p0", 0x08047608) = 0
3994/1: open("/dev/rdsk/c4d0p0", O_RDONLY) Err#6 ENXIO
3994/1: fstat64(2, 0x08046640) = 0
3994/1: write(2, " E r r o r : c a n ' t".., 24) = 24
3994/1: write(2, " / d e v / r d s k / c 4".., 16) = 16
3994/1: write(2, " ' .\n", 3) = 3
3994/1: Incurred fault #6, FLTBOUNDS %pc = 0x080658CB
3994/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
3994/1: Received signal #11, SIGSEGV [default]
3994/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
On Tuesday, March 2, 2021, 05:49:05 PM GMT+1, Gary Mills
wrote:
On Tue, Mar 02, 2021 at 03:37:23PM +, Reginald Beardsley via oi-dev wrote:
> Thank you again. Very helpful. The Z400 will only support IDE mode.
> ACHI+RAID is the other option which I think only works with Windows. I
> know it will not work with Solaris and feel fairly certain it doesn't
> work with Linux or *BSD either.
ACHI+RAID does work with Solaris and OI, but you have to do some
preparation first. I know because I have done that with my Z400
and installed OI on it. The instructions are here:
https://superuser.com/questions/635829/how-do-i-install-solaris-on-a-fake-raid-a-k-a-ahciraid-sata-sas-controller/635830#635830
--
-Gary Mills- -refurb- -Winnipeg, Manitoba, Canada-
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ALSA library/LibAsound for OpenIndiana?
On 2021-03-01 06:11, cretin1997 via openindiana-discuss wrote: ‐‐‐ Original Message ‐‐‐ On Monday, March 1, 2021 8:58 PM, cretin1997 via openindiana-discuss wrote: ‐‐‐ Original Message ‐‐‐ On Thursday, February 25, 2021 9:14 AM, cretin1997 via openindiana-discuss openindiana-discuss@openindiana.org wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, February 24, 2021 6:38 PM, cretin1997 via openindiana-discuss openindiana-discuss@openindiana.org wrote: > > > Could you consider port this very essential library from Linux to OI? I know ALSA is Linuxism. But Linuxism has spread into many applications. Now ALSA library is a hard requirement for sound support on Unix-like platforms of some applications. They are first developed on Linux and as ALSA library has been ported to many other Unix-like OSes as well, they just set ALSA library as a hard requirement. Of course a skillful developer could patch the code to use the platform specific facility. But I'm not one of them and ALSA library is the last piece to be able to build the software on OI. Please help. > > ALSA library is available on all BSDs. The only Unix-like OS doesn't have ALSA library is OpenIndiana/Illumos. > > Sent with ProtonMail Secure Email. > > openindiana-discuss mailing list > > openindiana-discuss@openindiana.org > > https://openindiana.org/mailman/listinfo/openindiana-discuss > > No one interested? > Currently I could build this with a small hack: > https://github.com/cnjinhao/nana > But no sound at all. Because of no ALSA library. > Please note that ALSA library and ALSA itself is not the same. > Porting ALSA library doesn't mean you need to pull in the whole Linux sound infrastructure. > Please have a look at it. > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss No one care about this? It's just a small library, but it helps many applications. Do you ever care about the productivity of your users? I think not. Please don't tell me port it myself. Because if I can, I already did it. Or do you want me to ask for the mercy of pkgsrc? No, absolutely no. I saw there is a ALSA library port on pkgsrc. But the weakness of pkgsrc is it's not integrate with the system. I will ended up building everything as it dependencies even though I have no use for them! pkgsrc doesn't use system library. It always build it own. It's a huge waste of time and most of the time it failed to build one random dependency and render the whole thing failed, too. Using OI as a workstation to do software development is impossible. Your OS is too useless. What's the use of it? A graphical server with a web browser so you could surf the web while working with your server via a graphical interface? This is too primitive to be even called a desktop. But if you say so, I will stop to expect anything more from OI. Best regards. openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss Please don't blame everything on Linuxism. Linuxism is a reality we have to live with. I know definitely someone will go and shout to my face about Linuxism, we are a small team, port it yourself we welcome patches, blah blah... Some old school die hard Unix veterans will come and shout to my face you youngster!, Unix as an IDE!, blah blah... No. I don't care. By IDE I mean a real IDE, not a discipline. I don't care about your discipline, to be clear. Even if doing the development enjoying all of the modern tools on Linux and only build the software to deploy on OI, it's still a lot of troubles. Getting the library you use to build and work on OI is already a showstopper. Why do you even dream of more software running on OI? It's unrealistic! All rubbish aside. It's *not* that nobody cares. In fact, if I could set an hours time aside. I could get the alsalib packaged for IO. So now that it's available and installed. You'll ask; why doesn't my application work? It uses Alsa and I installed alsalib. But it's still not working -- translation; I have to familiarize myself with your favorite applications and set aside an hours time for each of them and change/add to them the ability to use alsalib. IOW it looks easy from the outside-in. But not so, from the inside-out. Make no mistake; your request has merit. It's just going to take someone, or several people with the necessary time, to make the changes necessary to incorporate Alsa. HTH --Chris -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
I was able to patch the path to the libraries, but the open still fails and
then SEGV faults. From the ENOTSUP error I presume I need to fix the vtoc I
wiped out in my haste. But it's some small progress and I know a little bit
more. Probably time for a browse through the Internals 1st ed.
Reg
4043/1: open("/dev/rdsk/c4d0s0", O_RDONLY|O_NDELAY) = 4
4043/1: stat64("/opt/VRTSvxvm/lib/libadm.so.1", 0x08046968) = 0
4043/1: resolvepath("/opt/VRTSvxvm/lib/libadm.so.1", "/lib/libadm.so.1", 1023)
= 16
4043/1: ioctl(4, DKIOCGEXTVTOC, 0x080477A8) Err#48 ENOTSUP
4043/1: stat64("/opt/VRTSvxvm/lib/libefi.so.1", 0x08046968) = 0
4043/1: resolvepath("/opt/VRTSvxvm/lib/libefi.so.1", "/lib/libefi.so.1", 1023)
= 16
4043/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047310) = 0
4043/1: ioctl(4, DKIOCGMBOOT, 0x080979D0) = 0
4043/1: ioctl(4, DKIOCINFO, 0x080472A4) = 0
4043/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047300) = 0
4043/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
4043/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
4043/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
4043/1: close(4) = 0
4043/1: stat("/dev/rdsk/c4d0p0", 0x08047608) = 0
4043/1: open("/dev/rdsk/c4d0p0", O_RDONLY) Err#6 ENXIO
4043/1: fstat64(2, 0x08046640) = 0
4043/1: write(2, " E r r o r : c a n ' t".., 24) = 24
4043/1: write(2, " / d e v / r d s k / c 4".., 16) = 16
4043/1: write(2, " ' .\n", 3) = 3
4043/1: Incurred fault #6, FLTBOUNDS %pc = 0x080658CB
4043/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
4043/1: Received signal #11, SIGSEGV [default]
4043/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Do you ever think about adopting APT+DPKG?
On 2021-03-01 06:33, cretin1997 via openindiana-discuss wrote: We have the tech there. Well adapted for our needs. APT+DPKG based Illumos distro is not unpopular. Some distros even use RPM. Most historic APT+DPKG based distros already dead, only DilOS is left now. So we could have a look at DilOS, the way they patched and utilizing APT+DPKG and we can even co-operate with them, if both side wanted. We already see too many problems of the IPS pkg. Could we switch to another path? I know compatibility haunted us. But recently we broke it already. It's no longer the holy grail we have to keep at all cost anymore. Could we patch our oi-userland to generate DEB packages alongside of IPS packages? The DilOS people has figured out how to build illumos-gate into DEB packages already. This will not as hard as doing from scratch as we have many references. There are many possible "package managers" available. Some have already been recobbled to support Solaris derivatives. But IMHO the DEB package managers are not as efficient as many of the others, it's a real "cache thrasher". Many of the others are more DB centric. Which tends to make them much faster and less resource abusive. --Chris -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
Don't waste your time with this: You are in IDE emulation mode, and
even if you get that working somehow you won't be happy at all,
since that mode is just slow. Get yourself into AHCI mode first,
along the guidelines Gary just posted (and that should've worked
out of the box, these HPE guys manage to break everything...).
On 02.03.21 18:21, Reginald Beardsley via openindiana-discuss wrote:
Gary,
Thanks. That's *very* nteresting. I shall have to study that closely.
I ran "truss -f -o truss.out format -e /dev/rdsk/c4d0"
down at the end of a *very* long output is this tidbit. Note the ENOENTs. The
libraries being sought are in /lib and were found previously. I'm rather
puzzled that with the device specified on the command line, format(1m) walked
the entire /dev/rdsk tree and then some including sections of the filesysem I'd
never heard of.
At present I'm trying to sort out how to fix access to the libraries. /mnt/misc
is a RO filesystem mounted from the DVD, so the obvious solution is not
possible. This machine only has 8 GB of RAM so I might not be able to create a
copy of /mnt/misc in ramfs, but I'll give it a try.
I'm unclear about the relationship of c4d0, c4d0p0, etc. I can R/W /dev/rdsk/c4d0p0:c but
not without the ":c"
3994/1: open("/dev/rdsk/c4d0s0", O_RDONLY|O_NDELAY) = 4
3994/1: stat64("/opt/VRTSvxvm/lib/libadm.so.1", 0x08046968) Err#2 ENOENT
3994/1: ioctl(4, DKIOCGEXTVTOC, 0x080477A8) Err#48 ENOTSUP
3994/1: stat64("/opt/VRTSvxvm/lib/libefi.so.1", 0x08046968) Err#2 ENOENT
3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047310) = 0
3994/1: ioctl(4, DKIOCGMBOOT, 0x080979D0) = 0
3994/1: ioctl(4, DKIOCINFO, 0x080472A4) = 0
3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047300) = 0
3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
3994/1: close(4) = 0
3994/1: stat("/dev/rdsk/c4d0p0", 0x08047608) = 0
3994/1: open("/dev/rdsk/c4d0p0", O_RDONLY) Err#6 ENXIO
3994/1: fstat64(2, 0x08046640) = 0
3994/1: write(2, " E r r o r : c a n ' t".., 24) = 24
3994/1: write(2, " / d e v / r d s k / c 4".., 16) = 16
3994/1: write(2, " ' .\n", 3) = 3
3994/1: Incurred fault #6, FLTBOUNDS %pc = 0x080658CB
3994/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
3994/1: Received signal #11, SIGSEGV [default]
3994/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
On Tuesday, March 2, 2021, 05:49:05 PM GMT+1, Gary Mills
wrote:
On Tue, Mar 02, 2021 at 03:37:23PM +, Reginald Beardsley via oi-dev wrote:
Thank you again. Very helpful. The Z400 will only support IDE mode.
ACHI+RAID is the other option which I think only works with Windows. I
know it will not work with Solaris and feel fairly certain it doesn't
work with Linux or *BSD either.
ACHI+RAID does work with Solaris and OI, but you have to do some
preparation first. I know because I have done that with my Z400
and installed OI on it. The instructions are here:
https://superuser.com/questions/635829/how-do-i-install-solaris-on-a-fake-raid-a-k-a-ahciraid-sata-sas-controller/635830#635830
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Do you ever think about adopting APT+DPKG?
On Tue, Mar 2, 2021 at 11:43 AM Chris wrote: > On 2021-03-01 06:33, cretin1997 via openindiana-discuss wrote: > > We have the tech there. Well adapted for our needs. APT+DPKG based > Illumos > > distro > > is not unpopular. Some distros even use RPM. > > > > Most historic APT+DPKG based distros already dead, only DilOS is left > now. > > So we > > could have a look at DilOS, the way they patched and utilizing APT+DPKG > and > > we can > > even co-operate with them, if both side wanted. > > > > We already see too many problems of the IPS pkg. Could we switch to > another > > path? > > > > I know compatibility haunted us. But recently we broke it already. It's > no > > longer > > the holy grail we have to keep at all cost anymore. > > > > Could we patch our oi-userland to generate DEB packages alongside of IPS > > packages? > > > > The DilOS people has figured out how to build illumos-gate into DEB > packages > > already. > > > > This will not as hard as doing from scratch as we have many references. > There are many possible "package managers" available. Some have already > been > recobbled > to support Solaris derivatives. But IMHO the DEB package managers are not > as > efficient > I'd say this is largely an academic argument. I have 3 machines that use apt + deb with no associated issues. Actually, # apt dist-upgrade on Debian Buster, Ubuntu 20.10, and Raspberry Pi OS Buster runs MUCH faster than # pkg update -v -r on OI Hipster with approximately the same underlying hardware (Intel Core 2nd Gen, 16 GB RAM) for the OI, Debian, and Ubuntu machines. as many of the others, it's a real "cache thrasher". I don't think this is an issue if you have a decent (e.g. Samsung 860 Evo or better) SSD with good endurance specs. Many of the others are > more DB > centric. Which tends to make them much faster and less resource abusive. > > --Chris > > > > > > -- > ~10yrs a FreeBSD maintainer of ~160 ports > ~40yrs of UNIX > > ___ > 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] Do you ever think about adopting APT+DPKG?
On 2021-03-02 09:56, Judah Richardson wrote: On Tue, Mar 2, 2021 at 11:43 AM Chris wrote: On 2021-03-01 06:33, cretin1997 via openindiana-discuss wrote: > We have the tech there. Well adapted for our needs. APT+DPKG based Illumos > distro > is not unpopular. Some distros even use RPM. > > Most historic APT+DPKG based distros already dead, only DilOS is left now. > So we > could have a look at DilOS, the way they patched and utilizing APT+DPKG and > we can > even co-operate with them, if both side wanted. > > We already see too many problems of the IPS pkg. Could we switch to another > path? > > I know compatibility haunted us. But recently we broke it already. It's no > longer > the holy grail we have to keep at all cost anymore. > > Could we patch our oi-userland to generate DEB packages alongside of IPS > packages? > > The DilOS people has figured out how to build illumos-gate into DEB packages > already. > > This will not as hard as doing from scratch as we have many references. There are many possible "package managers" available. Some have already been recobbled to support Solaris derivatives. But IMHO the DEB package managers are not as efficient I'd say this is largely an academic argument. I have 3 machines that use apt + deb with no associated issues. Actually, # apt dist-upgrade on Debian Buster, Ubuntu 20.10, and Raspberry Pi OS Buster runs MUCH faster than # pkg update -v -r on OI Hipster with approximately the same underlying hardware (Intel Core 2nd Gen, 16 GB RAM) for the OI, Debian, and Ubuntu machines. as many of the others, it's a real "cache thrasher". I don't think this is an issue if you have a decent (e.g. Samsung 860 Evo or better) SSD with good endurance specs. Agreed. It's also not an issue with more RAM/cores && higher frequencies. ;-) In the end, I don't really care _which_ package manager is chosen; as long as there is only _one_ and that it's the simplest to use for the package *creators* :-) Ultimately; that should ensure the most packages for the users, with the greatest package integrity. No? :-) --Chris Many of the others are more DB centric. Which tends to make them much faster and less resource abusive. -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
The ENOENTs refer to libraries associated with the optional 3rd party
commercial product Veritas Volume Manager. format attempts to check for
conflicting uses of a raw device, such as if it is being managed by VxVM,
Solaris Disk Suite, ZFS, etc. In this case, it attempts to dynamically load the
VxVM libraries, but if they're not installed, that's ok, it just figures that
it can't do that particular test.
Of the other errors, the first is:
ENOTSUP on DKIOCGEXTVTOC on /dev/rdsk/c4d0s0
DKIOCEXTVTOC (per dkio man page) is described as follows:
DKIOCGEXTVTOC
The argument is a pointer to an extvtoc structure (described
below). This ioctl returns the device's current volume table of
contents (VTOC). VTOC is extended to support a disk up to 2TB in
size. For disks larger than 1TB this ioctl must be used instead of
DKIOCGVTOC.
Not sure why that happened without looking at code, if even then. That'd be
code for the driver, part of the kernel, that would let one see what cause(s)
there might be for ENOTSUP on that ioctl.
There is an implication there that the maximum disk size is 2TB. That's true
for SMI labels and I think for FDISK (MBR) labels, but I _think_ that EFI
labels can handle a larger disk; there are some mentions in documentation of
that capability. Note that drives larger than 2TB are probably more recent than
some of the driver or utility code...even with paid developers, there's always
new stuff coming along; although drives larger than 2TB were available perhaps
8 years ago, so if there is a problem with them other than just needing to use
EFI labels, it is a sign of aging code.
The second error is the ENXIO on /dev/rdsk/c4d0p0. Note that's different from
the first device, which was c4d0s0. c4d0p0 refers to an FDISK (MBR) partition
(presumably the first one), while c4d0s0 refers to a slice (presumably within
the FDISK partition tagged as for Solaris). ENXIO probably (without knowing
which driver was involved) means that the physical device exists but the
partition doesn't (or there's something weird with the partition table?).
Again, someone would have to look at driver source to know exactly why that
happened; they'd also have to see detailed output of various commands that
could show relevant system hardware and configuration. I'm not going to attempt
to guess what those commands might be, and I'm unlikely to dig into kernel code
except for my own interest. But I'm just another person on the list, not a
"contributor" or "developer", so take that how you will.
As you can see, even a first-pass attempt at understanding this stuff can be
pretty nontrivial, and digging deep enough to fix something quite a bit more
than that.
> On Mar 2, 2021, at 12:21, Reginald Beardsley via openindiana-discuss
> wrote:
>
> Gary,
>
> Thanks. That's *very* nteresting. I shall have to study that closely.
>
> I ran "truss -f -o truss.out format -e /dev/rdsk/c4d0"
>
> down at the end of a *very* long output is this tidbit. Note the ENOENTs. The
> libraries being sought are in /lib and were found previously. I'm rather
> puzzled that with the device specified on the command line, format(1m) walked
> the entire /dev/rdsk tree and then some including sections of the filesysem
> I'd never heard of.
>
> At present I'm trying to sort out how to fix access to the libraries.
> /mnt/misc is a RO filesystem mounted from the DVD, so the obvious solution is
> not possible. This machine only has 8 GB of RAM so I might not be able to
> create a copy of /mnt/misc in ramfs, but I'll give it a try.
>
> I'm unclear about the relationship of c4d0, c4d0p0, etc. I can R/W
> /dev/rdsk/c4d0p0:c but not without the ":c"
>
>
> 3994/1: open("/dev/rdsk/c4d0s0", O_RDONLY|O_NDELAY) = 4
> 3994/1: stat64("/opt/VRTSvxvm/lib/libadm.so.1", 0x08046968) Err#2 ENOENT
> 3994/1: ioctl(4, DKIOCGEXTVTOC, 0x080477A8) Err#48 ENOTSUP
> 3994/1: stat64("/opt/VRTSvxvm/lib/libefi.so.1", 0x08046968) Err#2 ENOENT
> 3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047310) = 0
> 3994/1: ioctl(4, DKIOCGMBOOT, 0x080979D0) = 0
> 3994/1: ioctl(4, DKIOCINFO, 0x080472A4) = 0
> 3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047300) = 0
> 3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
> 3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
> 3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
> 3994/1: close(4) = 0
> 3994/1: stat("/dev/rdsk/c4d0p0", 0x08047608) = 0
> 3994/1: open("/dev/rdsk/c4d0p0", O_RDONLY) Err#6 ENXIO
> 3994/1: fstat64(2, 0x08046640) = 0
> 3994/1: write(2, " E r r o r : c a n ' t".., 24) = 24
> 3994/1: write(2, " / d e v / r d s k / c 4".., 16) = 16
> 3994/1: write(2, " ' .\n", 3) = 3
> 3994/1: Incurred fault #6, FLTBOUNDS %pc = 0x080658CB
> 3994/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
> 3994/1: Received signal #11, SIGSEGV [default]
> 3994/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0258
>
>
>
> On Tuesday, March 2, 2021, 05:49:05 PM GMT+1, Gary Mills
Re: [OpenIndiana-discuss] Do you ever think about adopting APT+DPKG?
Le Mardi 2 mars 2021, Chris a écrit : > On 2021-03-02 09:56, Judah Richardson wrote: > > On Tue, Mar 2, 2021 at 11:43 AM Chris wrote: > > > >> On 2021-03-01 06:33, cretin1997 via openindiana-discuss wrote: > >> > We have the tech there. Well adapted for our needs. APT+DPKG based > >> Illumos > >> > distro > >> > is not unpopular. Some distros even use RPM. > >> > > >> > Most historic APT+DPKG based distros already dead, only DilOS is left > >> now. > >> > So we > >> > could have a look at DilOS, the way they patched and utilizing APT+DPKG > >> and > >> > we can > >> > even co-operate with them, if both side wanted. > >> > > >> > We already see too many problems of the IPS pkg. Could we switch to > >> another > >> > path? > >> > > >> > I know compatibility haunted us. But recently we broke it already. It's > >> no > >> > longer > >> > the holy grail we have to keep at all cost anymore. > >> > > >> > Could we patch our oi-userland to generate DEB packages alongside of IPS > >> > packages? > >> > > >> > The DilOS people has figured out how to build illumos-gate into DEB > >> packages > >> > already. > >> > > >> > This will not as hard as doing from scratch as we have many references. > >> There are many possible "package managers" available. Some have already > >> been > >> recobbled > >> to support Solaris derivatives. But IMHO the DEB package managers are not > >> as > >> efficient > >> > > I'd say this is largely an academic argument. I have 3 machines that use > > apt + deb with no associated issues. Actually, # apt dist-upgrade on Debian > > Buster, Ubuntu 20.10, and Raspberry Pi OS Buster runs MUCH faster than # > > pkg update -v -r on OI Hipster with approximately the same underlying > > hardware (Intel Core 2nd Gen, 16 GB RAM) for the OI, Debian, and Ubuntu > > machines. > > > > as many of the others, it's a real "cache thrasher". > > > > I don't think this is an issue if you have a decent (e.g. Samsung 860 Evo > > or better) SSD with good endurance specs. > Agreed. It's also not an issue with more RAM/cores && higher frequencies. ;-) > > In the end, I don't really care _which_ package manager is chosen; as long > as there is only _one_ and that it's the simplest to use for the package > *creators* :-) > Ultimately; that should ensure the most packages for the users, with the > greatest > package integrity. No? :-) > > --Chris > > > > Many of the others are > >> more DB > >> centric. Which tends to make them much faster and less resource abusive. The other ones do not use a SAT solver that cross checks any action on the system... Also I have repeated this a lot of times on the past but here again: traditional archive-based package managers are very slow for large updates. APT in particular is awful for a large number of packages triggering postinstall scripts. I think there are a lot of misconceptions about the boundaries of IPS. If it were just solving dependencies and unpacking tarballs and triggering shell scripts if would be as fast as the rest... Now if the discussion is whether the design has rough edges or whether the incurred penalty is worth paying for a desktop system where you do not care much about consistency... it is another topic. > >> > > -- > ~10yrs a FreeBSD maintainer of ~160 ports > ~40yrs of UNIX > > ___ > 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] Hipster 2020.10 text installer ISO Wow!!!!
In message <0679fa41-d544-7007-44fd-b00b3a5c9...@kit.edu>, "Udo Grabowski (IMK) " writes: >since that mode is just slow. Get yourself into AHCI mode first, >along the guidelines Gary just posted (and that should've worked >out of the box, these HPE guys manage to break everything...). Does HP's BIOS prohibit booting from LSI HBAs? ISTR some HPQ evil in that regard. In my little corner of the world, Dell Precision workstations are available at salvage prices for home lab use, but in other corners I have seen well-speced HP Z workstations on thrift shop shelves. John groenv...@acm.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
> On 2. Mar 2021, at 20:25, Richard L. Hamilton wrote:
>
> The ENOENTs refer to libraries associated with the optional 3rd party
> commercial product Veritas Volume Manager. format attempts to check for
> conflicting uses of a raw device, such as if it is being managed by VxVM,
> Solaris Disk Suite, ZFS, etc. In this case, it attempts to dynamically load
> the VxVM libraries, but if they're not installed, that's ok, it just figures
> that it can't do that particular test.
>
> Of the other errors, the first is:
>
> ENOTSUP on DKIOCGEXTVTOC on /dev/rdsk/c4d0s0
>
> DKIOCEXTVTOC (per dkio man page) is described as follows:
> DKIOCGEXTVTOC
>
> The argument is a pointer to an extvtoc structure (described
> below). This ioctl returns the device's current volume table of
> contents (VTOC). VTOC is extended to support a disk up to 2TB in
> size. For disks larger than 1TB this ioctl must be used instead of
> DKIOCGVTOC.
>
> Not sure why that happened without looking at code, if even then. That'd be
> code for the driver, part of the kernel, that would let one see what cause(s)
> there might be for ENOTSUP on that ioctl.
>
> There is an implication there that the maximum disk size is 2TB. That's true
> for SMI labels and I think for FDISK (MBR) labels, but I _think_ that EFI
> labels can handle a larger disk; there are some mentions in documentation of
> that capability. Note that drives larger than 2TB are probably more recent
> than some of the driver or utility code...even with paid developers, there's
> always new stuff coming along; although drives larger than 2TB were available
> perhaps 8 years ago, so if there is a problem with them other than just
> needing to use EFI labels, it is a sign of aging code.
>
> The second error is the ENXIO on /dev/rdsk/c4d0p0. Note that's different from
> the first device, which was c4d0s0. c4d0p0 refers to an FDISK (MBR) partition
> (presumably the first one), while c4d0s0 refers to a slice (presumably
> within the FDISK partition tagged as for Solaris). ENXIO probably (without
> knowing which driver was involved) means that the physical device exists but
> the partition doesn't (or there's something weird with the partition table?).
> Again, someone would have to look at driver source to know exactly why that
> happened; they'd also have to see detailed output of various commands that
> could show relevant system hardware and configuration. I'm not going to
> attempt to guess what those commands might be, and I'm unlikely to dig into
> kernel code except for my own interest. But I'm just another person on the
> list, not a "contributor" or "developer", so take that how you will.
>
> As you can see, even a first-pass attempt at understanding this stuff can be
> pretty nontrivial, and digging deep enough to fix something quite a bit more
> than that.
cmdkopen() has 4 cases for ENXIO, first one is when we can not get softstate
(we can drop it, I guess). Other three are about disk label (cmlb_valiate() and
cmlb_partinfo()) and some state variables, so it has to be there. Next
interesting bit could be get with dtrace:)
It is certain, there is something weird going on, we can post instructions for
dtrace, if you are still willing to go on. It would be nice to get to bottom of
this.
rgds,
toomas
>
>> On Mar 2, 2021, at 12:21, Reginald Beardsley via openindiana-discuss
>> wrote:
>>
>> Gary,
>>
>> Thanks. That's *very* nteresting. I shall have to study that closely.
>>
>> I ran "truss -f -o truss.out format -e /dev/rdsk/c4d0"
>>
>> down at the end of a *very* long output is this tidbit. Note the ENOENTs.
>> The libraries being sought are in /lib and were found previously. I'm rather
>> puzzled that with the device specified on the command line, format(1m)
>> walked the entire /dev/rdsk tree and then some including sections of the
>> filesysem I'd never heard of.
>>
>> At present I'm trying to sort out how to fix access to the libraries.
>> /mnt/misc is a RO filesystem mounted from the DVD, so the obvious solution
>> is not possible. This machine only has 8 GB of RAM so I might not be able to
>> create a copy of /mnt/misc in ramfs, but I'll give it a try.
>>
>> I'm unclear about the relationship of c4d0, c4d0p0, etc. I can R/W
>> /dev/rdsk/c4d0p0:c but not without the ":c"
>>
>>
>> 3994/1: open("/dev/rdsk/c4d0s0", O_RDONLY|O_NDELAY) = 4
>> 3994/1: stat64("/opt/VRTSvxvm/lib/libadm.so.1", 0x08046968) Err#2 ENOENT
>> 3994/1: ioctl(4, DKIOCGEXTVTOC, 0x080477A8) Err#48 ENOTSUP
>> 3994/1: stat64("/opt/VRTSvxvm/lib/libefi.so.1", 0x08046968) Err#2 ENOENT
>> 3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047310) = 0
>> 3994/1: ioctl(4, DKIOCGMBOOT, 0x080979D0) = 0
>> 3994/1: ioctl(4, DKIOCINFO, 0x080472A4) = 0
>> 3994/1: ioctl(4, DKIOCGMEDIAINFO, 0x08047300) = 0
>> 3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
>> 3994/1: ioctl(4, DKIOCGETEFI, 0x080472E8) = 0
>> 3
Re: [OpenIndiana-discuss] Does OI compress the zpool by default?
On Tue, Mar 2, 2021 at 4:16 PM Chris wrote: > On 2021-02-28 07:38, cretin1997 via openindiana-discuss wrote: > > zfs get compression and zfs get compressratio results seemed to tell > that > > it's not > > on by default. But, why? > The reason is or should be, because of its potential cost. That is; > compression can consume a great deal more CPU cycles. > ZFS compression is a good thing. You win by having to move less data through the entire I/O stack. Originally, compression was off by default because 15 years ago there were still incredibly slow systems still being used. Worse, zfs compression was single-threaded, which was a bit of a nightmare on something like the old coolthreads boxes. Neither are true any more. Over the years, CPU capacity has increased much faster than I/O performance, and we have better algorithms - and better optimized code - to play with. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer FAIL #3
On Tue, Mar 02, 2021 at 09:17:31AM -0500, John D Groenveld wrote: > In message <20210302014545.ga6...@imap.fastmail.com>, Gary Mills writes: > >These are Solaris partions, now called slices. They are within a > >single FDISK partition. You can use the partition command within > >format to see the slices. You can use the fdisk command within format > >to see the FDISK partitions. > > They are GPT partitions, not Solaris slices within a legacy MBR fdisk > partition. Sorry. I should not have replied. I've never used GPT disks, although ZFS offers to use the whole disk, whatever that means. I only know about FDISK partitions and Solaris slices. There was once one type of partition, then there were two, and now there is three. > There may be nomenclature byg here: > # zpool create -f -B -d weetest c4t0d0 > # fdisk /dev/rdsk/c4t0d0 > If you run fdisk /dev/rdsk/c4t0d0, you will see a single EFI partition, > but fdisk is just reporting that its a GPT labeled disk. > format -e /dev/rdsk/c4t0d0 -> partition will allow to create GPT > partitions, including the EFI GPT partition type only required if > booting UEFI, though I find FreeBSD's gpart(8) easier for the OP's use > case of multiple pools and filesystems on a single disk. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer FAIL #3
In message <20210302190828.ga16...@imap.fastmail.com>, Gary Mills writes: >Sorry. I should not have replied. I've never used GPT disks, Its fun to play with these under OI with VirtualBox or bhyve(5). John groenv...@acm.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer FAIL #3
> On 2. Mar 2021, at 21:08, Gary Mills wrote: > > On Tue, Mar 02, 2021 at 09:17:31AM -0500, John D Groenveld wrote: >> In message <20210302014545.ga6...@imap.fastmail.com>, Gary Mills writes: >>> These are Solaris partions, now called slices. They are within a >>> single FDISK partition. You can use the partition command within >>> format to see the slices. You can use the fdisk command within format >>> to see the FDISK partitions. >> >> They are GPT partitions, not Solaris slices within a legacy MBR fdisk >> partition. > > Sorry. I should not have replied. I've never used GPT disks, > although ZFS offers to use the whole disk, whatever that means. I > only know about FDISK partitions and Solaris slices. There was once > one type of partition, then there were two, and now there is three. /* * Since we own the whole disk, try to enable disk write * caching. We ignore errors because it's OK if we can't do it. */ (void) ldi_ioctl(dvd->vd_lh, DKIOCSETWCE, (intptr_t)&wce, FKIOCTL, kcred, NULL); But of course, the problem with MBR+VTOC is complexity and size limit. Many people just do not understand the nested partition tables:) rgds, toomas ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
The HP BIOS is the screwiest one I've ever come across. My first Z400 cost $1100, but several years ago I got 3x Z400's for a total of $300 delivered. They are all the older 4 DIMM machines w/ 2.67 GHz quad core W3520 processors, but you sure can't beat the price. Lately I've been eyeing a Z820. I can get one with 24 3 GHz cores, 512 GB of RAM and 20-30 TB of RAIDZ3 for less than I paid for my Ultra 20 in 2006. The hardest part is finding a justification with the current state of the oil industry. So I'll need a new use case. I'm happy to report that by running FreeBSD sade(8) and putting a GPT label on the disk I can access the disk on OI 2020.10 again and all the vendor information has been restored. prtvtoc again provides the same output as before I nuked the label. Once I've studied the ZFS implementations in Linux, BSD, OS X, Solaris and Illumos/OI I plan to write a more sensible way to clean cruft off of disks than a blind "dd if=/dev/zero...". Whenever I do disk upgrades I put the old disks in caddies so I can test stuff such as I've been doing. Or try out the latest version of Plan 9 ;-) So I think it worth studying how they are getting the disk info and doing some work on format(1m) after all. I don't think the proliferation of redundant tools is useful. I'm much more inclined to fix old stuff than write new stuff. Though "fix" may well require writing a lot of new code. It's the person who has to use it that matters. My chief objection to Gnu/Linux is the perpetually changing syntax and semantics of things one rarely does. That is very dangerous if you have some ancient utility that attends to a complex but infrequent task which you got working long ago, but never quite got around to documenting properly. Have Fun! Reg On Tuesday, March 2, 2021, 12:46:11 PM CST, John D Groenveld wrote: In message <0679fa41-d544-7007-44fd-b00b3a5c9...@kit.edu>, "Udo Grabowski (IMK) " writes: >since that mode is just slow. Get yourself into AHCI mode first, >along the guidelines Gary just posted (and that should've worked >out of the box, these HPE guys manage to break everything...). Does HP's BIOS prohibit booting from LSI HBAs? ISTR some HPQ evil in that regard. In my little corner of the world, Dell Precision workstations are available at salvage prices for home lab use, but in other corners I have seen well-speced HP Z workstations on thrift shop shelves. John groenv...@acm.org ___ 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] Hipster 2020.10 text installer FAIL #3
LoL! It has become completely nuts. We have MBR, GPT, EFI UEFI and probably some I don't yet know about. They may or may not be exactly the same depending upon the persuasions of the OS or program. Having wasted a couple of days going down this rabbit hole, I plan to be more cautious. Yeah, I know I can fix it, but I don't know how long it will take and this was a pretty rude time sink. Now on to making AHCI work on the Z400. "Damn the torpedoes, full speed ahead!" - Admiral Farragut at the battle of Mobile bay. Have Fun! Reg On Tuesday, March 2, 2021, 01:09:48 PM CST, Gary Mills wrote: On Tue, Mar 02, 2021 at 09:17:31AM -0500, John D Groenveld wrote: > In message <20210302014545.ga6...@imap.fastmail.com>, Gary Mills writes: > >These are Solaris partions, now called slices. They are within a > >single FDISK partition. You can use the partition command within > >format to see the slices. You can use the fdisk command within format > >to see the FDISK partitions. > > They are GPT partitions, not Solaris slices within a legacy MBR fdisk > partition. Sorry. I should not have replied. I've never used GPT disks, although ZFS offers to use the whole disk, whatever that means. I only know about FDISK partitions and Solaris slices. There was once one type of partition, then there were two, and now there is three. > There may be nomenclature byg here: > # zpool create -f -B -d weetest c4t0d0 > # fdisk /dev/rdsk/c4t0d0 > If you run fdisk /dev/rdsk/c4t0d0, you will see a single EFI partition, > but fdisk is just reporting that its a GPT labeled disk. > format -e /dev/rdsk/c4t0d0 -> partition will allow to create GPT > partitions, including the EFI GPT partition type only required if > booting UEFI, though I find FreeBSD's gpart(8) easier for the OP's use > case of multiple pools and filesystems on a single disk. -- -Gary Mills- -refurb- -Winnipeg, Manitoba, Canada- ___ 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] Hipster 2020.10 text installer FAIL #3
> On 2. Mar 2021, at 21:32, Reginald Beardsley via openindiana-discuss > wrote: > > > LoL! > > It has become completely nuts. We have MBR, GPT, EFI UEFI and probably some I > don't yet know about. They may or may not be exactly the same depending upon > the persuasions of the OS or program. > > Having wasted a couple of days going down this rabbit hole, I plan to be more > cautious. Yeah, I know I can fix it, but I don't know how long it will take > and this was a pretty rude time sink. > > Now on to making AHCI work on the Z400. > > "Damn the torpedoes, full speed ahead!" - Admiral Farragut at the battle of > Mobile bay. > > Have Fun! > Reg Beware the big white whale:) rgds, toomas > > On Tuesday, March 2, 2021, 01:09:48 PM CST, Gary Mills > wrote: > > On Tue, Mar 02, 2021 at 09:17:31AM -0500, John D Groenveld wrote: >> In message <20210302014545.ga6...@imap.fastmail.com>, Gary Mills writes: >>> These are Solaris partions, now called slices. They are within a >>> single FDISK partition. You can use the partition command within >>> format to see the slices. You can use the fdisk command within format >>> to see the FDISK partitions. >> >> They are GPT partitions, not Solaris slices within a legacy MBR fdisk >> partition. > > Sorry. I should not have replied. I've never used GPT disks, > although ZFS offers to use the whole disk, whatever that means. I > only know about FDISK partitions and Solaris slices. There was once > one type of partition, then there were two, and now there is three. > >> There may be nomenclature byg here: >> # zpool create -f -B -d weetest c4t0d0 >> # fdisk /dev/rdsk/c4t0d0 >> If you run fdisk /dev/rdsk/c4t0d0, you will see a single EFI partition, >> but fdisk is just reporting that its a GPT labeled disk. >> format -e /dev/rdsk/c4t0d0 -> partition will allow to create GPT >> partitions, including the EFI GPT partition type only required if >> booting UEFI, though I find FreeBSD's gpart(8) easier for the OP's use >> case of multiple pools and filesystems on a single disk. > > > -- > -Gary Mills--refurb--Winnipeg, Manitoba, Canada- > > ___ > 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 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!
On Tue, 2 Mar 2021 at 07:37, Reginald Beardsley via oi-dev wrote: > There clearly is a need for a "zfs unlabel " option to remove label > cruft. I ran into the problem with a 3 TB disk 7-8 years ago. On that > occasion I was a bit more thoughtful and searched for the pool label and did > a more surgical elimination. That was actually because the problem was the > duplicate label at the end of the disk. I believe you want "zpool labelclear", as per: https://illumos.org/man/1M/zpool -- Joshua M. Clulow http://blog.sysmgr.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] gparted stack trace from 2020.10 GUI installer disk on HP Z400
In message <1394386638.2119053.1614702010...@mail.yahoo.com>, Reginald Beardsle y via openindiana-discuss writes: >BTW I'm going to install FreeBSD 12.2 and run a script that walks the port tre >e just to see how much actually will build without manual intervention. I sus poudriere(8) is a good starting point for automated builds on FreeBSD: https://docs.freebsd.org/en/books/porters-handbook/#testing-poudriere> Project Trident, before their switch to Void Linux as their base system, had a nice Jenkins implementation in front of their build cluster complements iXsystems that would report the status of their fork of the ports collection against their TrueOS fork of current. OI is also using Jenkins CI: https://hipster.openindiana.org/jenkins/job/oi-userland/> Does Joyent have a public front-end/status-panel for pkgsrc builds? John groenv...@acm.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
As noted earlier, Damn the torpedos, full speed ahead! Send me the dtrace. I've been wanting to learn that better for quite a while. I'm pretty sure I have the book, but haven't had the motivation. I'm doing one of my unplanned, purely random projects. I've dropped around $200 on books on FreeBSD, Solaris and ZFS internals which will be arriving late this week or early next week. The VTOC discussion in the 1st ed of "Solaris Internals" was a bit of a let down. I'm hoping that the 2nd ed addresses that. I take it *very* seriously when computers don't do *exactly* what I want. And I have a long history of doing rather exotic stuff. Before I became good friends with Unix I tuned a MicroVAX II in a BA123 "world box" to run 2 batch queues at 100% CPU utilization 24x7 without degrading interactive usage. Can't do that in Unix because of fork-exec, but you can in a transient process space OS like VMS by setting WS_QUOTA, WS_EXTANT and related parameters. Sadly in a few months of runs I probably saved the research group I was in more than I was being paid, but lost my financial support and PhD along with it. Oh, well. Have Fun! Reg On Tuesday, March 2, 2021, 12:52:04 PM CST, Toomas Soome via openindiana-discuss wrote: cmdkopen() has 4 cases for ENXIO, first one is when we can not get softstate (we can drop it, I guess). Other three are about disk label (cmlb_valiate() and cmlb_partinfo()) and some state variables, so it has to be there. Next interesting bit could be get with dtrace:) It is certain, there is something weird going on, we can post instructions for dtrace, if you are still willing to go on. It would be nice to get to bottom of this. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Why OpenIndiana online package search still query something from opensolaris.org?
Hmm I had a look this seems deep in the templates. I'll see that I can remove those, they are defunct anyway. Thanks for reporting. -Till On 02.03.21 13:47, Alan Coopersmith wrote: I don't see it waiting, but I do see in the page source, at the bottom of https://pkg.openindiana.org/hipster/en/index.shtml :
Re: [OpenIndiana-discuss] [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!
I tried that, but probably not at the appropriate time. I'd likely done the "dd if=/dev/zero..." already. I was annoyed and got out the big hammer. So by the time I tried it, it didn't matter. Also it was a FreeBSD "zroot" label. After I play with the AHCI stuff I may repeat the situation. Have Fun! Reg On Tuesday, March 2, 2021, 01:41:08 PM CST, Joshua M. Clulow wrote: On Tue, 2 Mar 2021 at 07:37, Reginald Beardsley via oi-dev wrote: > There clearly is a need for a "zfs unlabel " option to remove label > cruft. I ran into the problem with a 3 TB disk 7-8 years ago. On that > occasion I was a bit more thoughtful and searched for the pool label and did > a more surgical elimination. That was actually because the problem was the > duplicate label at the end of the disk. I believe you want "zpool labelclear", as per: https://illumos.org/man/1M/zpool -- Joshua M. Clulow http://blog.sysmgr.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
Does *not* work on my Z400 machine. I reset the BIOS to "AHCI+RAID" and the
2020.10 GUI installer enters maintenance mode. prtconf -v won't even run.
With it set to "IDE" in the BIOS it reports "82801JI (ICH10 family) 4 port SATA
IDE" and the same message but "2 port".
"RAID" never appears in the prtconf -v output. I'm running BIOS 3.19, though I
do have a couple of machines with an older BIOS (3.07??) installed. Those are
all 4 DIM slot machines. My newer 6 slot machine is far too precious to fool
with. The 4 DIMM machines have Vista stickers. The 6 DIMM came with Win 7 Pro.
I really don't think it's an issue. The numbers below are for a 3 disk RAIDZ1
pool with a quad core 2.67 GHz Xeon W3520 with 8 GB of RAM. Realistically it's
not going to be able to crunch data fast enough for the disk transfer rate to
matter.
sun_x86%rhb {126} /usr/bin/time dd if=/dev/zero bs=65536 count=65536 of=zero.tst
65536+0 records in
65536+0 records out
4294967296 bytes transferred in 46.334185 secs (92695432 bytes/sec)
real 46.3
user 0.1
sys 4.8
sun_x86%rhb {127}
sun_x86%rhb {127} rm zero.tst
sun_x86%rhb {128} /usr/bin/time dd if=/dev/zero bs=65536 count=1048576
of=zero.tst
1048576+0 records in
1048576+0 records out
68719476736 bytes transferred in 1086.415813 secs (63253384 bytes/sec)
real 18:06.4
user 2.2
sys 1:17.0
sun_x86%rhb {129}
Have Fun!
Reg
On Tuesday, March 2, 2021, 10:49:05 AM CST, Gary Mills
wrote:
ACHI+RAID does work with Solaris and OI, but you have to do some
preparation first. I know because I have done that with my Z400
and installed OI on it. The instructions are here:
https://superuser.com/questions/635829/how-do-i-install-solaris-on-a-fake-raid-a-k-a-ahciraid-sata-sas-controller/635830#635830
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Tue, Mar 2, 2021 at 1:25 PM Reginald Beardsley via openindiana-discuss < openindiana-discuss@openindiana.org> wrote: > > The HP BIOS is the screwiest one I've ever come across. Can confirm via my HP ProBook. Dell's BIOSes are a lot better. My first Z400 cost $1100, but several years ago I got 3x Z400's for a total > of $300 delivered. They are all the older 4 DIMM machines w/ 2.67 GHz quad > core W3520 processors, but you sure can't beat the price. Lately I've been > eyeing a Z820. I can get one with 24 3 GHz cores, 512 GB of RAM and 20-30 > TB of RAIDZ3 for less than I paid for my Ultra 20 in 2006. The hardest part > is finding a justification with the current state of the oil industry. So > I'll need a new use case. > > I'm happy to report that by running FreeBSD sade(8) and putting a GPT > label on the disk I can access the disk on OI 2020.10 again and all the > vendor information has been restored. prtvtoc again provides the same > output as before I nuked the label. Once I've studied the ZFS > implementations in Linux, BSD, OS X, Solaris and Illumos/OI I plan to write > a more sensible way to clean cruft off of disks than a blind "dd > if=/dev/zero...". Whenever I do disk upgrades I put the old disks in > caddies so I can test stuff such as I've been doing. Or try out the latest > version of Plan 9 ;-) > > So I think it worth studying how they are getting the disk info and doing > some work on format(1m) after all. I don't think the proliferation of > redundant tools is useful. I'm much more inclined to fix old stuff than > write new stuff. Though "fix" may well require writing a lot of new code. > It's the person who has to use it that matters. My chief objection to > Gnu/Linux is the perpetually changing syntax and semantics of things one > rarely does. That is very dangerous if you have some ancient utility that > attends to a complex but infrequent task which you got working long ago, > but never quite got around to documenting properly. > > Have Fun! > Reg > On Tuesday, March 2, 2021, 12:46:11 PM CST, John D Groenveld < > groenv...@acm.org> wrote: > > In message <0679fa41-d544-7007-44fd-b00b3a5c9...@kit.edu>, "Udo > Grabowski (IMK) > " writes: > >since that mode is just slow. Get yourself into AHCI mode first, > >along the guidelines Gary just posted (and that should've worked > >out of the box, these HPE guys manage to break everything...). > > Does HP's BIOS prohibit booting from LSI HBAs? > ISTR some HPQ evil in that regard. > In my little corner of the world, Dell Precision workstations > are available at salvage prices for home lab use, but in other > corners I have seen well-speced HP Z workstations on thrift shop > shelves. > > John > groenv...@acm.org > > ___ > 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 > ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
In regard to: Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO...: On Tue, Mar 2, 2021 at 1:25 PM Reginald Beardsley via openindiana-discuss < openindiana-discuss@openindiana.org> wrote: The HP BIOS is the screwiest one I've ever come across. Can confirm via my HP ProBook. Dell's BIOSes are a lot better. That may be true, but both Jedi and I tried several different Dell systems in late 2019 (mostly PowerEdge R710, R720, and R730 servers for me) and could not get a successful OI install on any of them using the 2019 OI installers. I tried a range of BIOS versions for each of them, including latest or in some cases last BIOS version. I've also found that the most recent Dell Precision workstations now come with some features (like USB boot) not available from the legacy BIOS. They're slowly moving primarily to UEFI. There's a good chance that my next workstation at work won't actually run OI. Tim -- Tim Mooney tim.moo...@ndsu.edu Enterprise Computing & Infrastructure / Division of Information Technology/701-231-1076 (Voice) North Dakota State University, Fargo, ND 58105-5164 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Tue, Mar 2, 2021 at 6:14 PM Tim Mooney via openindiana-discuss < openindiana-discuss@openindiana.org> wrote: > In regard to: Re: [OpenIndiana-discuss] Hipster 2020.10 text installer > ISO...: > > > On Tue, Mar 2, 2021 at 1:25 PM Reginald Beardsley via > openindiana-discuss < > > openindiana-discuss@openindiana.org> wrote: > > > >> > >> The HP BIOS is the screwiest one I've ever come across. > > > > Can confirm via my HP ProBook. Dell's BIOSes are a lot better. > > That may be true, but both Jedi and I tried several different Dell systems > in late 2019 (mostly PowerEdge R710, R720, and R730 servers for me) and > could > not get a successful OI install on any of them using the 2019 OI > installers. > I tried a range of BIOS versions for each of them, including latest or in > some cases last BIOS version. > Sorry, I was referring to the BIOS' UI/UX in isolation, not how well it works with OI. I use an HP Z800 daily but don't have access to its BIOS (AFAIK, I've never tried) so I can't comment there. However, I have seen folks on here say it works well with Solaris and OI, so there's that. > > I've also found that the most recent Dell Precision workstations now come > with some features (like USB boot) not available from the legacy BIOS. > They're slowly moving primarily to UEFI. ... as is everything. It's the current gen industry standard. There's a good chance that my > next workstation at work won't actually run OI. > I create and run simulations for a living. I haven't been assigned a non-Windows workstation since 2009 (IBM AIX was the last non-Windows OS I ran directly for work). The last cluster I used had an IBM web frontend; I have no idea what OS it was running, and that job was sufficiently stressful to make that question a trivial detail ;) > > Tim > -- > Tim Mooney tim.moo...@ndsu.edu > Enterprise Computing & Infrastructure / > Division of Information Technology/701-231-1076 (Voice) > North Dakota State University, Fargo, ND 58105-5164 > > ___ > 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] Hipster 2020.10 text installer ISO Wow!!!!
In message <7749906e-c8f6-84e8-1946-7e16caf31...@ndsu.edu>, Tim Mooney via open indiana-discuss writes: >That may be true, but both Jedi and I tried several different Dell systems >in late 2019 (mostly PowerEdge R710, R720, and R730 servers for me) and could >not get a successful OI install on any of them using the 2019 OI installers. In UEFI mode, OI-hipster-text-20201031.usb image boots only to maintenance but OI-hipster-text-20201031.iso CD image works fine. My WAG is the bug is not with bootx64.efi but somewhere in the UFS partition on the USB image but I need to dig deeper. John groenv...@acm.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] ALSA library/LibAsound for OpenIndiana?
‐‐‐ Original Message ‐‐‐ On Wednesday, March 3, 2021 12:34 AM, Chris wrote: > > All rubbish aside. It's not that nobody cares. In fact, if I could set an > hours > time aside. I could get the alsalib packaged for IO. So now that it's > available > and installed. You'll ask; why doesn't my application work? It uses Alsa and > I > installed alsalib. But it's still not working -- translation; I have to > familiarize > myself with your favorite applications and set aside an hours time for each > of them > and change/add to them the ability to use alsalib. > > IOW it looks easy from the outside-in. But not so, from the inside-out. Make > no > mistake; your request has merit. It's just going to take someone, or several > people with the necessary time, to make the changes necessary to incorporate > Alsa. > > HTH > > --Chris > No. I'm not that stupid. I only need the library. I already have contact via email with the software developer. Everything since then I will work with them, not you. The only thing they require is all of the dependencies satisfied. They are pleased to patch their software to run on a new platform but not to add new code just to support a specific platform. Hope it helps. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Does OI compress the zpool by default?
‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 11:15 PM, Chris wrote: > On 2021-02-28 07:38, cretin1997 via openindiana-discuss wrote: > > The reason is or should be, because of its potential cost. That is; > compression can consume a great deal more CPU cycles. So if the host has > limited resources, either outright or because of work load. Then compression > will not be an advantage, and may swamp the system. Further, in several > implementations several of the settings are somewhat dynamic, and can be > "tuned". > Compression being one of them. > > Apologies in advance if this question has already been answered. I'm in the > process of getting caught up on my mail. :-) > > --Chris > > > > > -- > ~10yrs a FreeBSD maintainer of ~160 ports > ~40yrs of UNIX Except this easy to easy to change from not compressed to compressed. Setting the attribute alone not work. If you think have to do send/recv everything to get it compressed is a pleasure task, especially you have to do this every time after you installed a new system, I have nothing to say anymore. Why don't it just the thing already set to be compressed from the beginning? It will save much time and space for the user! BTW, FreeBSD seemed to turn on lz4 compression by default. Nowadays with modern hardware, it's sane to turn it on by default. Your arguments about an old system should be dismissed completely. None of the Illumos is for old and weak system. Illumos is a resource hog. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] gparted stack trace from 2020.10 GUI installer disk on HP Z400
‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 11:20 PM, Reginald Beardsley via openindiana-discuss wrote: > FWIW > > I invoked it from the desktop. > > It should either work or not be there. > > BTW I'm going to install FreeBSD 12.2 and run a script that walks the port > tree just to see how much actually will build without manual intervention. I > suspect that will produce a bit of a stir. > Should should use the stable branch of it: https://github.com/freebsd/freebsd-ports/branches I think it's branches/2020Q4. master is constantly changing and could break things randomly. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Tue, Mar 02, 2021 at 09:42:45PM +, Reginald Beardsley wrote: > Does *not* work on my Z400 machine. I reset the BIOS to "AHCI+RAID" >and the 2020.10 GUI installer enters maintenance mode. prtconf -v won't >even run. I wonder if you made the change too late in the boot process? When the loader is running, you can interrupt the automatic boot by pressing the space bar. Then, you can enter commands to the loader. Selecting the single-user boot may be sufficient. You may need to use the text installer instead. As well, you may need to enter the fully-qualified path of prtconf, like this: /usr/sbin/prtconf -v | less I know that it's complicated, but it's the only way to accomodate a broken disk controller. Also, you only have to do this once. Most systems do not have this problem. -- -Gary Mills--refurb--Winnipeg, Manitoba, Canada- ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!
‐‐‐ Original Message ‐‐‐ On Wednesday, March 3, 2021 3:01 AM, Reginald Beardsley via openindiana-discuss wrote: > I tried that, but probably not at the appropriate time. I'd likely done the > "dd if=/dev/zero..." already. I was annoyed and got out the big hammer. So by > the time I tried it, it didn't matter. Also it was a FreeBSD "zroot" label. > > After I play with the AHCI stuff I may repeat the situation. > > Have Fun! > Reg > Ahh, FreeBSD. Yeah, FreeBSD's zpool can't be cleared easily. I have suffered from this, too. zpool destroy alone doesn't work. If you fire up GParted on Linux, you will see a whole disk as a orangish ZFS file system, even though you have created a new GPT partition table and already partitioned the disk for another OS! The only solution is dd if=/dev/zero, even though my disks are very fast SSD, this took very long time indeed. How time consuming! BTW, anyone know how to stop the browser from automatically mess up my writings? It just replace/rearrange words randomly, rendered the whole thing as a mess! I think I will switch browser. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On 2021-03-02 03:20, cretin1997 via openindiana-discuss wrote: Another weakness of FreeBSD is the init system of it that has to be mitigated by tools like daemontools. No offense, but this is false. Some embrace the KISS principle praise it for it deterministic and simplicity. But when comparing with Solaris' SMF and FMA, FreeBSD's RC init system is a joke. That's real. FreeBSD's RC init system loses to SystemD, too, even though they don't want to admit it. This is purely opinion (yours). :-) I know many, many people who flocked from Linux to FreeBSD when SystemD as the only option became final. Those whom couldn't bear to leave Linux, went to Slackware. --Chris -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] gparted stack trace from 2020.10 GUI installer disk on HP Z400
If the ISO is not "stable" it's not even worth doing. Kirk is brilliant, but he just describes the concepts. I'll see what the new book has to say and then compare it to the implementation. On Tuesday, March 2, 2021, 09:01:10 PM CST, cretin1997 wrote: ‐‐‐ Original Message ‐‐‐ On Tuesday, March 2, 2021 11:20 PM, Reginald Beardsley via openindiana-discuss wrote: > FWIW > > I invoked it from the desktop. > > It should either work or not be there. > > BTW I'm going to install FreeBSD 12.2 and run a script that walks the port > tree just to see how much actually will build without manual intervention. I > suspect that will produce a bit of a stir. > Should should use the stable branch of it: https://github.com/freebsd/freebsd-ports/branches I think it's branches/2020Q4. master is constantly changing and could break things randomly. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
I hit F10, changed from IDE to AHCI+RAID, saved and booted. What are you suggesting? As a practical matter 60 MB/s write is not bad. Certainly good enough for this machine even with 32 GB of RAM in place of the current 8 GB. On Tuesday, March 2, 2021, 09:04:12 PM CST, Gary Mills wrote: On Tue, Mar 02, 2021 at 09:42:45PM +, Reginald Beardsley wrote: > Does *not* work on my Z400 machine. I reset the BIOS to "AHCI+RAID" > and the 2020.10 GUI installer enters maintenance mode. prtconf -v won't > even run. I wonder if you made the change too late in the boot process? When the loader is running, you can interrupt the automatic boot by pressing the space bar. Then, you can enter commands to the loader. Selecting the single-user boot may be sufficient. You may need to use the text installer instead. As well, you may need to enter the fully-qualified path of prtconf, like this: /usr/sbin/prtconf -v | less I know that it's complicated, but it's the only way to accomodate a broken disk controller. Also, you only have to do this once. Most systems do not have this problem. -- -Gary Mills- -refurb- -Winnipeg, Manitoba, Canada- ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
Gad! The BSD rc.d system is the epitome of the Unix tradition of "ease of discovery". The Sys V inittab was OK, but not as flexible. SMF was designed for very large system environments which no longer exist. And Sun had to grandfather both BSD and Sys V ISV installs which simply made it more complex. Systemd is just a reinvention of SMF motivated by the reality that Linux has displaced SunOS and there are very large Linux environments which need better management tools. I wrote a *very* acerbic essay "You Must Be Root To Install" in response to having to deal with this stuff. And typeset Will Gray's Usenet post on the same subject. In certain circles there is a popular quip, "Algol 60 was a significant improvement over its successors." Big system environments are hard. I was very excited by Plan 9 and got a disk at Usenix '95. A complete bootable OS and windowing system with Unicode support, an editor and basic utilities on a single 1.44 MB floppy! The goal was to handle 35,000 users. I had the opportunity to discuss it with Dennis who informed me that the work to make it scale to that many users had not and was not likely to be done. Staff resources had been shifted to Inferno and set top boxes. :-( Plan 9 does still exist and runs some very large machines that do things which are *very* secret. About all they will reveal is a photo of the cabinets in the machine room. Reg On Tuesday, March 2, 2021, 09:36:30 PM CST, Chris wrote: On 2021-03-02 03:20, cretin1997 via openindiana-discuss wrote: > > Another weakness of FreeBSD is the init system of it that has to be > mitigated by > tools like daemontools. No offense, but this is false. > Some embrace the KISS principle praise it for it > deterministic and simplicity. But when comparing with Solaris' SMF and FMA, > FreeBSD's RC init system is a joke. That's real. FreeBSD's RC init system > loses to > SystemD, too, even though they don't want to admit it. This is purely opinion (yours). :-) I know many, many people who flocked from Linux to FreeBSD when SystemD as the only option became final. Those whom couldn't bear to leave Linux, went to Slackware. --Chris -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ 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] Hipster 2020.10 text installer ISO Wow!!!!
In message <1078948242.36904.1614743360...@mail.yahoo.com>, Reginald Beardsley via openindiana-discuss writes: >I hit F10, changed from IDE to AHCI+RAID, saved and booted. What are you sugge >sting? Next boot the installation media and follow the recipe to obtain the PCI ID for the disk controller and attach ahci(7D). https://superuser.com/questions/635829/how-do-i-install-solaris-on-a-fake-raid-a-k-a-ahciraid-sata-sas-controller/635830#635830> Then you should be to see your disks with diskinfo(1M) and import your OI rpool to configure your OI installation to attach ahci to to the controller permanently. John groenv...@acm.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] gparted stack trace from 2020.10 GUI installer disk on HP Z400
‐‐‐ Original Message ‐‐‐ On Wednesday, March 3, 2021 10:45 AM, Reginald Beardsley wrote: > If the ISO is not "stable" it's not even worth doing. Kirk is brilliant, but > he just describes the concepts. > I'll see what the new book has to say and then compare it to the > implementation. Oh man, I mean the ports collection. The ports is what you get when you run portsnap fetch extract and portsnap fetch update. They are going to deprecate portsnap so the most obvious way to get the ports tree is via git. I feared if you got the wrong branch of the ports tree, the master branch, because I have never had any build errors with ports, so I remind you that you should use the stable quarterly branch. Seemed you never used FreeBSD before. I have to remind you that, FreeBSD names their ISO a bit different from the rest. STABLE branch is indeed testing but RELEASE branch is indeed stable. You should get the RELEASE branch ISO. ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Tue, 2 Mar 2021 at 20:32, John D Groenveld wrote: > In message <1078948242.36904.1614743360...@mail.yahoo.com>, Reginald Beardsley > via openindiana-discuss writes: > >I hit F10, changed from IDE to AHCI+RAID, saved and booted. What are you > >sugge > >sting? > > Next boot the installation media and follow the recipe > to obtain the PCI ID for the disk controller and attach ahci(7D). > https://superuser.com/questions/635829/how-do-i-install-solaris-on-a-fake-raid-a-k-a-ahciraid-sata-sas-controller/635830#635830> > > Then you should be to see your disks with diskinfo(1M) and import > your OI rpool to configure your OI installation to attach ahci to > to the controller permanently. If ahci(7D) does indeed support this controller, and it's just that the association with the specific PCI ID is missing, that's incredibly easy to fix in illumos and then nobody needs to do the manual update_drv dance ever again. At present, it's just attaching to the AHCI 1.0 PCI device class, 01:06:01: http://src.illumos.org/source/xref/illumos-gate/usr/src/pkg/manifests/driver-storage-ahci.mf?r=fd6d41c5#46-47 But if we need to bind it to more specific devices that do not advertise the class, it would just mean more aliases in the package manifest. It'd help to collect the data from prtconf and file a bug report to start with, and then making the actual change is not likely to be a great deal more work after that. It's always best to file and fix the underlying bug where we can, rather than propagate workarounds like this. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
