Hi Iggi, Alright, I'll take a look at the Issues and such under the GitHub repos.
I have OI running on an amd64 uefi+csm machine, and an amd64 bios-only machine. On Sat, Jul 27, 2024, 1:23 PM Ignacio Soriano Hernandez via illumos-discuss <discuss@lists.illumos.org> wrote: > > Hi Bryce, > > that would be awesome, if you just look into: > > https://www.illumos.org/projects > > There is so much for your taste that you be overwhelmed by the things that > are pending in all areas and due to capacity and knowledge are more in "bug > fixing" mode than anything else :-) > > graphicsdrm, illumos-gate, OpenIndiana you can select depending on your > taste .. and yes, the arm64 approaches had more an experimental approach > with lots and lots of "custom" workarounds (don't want to call them "hacks" > :-)) > > Have you installed one of the illumos based dirtros on baremetal (or > running in a VM)? .. then you will instantly find out what is missing .. > because you will be joining from an operating system that has basically > support for everything .. > > Btw. Toasterson (nick) is one of the maintainers of OI, nice guy, very > helpful and he arranged some co-working sessions to tackle the most > "urgent" topics. > > Cheers > > Iggi > > Bryce <678...@gmail.com> schrieb am 27. Juli 2024 um 18:58: > > > Hi, Iggi: > > I certainly would not mind contributing wherever I could. I've been > reading through the source for the bootloader, if there are any issues that > need to be addressed id love to see if I could help. > > I'd like to port Illumos because, while there do exist several ports to > arm64, they are all incomplete or don't work for some people. id like to > try fixing this. > > If there's anything that I could contribute I'd love to know. > > > On Sat, Jul 27, 2024, 12:09 PM Ignacio Soriano Hernandez via > illumos-discuss <discuss@lists.illumos.org> wrote: > >> Hi Bryce, >> >> let me first complain as I cannot help you with your request. >> >> Reading this posting I just ask myself, why is this the next try to make >> something where illumos and several distros based on it still lack core >> capabilities (see the driver support, power management, graphics subsystem, >> etc, etc.) there even have been several proof of concepts with regards to >> having an illumos based distro on arm64 (yes, several projects made it up >> to prompt and some core capabilities) while someone with that deep >> knowledge would be a huge asset to get some things done to close some gaps? >> And don't get me wrong please, I like that there are projects one wants >> and has to do because it THAT what gathers your interest :-) >> So if you like to get into the core core there are lots of areas where >> someone knowledgeable like you could deliver so much value to the whole >> community . >> >> Thanks for your passion and motiviation and welcome in the rabbithole :-) >> >> Cheers from Germany >> >> Iggi >> >> Bryce <678...@gmail.com> schrieb am 26. Juli 2024 um 20:59: >> >> >> Wow, thanks Joshua >> >> that makes a lot of sense. I'm trying to build a monolithic illumos >> kernel that includes its own root file system. I want to do this because I >> see that illumos is really only established on x86 with a weak standing in >> SPARC, and I'd like to try and port Illumos to other arch's. I'd like to >> get a minimal image working on x86 first though, and troubleshoot my way >> from there on arm64 hopefully then aarch and maybe risc v. (yes, I know >> it's a lot of work, but I enjoy tinkering in assembly and id like to help >> the community). >> >> so, the bootloader passes a command line string and perhaps an >> environment listing (which I assume is also a string?) to the kerbel, does >> it pass these as pointers? If so, are they pushed onto the stack? and if >> that is so, then does the bootloader load the kernel and set up SS and BP >> in the process? >> >> speaking of which, does the loader switch into protected mode before >> loading the kerbel (I assume so, as to load a ufs/cpio archive with drivers >> I'd assume you'd need more than a meg of memory. >> >> Also, can the loader be configured to load the kernel from a known >> address on disk, instead of from a file system? if not that's fine, I could >> patch the source to support that. I ask because I used legacy grub a long >> time ago, and I'm pretty sure it doesn't have that feature, but idk how >> illumos has patched their grub 0.98. >> >> I'll definitely refer to omnios to see how the big guys do it, but it's >> not quite what I'm looking for. >> >> thank you for offering the templates, but I was looking for a slightly >> lower level modification. >> >> On Fri, Jul 26, 2024, 2:26 PM Joshua M. Clulow via illumos-discuss < >> discuss@lists.illumos.org> wrote: >> >>> On Fri, 26 Jul 2024 at 10:49, Bryce <678...@gmail.com> wrote: >>> > I see. So the third stage bootloader loads the kernel into memory, as >>> well as the boot_archive, informs the kernel where the archive is (in >>> memory), then the kernel uses the drivers and such in the programs to load >>> the root and execute /sbin/init? >>> > >>> > I checked the filelist document in >>> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/boot/filelist/i386/filelist.ramdisk >>> and didn't see an /init, do does that mean that whatever the kernel does at >>> that time is completely controlled by the drivers (as I would expect)? >>> >>> There are two distinct styles of boot archive: >>> >>> (a) Archive style; e.g., CPIO. Essentially a cache of files from >>> the real root file system, kept in sync by bootadm(8). This >>> cache only needs to contain: >>> >>> - kernel modules required to locate and mount the root >>> file system from whichever devices house it >>> >>> - any data files (e.g., path_to_inst(5) and system(5) and >>> so on) that are needed before the root file system is >>> mounted >>> >>> (b) Ramdisk style; i.e., a ufs(4FS) image. This is an entire >>> root file system, made available to the kernel by the boot >>> loader. There are a minimal set of routines in the base >>> kernel that can pick files out of a UFS image like they can >>> for a CPIO archive, before the file system is actually >>> mounted. >>> >>> In addition to the kernel ("unix") and the boot archive (described >>> above) the boot loader provides either or both of a command line >>> string, and/or an environment (a list of string key-value pairs). >>> In this environment, we provide some additional properties that tell >>> the kernel which file system driver to use and how to locate the >>> file system (e.g., a /devices path to the disk, or some information >>> about the network for NFS root, etc). >>> >>> In the archive case, the loader must provide enough detail that when >>> the kernel calls vfs_mountroot(), we can locate and mount the root >>> file system. Modules and data needed before that point come from >>> the archive, and after that point, come from the newly mounted file >>> system. The init process is started _after_ that, so we don't need >>> to include it in the archive. >>> >>> In the ramdisk case, the kernel first treats the UFS image as an >>> archive up until vfs_mountroot(), when it "mounts" the UFS image >>> in-place in RAM and things proceed normally as if it were accessing >>> a physical disk -- with the obvious caveat that changes will be >>> destroyed on reboot. This is how install images work today; they >>> boot from an ISO or a USB image into this kind of ramdisk and then >>> load other software by finding and mounting the boot device later >>> from usermode. It's also how SmartOS works. >>> >>> At Oxide, we've got a prototype for a new kind of booting, using a >>> combination of a CPIO boot archive that contains drivers for disks >>> and the ZFS modules, and then having the kernel load a ramdisk image >>> from a slice on an NVMe device into RAM. To do this, I had to add >>> new hooks into the main() routine of the kernel just prior to >>> vfs_mountroot() so that we could inject some custom behaviour from a >>> separate kernel module we build. It's designed to be customisable >>> without changing the base kernel source, but also not quite ready to >>> upstream to mainline illumos -- though I'm keen to get it up there >>> eventually! >>> >>> If you want to get started with a minimal boot-to-ramdisk system, I >>> would probably look at SmartOS, as that's what it is! It uses the >>> UFS ramdisk approach today, and that ramdisk is able to locate other >>> resources on physical disks as needed, etc. We also have some tools >>> the allow building images automatically from templates: >>> >>> https://github.com/illumos/image-builder >>> >>> There is no documentation there right now, but I have some examples >>> of how to use it up here: >>> >>> https://github.com/jclulow/omnios-image-builder >>> >>> I have, in my home directory, other templates I'm yet to add there >>> which can construct a custom OmniOS-based ramdisk image that you can >>> add software and custom boot-time behaviour to. If you want me to >>> throw that up in there, let me know. >>> >>> Happy to answer any questions, as I know this is a lot to take in! >>> It would help to have more concrete specifics about how you're >>> looking to operate the system you're building, what software you're >>> hoping to include, how autonomous it should be, how you're hoping to >>> update it, etc. >>> >>> >>> Cheers. >>> >>> -- >>> Joshua M. Clulow >>> http://blog.sysmgr.org >>> >>> ------------------------------------------ >>> illumos: illumos-discuss >>> Permalink: >>> https://illumos.topicbox.com/groups/discuss/Tc9bfa679c7294ee7-Ma01a51d0c7fe2e4bc5c02ceb >>> Delivery options: >>> https://illumos.topicbox.com/groups/discuss/subscription >>> >> >> >> > > > *illumos <https://illumos.topicbox.com/latest>* / illumos-discuss / see > discussions <https://illumos.topicbox.com/groups/discuss> + participants > <https://illumos.topicbox.com/groups/discuss/members> + delivery options > <https://illumos.topicbox.com/groups/discuss/subscription> Permalink > <https://illumos.topicbox.com/groups/discuss/T0d8bd09ba88fa337-M9c78097aa3e6a825ef077f94> > ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tc9bfa679c7294ee7-M96c461db8e7b504c2593dd76 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
