[GH-ISSUE #551 ] Solaris based distros #1711

Author

Owner

@thelamer commented on GitHub (Jan 27, 2020):

ref issue upstream to see if they can just host it :
https://smartos.topicbox.com/groups/smartos-discuss/T181a52074b18fa37/direct-hosting-of-platform-tarballs-for-netbooting

@thelamer commented on GitHub (Jan 27, 2020): ref issue upstream to see if they can just host it : https://smartos.topicbox.com/groups/smartos-discuss/T181a52074b18fa37/direct-hosting-of-platform-tarballs-for-netbooting

kerem commented

Author

Owner

@bahamat commented on GitHub (Jan 30, 2020):

I've got a netboot.xyz-custom fork that works with SmartOS here: https://github.com/bahamat/netboot.xyz-custom

I just need to do a bit of work to "operationalize" our side of it to get it ready for mainline inclusion.

@bahamat commented on GitHub (Jan 30, 2020): I've got a netboot.xyz-custom fork that works with SmartOS here: https://github.com/bahamat/netboot.xyz-custom I just need to do a bit of work to "operationalize" our side of it to get it ready for mainline inclusion.

kerem commented

Author

Owner

@thelamer commented on GitHub (Jan 30, 2020):

OmniOS reference, looks like http support for grabbing the zlib files only might have to lean on them for hosting if possible:
https://github.com/jfqd/OmniOSce-wiki/blob/master/PXEfromNonOmniOS.md

@thelamer commented on GitHub (Jan 30, 2020): OmniOS reference, looks like http support for grabbing the zlib files only might have to lean on them for hosting if possible: https://github.com/jfqd/OmniOSce-wiki/blob/master/PXEfromNonOmniOS.md

kerem commented

Author

Owner

@bahamat commented on GitHub (Jan 31, 2020):

I've deployed a new infrastructure for hosting netboot and updated my fork of netboot.xyz-custom to point at this new infra hosted at netboot.joyent.com. You can use this for testing, and we can discuss what final integration will look like.

@bahamat commented on GitHub (Jan 31, 2020): I've deployed a new infrastructure for hosting netboot and updated my fork of netboot.xyz-custom to point at this new infra hosted at netboot.joyent.com. You can use this for testing, and we can discuss what final integration will look like.

kerem commented

https://netboot.joyent.com/smartos.ipxe

Author

Owner

@thelamer commented on GitHub (Jan 31, 2020):

Paging @antonym , we have avoided it in the past, but would it make sense to link directly to external ipxe for rolling out Smartos considering the organizations direct support ?

@thelamer commented on GitHub (Jan 31, 2020): Paging @antonym , we have avoided it in the past, but would it make sense to link directly to external ipxe for rolling out Smartos considering the organizations direct support ? https://netboot.joyent.com/smartos.ipxe

kerem commented

Author

Owner

@antonym commented on GitHub (Jan 31, 2020):

I'd still prefer to maintain the actual pxe boot instructions within the project as it makes it easier to view the various boot methods as documentation in one repo. If it chains out to a remote menu, that's another place a user would have to go to view the docs on how to boot that OS.

It would be interesting though if we could pull versions from an iPXE file from the provider so that their build systems could generate a versioned file to avoid having to maintain version increments.

But either way, this is awesome, thanks for setting up infrastructure to allow us to consume builds!

@antonym commented on GitHub (Jan 31, 2020): I'd still prefer to maintain the actual pxe boot instructions within the project as it makes it easier to view the various boot methods as documentation in one repo. If it chains out to a remote menu, that's another place a user would have to go to view the docs on how to boot that OS. It would be interesting though if we could pull versions from an iPXE file from the provider so that their build systems could generate a versioned file to avoid having to maintain version increments. But either way, this is awesome, thanks for setting up infrastructure to allow us to consume builds!

kerem commented

Author

Owner

@bahamat commented on GitHub (Jan 31, 2020):

If there’s a better way to provide versions, I’m perfectly willing to do that instead. I don’t have a particular preference for hosting the boot instructions, but I do want to be able to support multiple versions.

Is it possible to chain load just a list of items for the menu?

@bahamat commented on GitHub (Jan 31, 2020): If there’s a better way to provide versions, I’m perfectly willing to do that instead. I don’t have a particular preference for hosting the boot instructions, but I do want to be able to support multiple versions. Is it possible to chain load just a list of items for the menu?

kerem commented

Author

Owner

@antonym commented on GitHub (Jan 31, 2020):

Yeah, you could chain in specific versions, so if you wanted to maintain several versions you could do something like:

# versions.ipxe
#!ipxe

# build date... etc
set smartos_option_1 20200130T131547Z
set smartos_option_2 20200117T180335Z
set smartos_option_3 20200103T004546Z
set smartos_option_4 20191219T093118Z

netboot.xyz menu file

#!ipxe

echo Checking for latest upstream versions...
chain --timeout 5000 https://netboot.joyent.com/versions.ipxe ||
...

:smartos_menu
menu Joyent SmartOS
item --gap Platform Images:
item ${smartos_option_1} ${space} ${smartos_option_1}
item ${smartos_option_2} ${space} ${smartos_option_2}
item ${smartos_option_3} ${space} ${smartos_option_3}
item ${smartos_option_4} ${space} ${smartos_option_4}
...

@antonym commented on GitHub (Jan 31, 2020): Yeah, you could chain in specific versions, so if you wanted to maintain several versions you could do something like: ``` # versions.ipxe #!ipxe # build date... etc set smartos_option_1 20200130T131547Z set smartos_option_2 20200117T180335Z set smartos_option_3 20200103T004546Z set smartos_option_4 20191219T093118Z ``` netboot.xyz menu file ``` #!ipxe echo Checking for latest upstream versions... chain --timeout 5000 https://netboot.joyent.com/versions.ipxe || ... :smartos_menu menu Joyent SmartOS item --gap Platform Images: item ${smartos_option_1} ${space} ${smartos_option_1} item ${smartos_option_2} ${space} ${smartos_option_2} item ${smartos_option_3} ${space} ${smartos_option_3} item ${smartos_option_4} ${space} ${smartos_option_4} ... ```

kerem commented

Author

Owner

@thelamer commented on GitHub (Jan 31, 2020):

We can probably do an external assets yaml like we do with endpoints for programmatically ingested externally hosted asset versioning through cronned builders .

@thelamer commented on GitHub (Jan 31, 2020): We can probably do an external assets yaml like we do with endpoints for programmatically ingested externally hosted asset versioning through cronned builders .

kerem commented

Author

Owner

@antonym commented on GitHub (Jan 31, 2020):

Yeah, that'd be cool too... eventually we might add some mirroring logic so users could mirror the kernels locally so ideally we can leverage the assets/version yamls to store those versions and retrieve those files. That might be where the dependency on the versions hosted remotely could break.

@antonym commented on GitHub (Jan 31, 2020): Yeah, that'd be cool too... eventually we might add some mirroring logic so users could mirror the kernels locally so ideally we can leverage the assets/version yamls to store those versions and retrieve those files. That might be where the dependency on the versions hosted remotely could break.

kerem commented

Author

Owner

@bahamat commented on GitHub (Jan 31, 2020):

We can probably do an external assets yaml like we do with endpoints for programmatically ingested externally hosted asset versioning through cronned builders .

@thelamer If you can tell me the syntax for that (or point me to an example?), I'll set it up.

@bahamat commented on GitHub (Jan 31, 2020): > We can probably do an external assets yaml like we do with endpoints for programmatically ingested externally hosted asset versioning through cronned builders . @thelamer If you can tell me the syntax for that (or point me to an example?), I'll set it up.

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 1, 2020):

It doesn't exist we are speaking hypothetically.
Likely it will be a bash command that generates a string we can update in a yaml file in our repo from pretty much any external source.
This breaks down the build env a little more.
https://github.com/netbootxyz/build-pipelines

You have done plenty on your side , the ball is in our court to ingest your work.

@thelamer commented on GitHub (Feb 1, 2020): It doesn't exist we are speaking hypothetically. Likely it will be a bash command that generates a string we can update in a yaml file in our repo from pretty much any external source. This breaks down the build env a little more. https://github.com/netbootxyz/build-pipelines You have done plenty on your side , the ball is in our court to ingest your work.

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 1, 2020):

I updated the ipxe file to allow usage of kmdb, so I'd like that to be included with the boot instructions, wherever that ends up being.

We have releases every two weeks, and one thing I'd like to do in addition to keeping releases relatively up to date, is to sometimes include experimental images. For example, right now we're close to integrating in-zone nfs server, and having that available would reduce friction for people wanting to test it. So if possible, I'd like the list of images to be of variable size rather than just a static four (or however many) elements.

@bahamat commented on GitHub (Feb 1, 2020): I updated the ipxe file to allow usage of kmdb, so I'd like that to be included with the boot instructions, wherever that ends up being. We have releases every two weeks, and one thing I'd like to do in addition to keeping releases relatively up to date, is to sometimes include experimental images. For example, right now we're close to integrating in-zone nfs server, and having that available would reduce friction for people wanting to test it. So if possible, I'd like the list of images to be of variable size rather than just a static four (or however many) elements.

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 3, 2020):

Smartos is now in development head and can be tested with these assets:
https://s3.amazonaws.com/dev.boot.netboot.xyz/0899b4efaf4feccc7e1ddc5b381ad16a7d7a03eb/index.html

We will ingest an array of versions for whatever you put in between the platforms and options menu in your ipxe file , but the rest of the file is static and will need logic changes PR'd in.
Let me know if you notice anything that needs fixing in the initial implementation @bahamat .

@thelamer commented on GitHub (Feb 3, 2020): Smartos is now in development head and can be tested with these assets: https://s3.amazonaws.com/dev.boot.netboot.xyz/0899b4efaf4feccc7e1ddc5b381ad16a7d7a03eb/index.html We will ingest an array of versions for whatever you put in between the platforms and options menu in your ipxe file , but the rest of the file is static and will need logic changes PR'd in. Let me know if you notice anything that needs fixing in the initial implementation @bahamat .

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 3, 2020):

@thelamer Neat!

Looking at the commit (0899b4efaf), I'm not sure how to format it, or where to put it.

@bahamat commented on GitHub (Feb 3, 2020): @thelamer Neat! Looking at the commit (0899b4efaf4feccc7e1ddc5b381ad16a7d7a03eb), I'm not sure how to format it, or where to put it.

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 3, 2020):

we use a cronned bot to pull in your ipxe file and parse out the versions to commit changes to our development branch.
The logic is here:
https://github.com/netbootxyz/external-versions/blob/smartos/version.sh
You just change your ipxe file versions and we will ingest it.

@thelamer commented on GitHub (Feb 3, 2020): we use a cronned bot to pull in your ipxe file and parse out the versions to commit changes to our development branch. The logic is here: https://github.com/netbootxyz/external-versions/blob/smartos/version.sh You just change your ipxe file versions and we will ingest it.

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 3, 2020):

Ok, that works for me. How frequently do you pull it in?

@bahamat commented on GitHub (Feb 3, 2020): Ok, that works for me. How frequently do you pull it in?

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 3, 2020):

Daily

@thelamer commented on GitHub (Feb 3, 2020): Daily

kerem commented

Author

Owner

@antonym commented on GitHub (Feb 3, 2020):

Do the images work in UEFI? I was getting exec errors trying with VirtualBox in UEFI mode. If not, we can disable the menu from the UEFI menu. Legacy mode worked great though.

@antonym commented on GitHub (Feb 3, 2020): Do the images work in UEFI? I was getting exec errors trying with VirtualBox in UEFI mode. If not, we can disable the menu from the UEFI menu. Legacy mode worked great though.

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 4, 2020):

Triton and stand-alone SmartOS use the same build process for platform images (although they have different release schedules), so it should work with uefi, although we do have a problem where the console is blank (see https://smartos.org/bugview/OS-7746). I'm not sure if the problem is ipxe or loader, and we haven't made it a high priority because we primarily use serial for console access.

Even with the blank console, it should still be booted and usable. I was going to bring up enabling the serial console for netboot.xyz the same way we do for Triton, though not necessarily for OS-7746.

@bahamat commented on GitHub (Feb 4, 2020): Triton and stand-alone SmartOS use the same build process for platform images (although they have different release schedules), so it *should* work with uefi, although we do have a problem where the console is blank (see https://smartos.org/bugview/OS-7746). I'm not sure if the problem is ipxe or loader, and we haven't made it a high priority because we primarily use serial for console access. Even with the blank console, it should still be booted and usable. I was going to bring up enabling the serial console for netboot.xyz the same way we do for Triton, though not necessarily for OS-7746.

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 4, 2020):

BTW, I can't get the efi ISO to load at all using vmware fusion.

@bahamat commented on GitHub (Feb 4, 2020): BTW, I can't get the efi ISO to load at all using vmware fusion.

kerem commented

Author

Owner

@antonym commented on GitHub (Feb 4, 2020):

Is the VM settings set in UEFI mode? If it's in legacy it probably won't boot. We can look at adding serial console support to the ipxe image if needed as well.

@antonym commented on GitHub (Feb 4, 2020): Is the VM settings set in UEFI mode? If it's in legacy it probably won't boot. We can look at adding serial console support to the ipxe image if needed as well.

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 4, 2020):

I'm not sure where to change that. Compatibility is set to version 14, which should allow efi. All the settings are the same as my regular SmartOS vm, which works with EFI.

@bahamat commented on GitHub (Feb 4, 2020): I'm not sure where to change that. Compatibility is set to version 14, which should allow efi. All the settings are the same as my regular SmartOS vm, which works with EFI.

kerem commented

Author

Owner

@antonym commented on GitHub (Feb 4, 2020):

Should be a way to do it via the interface or by editing the vmx and changing the firmware mode.

@antonym commented on GitHub (Feb 4, 2020): Should be a way to do it via the interface or by editing the vmx and changing the firmware mode.

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 4, 2020):

I get exec format error on hardware too using UEFI, I get the same error codes when I try to load a 32 bit kernel in UEFI also if that helps.

@thelamer commented on GitHub (Feb 4, 2020): I get exec format error on hardware too using UEFI, I get the same error codes when I try to load a 32 bit kernel in UEFI also if that helps.

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 5, 2020):

Our kernel is 64-bit only. It's not even possible to build a 32-bit illumos kernel anymore.

Would either of you be able to give me a screenshot of it?

@bahamat commented on GitHub (Feb 5, 2020): Our kernel is 64-bit only. It's not even possible to build a 32-bit illumos kernel anymore. Would either of you be able to give me a screenshot of it?

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 5, 2020):

I was compiling a micro os a while back for a POC Linux bootloader , I got exec format when I did not flag EFI stub support also.
I am just shooting in the dark here , my expertise in Solaris in general stops at getting it to boot.

@thelamer commented on GitHub (Feb 5, 2020): I was compiling a micro os a while back for a POC Linux bootloader , I got exec format when I did not flag EFI stub support also. I am just shooting in the dark here , my expertise in Solaris in general stops at getting it to boot.

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 5, 2020):

SmartOS by itself works with EFI. Our usb boot images are EFI capable and the same platform image we’re providing for NetBoot is what we use for our usb images.

@bahamat commented on GitHub (Feb 5, 2020): SmartOS by itself works with EFI. Our usb boot images are EFI capable and the same platform image we’re providing for NetBoot is what we use for our usb images.

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 7, 2020):

@bahamat your live https://boot.netboot.xyz/2.0.8/index.html

@thelamer commented on GitHub (Feb 7, 2020): @bahamat your live https://boot.netboot.xyz/2.0.8/index.html

kerem commented

Author

Owner

@bahamat commented on GitHub (Feb 7, 2020):

@thelamer Nice! I was just adding an experimental platform image and noticed the Unix menu show up!

@bahamat commented on GitHub (Feb 7, 2020): @thelamer Nice! I was just adding an experimental platform image and noticed the Unix menu show up!

kerem commented

Author

Owner

@thelamer commented on GitHub (Feb 7, 2020):

Pinged omnios gitter to get a dialogue started just tracking link here https://gitter.im/omniosorg/Lobby

@thelamer commented on GitHub (Feb 7, 2020): Pinged omnios gitter to get a dialogue started just tracking link here https://gitter.im/omniosorg/Lobby

kerem commented