| opendevreview | cid proposed openstack/virtualpdu master: WIP: Vendor pysnmp-lextudio into virtupdu https://review.opendev.org/c/openstack/virtualpdu/+/928823 | 05:01 |
|---|---|---|
| rpittau | good morning ironic! o/ | 07:20 |
| opendevreview | Merged openstack/ironic master: doc/source/admin fixes part-1 https://review.opendev.org/c/openstack/ironic/+/929364 | 07:44 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Fix double transition to INSPECTFAIL on aborting in-band inspection https://review.opendev.org/c/openstack/ironic/+/930279 | 08:40 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-tempest-plugin master: Check inspection data and abortion in the standalone tests https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/927928 | 08:40 |
| dtantsur | Could I get a 2nd +2 please? https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/930028 https://review.opendev.org/c/openstack/ironic-python-agent/+/929766 https://review.opendev.org/c/openstack/bifrost/+/928896 | 08:41 |
| dtantsur | Thank you rpittau | 08:45 |
| rpittau | np! :) | 08:45 |
| iurygregory | good morning Ironic, I'm back o/ | 09:30 |
| dtantsur | \o/ | 09:30 |
| dtantsur | welcome back iurygregory | 09:30 |
| rpittau | welcome back iurygregory :) | 09:37 |
| iurygregory | tks o/ | 09:57 |
| opendevreview | Merged openstack/ironic-python-agent stable/2023.1: Unmount config drives https://review.opendev.org/c/openstack/ironic-python-agent/+/917852 | 10:14 |
| cid | welcome back, iurygregory | 10:19 |
| iurygregory | tks cid o/ | 10:19 |
| opendevreview | Merged openstack/ironic-tempest-plugin master: Provide consistent spelling of the microversion header https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/930028 | 10:28 |
| masghar | This doesnt look right: https://docs.openstack.org/ironic/latest/admin/drivers/redfish.html#:~:text=enabled_inspect_interfaces%20%3D%20inspector%2Credfish | 10:38 |
| masghar | (Also, hey Iury!) | 10:39 |
| dtantsur | masghar: you mean s/inspector/agent/ ? | 10:39 |
| iurygregory | masghar, hey o/ | 10:39 |
| dtantsur | agreed, patch welcome | 10:39 |
| opendevreview | Merged openstack/ironic-python-agent master: Trivial: fix variable in formatting https://review.opendev.org/c/openstack/ironic-python-agent/+/929766 | 10:39 |
| masghar | dtantsur: yes | 10:39 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-python-agent stable/2024.2: Trivial: fix variable in formatting https://review.opendev.org/c/openstack/ironic-python-agent/+/930286 | 10:40 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-python-agent stable/2024.1: Trivial: fix variable in formatting https://review.opendev.org/c/openstack/ironic-python-agent/+/930287 | 10:41 |
| iurygregory | if anyone has something urgent that needs review feel free to ping me, I'm still catching up on emails after 3 weeks off | 10:43 |
| opendevreview | Merged openstack/bifrost master: CI: pin the benchmark job to ubuntu-jammy https://review.opendev.org/c/openstack/bifrost/+/928896 | 10:43 |
| opendevreview | Mahnoor Asghar proposed openstack/ironic master: Fix inspect interface for redfish driver in the docs https://review.opendev.org/c/openstack/ironic/+/930288 | 10:57 |
| dtantsur | masghar: you changed the wrong one ^^ | 11:01 |
| masghar | dtantsur: Did I? | 11:02 |
| dtantsur | masghar: you changed redfish, not inspector | 11:03 |
| masghar | Redfish is a valid inspect interface? :O | 11:05 |
| masghar | It is! | 11:06 |
| opendevreview | Mahnoor Asghar proposed openstack/ironic master: Fix inspect interface for redfish driver in the docs https://review.opendev.org/c/openstack/ironic/+/930288 | 11:08 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: Firmware Update via Firmware Interface Docs https://review.opendev.org/c/openstack/ironic/+/926961 | 11:19 |
| dtantsur | masghar: redfish is an out-of-band inspection interface, yes | 11:22 |
| dtantsur | yay, the new inspection tests finally pass at https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/927928 (and even caught an actual bug in ironic) | 11:26 |
| dtantsur | JayF: since you've reviewed before ^^ | 11:27 |
| opendevreview | Merged openstack/ironic master: Fix inspect interface for redfish driver in the docs https://review.opendev.org/c/openstack/ironic/+/930288 | 12:49 |
| opendevreview | Merged openstack/ironic-python-agent stable/2024.2: Trivial: fix variable in formatting https://review.opendev.org/c/openstack/ironic-python-agent/+/930286 | 13:06 |
| derekh | Hey @TheJulia , I'm testing out the redfish https boot driver and all is going ok on virt with sushy-tools but when trying on baremetal I don't see the 'HttpBootUri' value exposed over redfish , just wondering if there are any vendors that you know should support it? (have tied Dell and HP so far) | 13:09 |
| iurygregory | derekh, I would say it's possible that some vendor is not exposing yet, which firmware version you have installed? | 13:11 |
| TheJulia | good morning | 13:11 |
| TheJulia | derekh: Yeah, the field name is taken from the DMTF reference and cross referenced with ?ilo? hardware if memory serves. A lack of it signals either the firmware is too old since that came about in ComputerSystem ?1.9? or the vendor has chosen not to support it | 13:12 |
| derekh | @iurygregory, Dell: BIOS Version 2.17.2, iDRAC Firmware Version 7.00.00.173 | 13:13 |
| derekh | HP: System ROM U30 v3.32 (08/29/2024), iLO 5 3.07 Aug 09 2024 | 13:13 |
| TheJulia | Interesting | 13:13 |
| iurygregory | oh wow O.o | 13:15 |
| dtantsur | so it may very well be possible that no hardware actually supports UEFI HTTP boot? | 13:15 |
| derekh | The one thing I managed to do is set http boot url in the idrac web console (not practial I know) | 13:15 |
| derekh | the host then runs "HEAD" against the iso file but doesn't download it, after many attempts changing things (ip, ports, http vs https etc...), | 13:15 |
| derekh | I found that its the Content-Type it is looking at, when I give it a text file the hardware downloads the file (HEAD followed by GET) but then fails | 13:15 |
| derekh | I'm thinking its not looking for a iso at all but rather a script to load the iso, | 13:15 |
| TheJulia | or they could be hiding it behind setting the mode override first?! | 13:15 |
| TheJulia | "longDescription": "This property shall contain the URI to perform an HTTP or HTTPS boot when `BootSourceOverrideTarget` is set to `UefiHttp`. If this property is not configured or supported, the URI shall be provided by a DHCP server as specified by the UEFI Specification.", | 13:16 |
| iurygregory | makes sense ^ | 13:17 |
| TheJulia | Honestly, I'd open cases with vendors because hacking at hidden behavior is not ideal when the standard is fairly clear | 13:17 |
| TheJulia | and super surprising it is not in the ilo your looking at | 13:18 |
| derekh | I havn't attempted to set it with dhcp, it wasn't the use case I was trying to test | 13:18 |
| TheJulia | like, *really* surprised | 13:18 |
| dtantsur | derekh: if you're up for some manual testing, you could try setting BootSourceOverrideTarget first | 13:18 |
| dtantsur | if we find that no hardware actually works... it will be pretty embarrassing. | 13:18 |
| derekh | I'm already in manual testing mode so I'll give it a go | 13:19 |
| rpittau | according to sparse documentation, at least on DELL there are various settings to enable UEFI HTTP, on the BIOS config | 13:19 |
| derekh | an example of what I've seen so far | 13:20 |
| rpittau | same on HP, AFAICS | 13:21 |
| derekh | Dell: curl -ks -u XXX -X PATCH https://XXX/redfish/v1/Systems/System.Embedded.1 -H 'Content-Type: application/json' -d '{"Boot": {"BootSourceOverrideTarget": "UefiHttp", "BootSourceOverrideEnabled": "Once", "HttpBootUri": "http://XXX:6180/redfish/boot-27c76abb-20cd-4ff9-96b7-e51f9705658c.iso"}}' | 13:21 |
| derekh | {"error":{"@Message.ExtendedInfo":[{"Message":"The property HttpBootUri is not in the list of valid properties for the resource.", | 13:21 |
| derekh | HP: curl -ks -u XXX -X PATCH https://dXXX/redfish/v1/Systems/1 -H 'Content-Type: application/json' -d '{"Boot": {"BootSourceOverrideTarget": "UefiHttp", "BootSourceOverrideEnabled": "Once", "HttpBootUri": "https://XXX/image.iso"}}' | 13:21 |
| derekh | {"error":{"code":"iLO.0.10.ExtendedInfo","message":"See @Message.ExtendedInfo for more information.","@Message.ExtendedInfo":[{"MessageArgs":["HttpBootUri"],"MessageId":"iLO.2.13.PropertyNotWritableOrUnknown"}]}} | 13:21 |
| dtantsur | derekh: what if you try without HttpBootUri in the first requested and only with HttpBootUri in the 2nd? | 13:22 |
| dtantsur | maybe it needs to be "turned on"... | 13:22 |
| iurygregory | ++ | 13:22 |
| TheJulia | looks like in the most recently published ilo schemas, its just not there which is silly since they've had underlying support in the bmc since the ilo4 days to do it | 13:23 |
| TheJulia | (for ilo) | 13:23 |
| iurygregory | yay... | 13:24 |
| TheJulia | on a plus side, it *is* explicitly in https://docs.nvidia.com/networking/display/bluefielddpuosv470/redfish | 13:24 |
| dtantsur | Well, we cannot declare something supported based on reading docs alone | 13:24 |
| dtantsur | It starts looking like we need to mark it as experimental in Ironic and pull it out of Metal3 (sorry derekh!) | 13:25 |
| iurygregory | it would be good if we had bluefield to test it... | 13:26 |
| dtantsur | If there is a way to turn it on, either via Redfish or by users manually, we can document it | 13:26 |
| dtantsur | Well.. we don't have bluefields and how knows if we get them in 2025 | 13:26 |
| iurygregory | yeah =( | 13:26 |
| derekh | give me a little more time to 1. make doubly sure I'm not doing something stupid or it isn't easliy fixable | 13:26 |
| derekh | or 2 find some other vendors to check against | 13:26 |
| dtantsur | +++ | 13:27 |
| TheJulia | Well, the original driver was due to Bluefield for the URL provided path, but yeah... If other vendors are ignoring it that is not great. We did the leg work this time last year and I think expected bits standardized the year before that | 13:30 |
| dtantsur | As always with Redfish, the vendors can happily ignore the bits that don't bring them cash | 13:31 |
| dtantsur | given that virtual media is very popular, they may see UEFI HTTP boot via Redfish as redundant, and I cannot fully blame them | 13:31 |
| TheJulia | yup, unfortunate. | 13:31 |
| TheJulia | I *really* don't see that. I have a slew of people demanding pxe boot forever which is also just not realistic *either*. | 13:32 |
| TheJulia | le sigh | 13:32 |
| dtantsur | I guess it's either PXE or virtual media for the vendors | 13:33 |
| TheJulia | at least the dhcp path should be delineated, but I know to you guys, that is likely non-viable | 13:33 |
| TheJulia | well, what is weird and frustrating is vendors like to also hide it on hardware | 13:33 |
| dtantsur | we can consider it when iPXE will start getting phased out | 13:33 |
| dtantsur | but otherwise, it brings us very few benefits over what we have | 13:33 |
| TheJulia | That path is already happening, but will likely never happen upstream. It will be driven by market forces of operators who have to be in secure boot mode at all times due to regulations | 13:34 |
| dtantsur | How large is the overlap between operators who need secure boot and operators who cannot possibly use virtual media? | 13:34 |
| TheJulia | semi-substantial if I take field feedback with a grain of salt. Some if it is architectural constraints/issues where BMCs just simply are not allowed to reach out in some secure environments. The others might just be a predicated context bias against anything they don't know so they want the warm blanket of pxe | 13:37 |
| TheJulia | some of that issue may just be operators trying to do test deployments with old hardware which has no support for vmedia as well, minimal clarity there. | 13:38 |
| dtantsur | To be clear: when I say "cannot possibly", I don't mean bias and prejustice | 13:39 |
| TheJulia | derekh: what version of computersystem is the remote endpoint returning? | 13:40 |
| TheJulia | for ilo specifically? | 13:41 |
| dtantsur | I'm curious how many will drop out even if pressure is applied vs accepting their fate and upgrading their ilo4 to something sane :) | 13:41 |
| * TheJulia found an example ilo schema returning computersystem 1.15 with the field set to null.... | 13:41 | |
| TheJulia | Well, Superdome Flex | 13:42 |
| derekh | "@odata.type": "#ComputerSystem.v1_17_0.ComputerSystem", | 13:42 |
| TheJulia | hmm | 13:43 |
| TheJulia | Thanks HPE | 13:44 |
| dtantsur | If only these versions meant anything.. (thank you HPE and DMTF) | 13:44 |
| TheJulia | Exactly! | 13:44 |
| * TheJulia makes more coffee to be able to use words during the first meeting of the day | 13:44 | |
| JayF | TheJulia: just noting there's still a giant contingent of server installations that will not be required to secure boot. I think we've got to be careful about engineering ourselves into a corner at the expense of those environments... Especially re: the comment about not being able to support pxe forever | 14:09 |
| JayF | I'm not saying that I wouldn't suggest folks even in those environments use virtual media if possible, I'm just saying there's absolutely zero urgency in those situations to make a change | 14:10 |
| TheJulia | The *bulk* of our deployments are in telecom environments, so if we don't have a solid forward path, we're the technology being ripped out. | 14:13 |
| JayF | I'm not saying we shouldn't have a forward path, I'm saying we shouldn't force the numerous installations that don't have that requirement to accept it | 14:18 |
| JayF | And while I'm sure you're right when talking about total server count, I don't think the majority of ironic installations are in Telecom environments | 14:19 |
| TheJulia | I guess what I'm trying to say is that we shouldn't rest on our laurels. We also must not intentionally break, but we must anticipate packagers are going to begin to break things out from under us as they move forward to meet newer regulations. | 14:28 |
| JayF | Potentially yes, but from an ecosystem standpoint I know that I will find it incredibly frustrating if some of our users who don't have those regulatory barriers have them built anyway by the distribution providers | 14:30 |
| JayF | For stuff like that ironic is along for the ride, but it will be very frustrating if the needs of the mega scale regulated industry drive how the more normal size clouds have to be operated | 14:31 |
| dtantsur | TheJulia: as a data point, it is telecoms that are primarily driving the demand for virtual media in my world | 14:32 |
| dtantsur | many of them have enough leverage to actively negotiate supported hardware features with vendors | 14:33 |
| TheJulia | Its not just needs, often the telcoms are the forcing early adopters through the need to build and sustain the next wave of technology rollout. | 14:35 |
| TheJulia | I'm getting an entirely opposite feedback loop. Although I know some of those same telecoms and have a bit more faith in the virtual media case. | 14:37 |
| TheJulia | s/telcoms/telecoms/ | 14:37 |
| dtantsur | But also I tend to agree with JayF: a lot of smaller shops don't and won't care about secure boot | 14:38 |
| TheJulia | At least, until the government regulator goes in and sees they don't meet compliance ;) | 14:39 |
| TheJulia | I need to follow-up and see where the regulation package CISA was driving is at | 14:40 |
| TheJulia | The nuking of the the Chevron Deference means those smalls hops can litigate it into courts | 14:40 |
| TheJulia | s/small hops/small shops/ | 14:40 |
| TheJulia | Come to think of it, that may never be finalized since the courts decided the courts make the rules | 14:41 |
| dtantsur | the government regulator does not concern anyone, even if we focus only on the USA | 14:41 |
| TheJulia | Regulators who can levy fines not concerning anyone? | 14:42 |
| JayF | Not everyone is regulated | 14:46 |
| JayF | dtantsur: TheJulia: I think my concern is this: Telecoms are over-represented in the "ability to pay for support and make loud noises about support" category, which influences OpenStack a lot. I don't see telecoms at BM SIG meetings, or at user group meetups -- I see smaller shops; universities, medium-sized clouds, etc | 14:47 |
| TheJulia | Indeed, but depending on vertical, regulation can be a bit extreme. | 14:47 |
| JayF | so I want to ensure we're looking out for the full rainbow of our users and not just the noisiest ones | 14:48 |
| TheJulia | That is fine, I can't solve the telcom's desire to operate in industry centric circles. | 14:49 |
| JayF | They are clued into what GR-OSS tries to sell the smaller/more niche shops on: being public about your needs and cloud use cases gets them more attention :) | 14:52 |
| TheJulia | Indeed, in their own ways | 14:56 |
| * TheJulia remembers the berlin operators meetup | 14:57 | |
| rpittau | need to drop, see you tomorrow! o/ | 15:20 |
| TheJulia | o/ | 15:20 |
| opendevreview | Merged openstack/ironic-python-agent stable/2024.1: Trivial: fix variable in formatting https://review.opendev.org/c/openstack/ironic-python-agent/+/930287 | 15:35 |
| opendevreview | Merged openstack/bifrost stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/bifrost/+/930031 | 16:10 |
| dtantsur | a bug I've discovered today, if anyone has a minute: https://review.opendev.org/c/openstack/ironic/+/930279 | 16:14 |
| masghar | General question: How long does a cleaning operation normally take? (I used the baremetal node provide command) | 16:39 |
| JayF | it varies with the size of the disks | 16:40 |
| masghar | I have a 10 GB VM | 16:40 |
| JayF | in devstack configs it usually takes ~minutes | 16:40 |
| JayF | like 5 minutes at most | 16:40 |
| masghar | Alrightie, thanks | 16:41 |
| JayF | might wanna check your ironic-bm-logs in /opt/stack/ironic-bm-logs to see if something didn't boot causing a timeout | 16:41 |
| JayF | if it's taking a while | 16:41 |
| masghar | I'm using bifrost, let me see... | 16:41 |
| JayF | I don't know where those logs are in bifrost testenv | 16:42 |
| masghar | Yeah, but there's gotta be an equivalent | 16:43 |
| masghar | ramdisk logs, perhaps | 16:43 |
| JayF | ++ | 16:43 |
| JayF | I just pushed https://review.opendev.org/c/openstack/oslo.utils/+/930365 to help start the discussion around how Ironic can interact with this code | 17:15 |
| JayF | I'm more than a little worried about a future of e.g. MBRInspector or CrazyWeirdPartitionTableInspector or similar continuing to change the definition of "raw" | 17:15 |
| JayF | and I really, really don't want us to have to maintain a list in Ironic that we have to worry about pinning to oslo.utils versions | 17:16 |
| JayF | dtantsur: TheJulia ^ since I know you were both looking at impacted code | 17:19 |
| JayF | I'm not sure I'm doing the best job explaining what's going on | 17:21 |
| clarkb | JayF: TheJulia: looking at that code the gpt detections loooks at bytes 512-1024 which may not be correct for 4k sector images (I think based on earlier discussions putting 4k support into dib) | 17:25 |
| JayF | nice catch | 17:25 |
| JayF | We should probably bug that | 17:25 |
| TheJulia | clarkb: that is actually wrong too | 17:25 |
| TheJulia | clarkb: that assumes a 512 byte block size | 17:25 |
| TheJulia | which is totally wrong | 17:26 |
| clarkb | TheJulia: yup that is what I thought thanks for confirming. It needs to check both sets of bytes | 17:26 |
| JayF | do one of you want to file the bug since you know it better? | 17:26 |
| JayF | I can if you can't though | 17:26 |
| clarkb | self.new_region('gpt', CaptureRegion(512, 512)) <- is specifically the too narrowly focused code | 17:26 |
| TheJulia | clarkb: 512 byte, 1k block, 2k block, and 4k block sizes | 17:26 |
| TheJulia | yup | 17:27 |
| * JayF doing the thing with that detail | 17:27 | |
| TheJulia | cool, thanks | 17:27 |
| JayF | https://bugs.launchpad.net/oslo.utils/+bug/2081872 | 17:29 |
| JayF | I put some notes in #openstack-oslo | 17:44 |
| JayF | but tl;dr: https://opendev.org/openstack/nova/src/branch/master/nova/virt/images.py#L164 nova basically keeps it's "no really, it's actually raw" detection code inside their codebase | 17:44 |
| JayF | so we could do the same but it seems like a setup for future failure | 17:44 |
| cardoe | So speaking of docs that almost get you there... IPA... am I suppose to use ARI / AKI with glance for those? what about esp.img? | 18:08 |
| JayF | raw/raw AIUI today | 18:11 |
| JayF | we updaed ironic docs o say the right thing | 18:11 |
| JayF | but we definately need a better type for those | 18:12 |
| TheJulia | "raw" is the closest meaning, even though they are boot related arifats. ARI/AKI are legacy meanings which were erroniously latched on to | 18:36 |
| TheJulia | clarkb: esp.img is just a vfat filesystem, so... raw for now. That may need to change/evolve in the future if there is further delineation | 18:36 |
| clarkb | cardoe: ^ tab complete failure I assume | 18:37 |
| TheJulia | yup, sorry | 18:37 |
| clarkb | no worries. It happens to me all the time too | 18:37 |
| JayF | TheJulia: dansmith: one thing this conversation makes super clear: we probably need a first class kernel/ramdisk type that's not aki/ari -- since we're now calling them 'raw' and we don't want raw to be raw forever | 18:37 |
| dansmith | JayF: I think I've said that several times over the last couple of months, sometimes in public and sometimes even without profanity :) | 18:38 |
| JayF | hey, you got us to update our docs from aki/ari -> raw, so that's something | 18:38 |
| JayF | lol | 18:38 |
| JayF | it's just hard to define what a 'ramdisk' is | 18:38 |
| TheJulia | rpittau: I put another item on to the ptg etherpad specifically regarding the baremetal sig and building more intentionality. There is a related community wide conversation I'm having in trying to basically bridge some of the gaps and siloing we've all built up and maintain over the years. | 18:39 |
| JayF | since even initramfses can be multiple things | 18:39 |
| dansmith | yep | 18:39 |
| TheJulia | "some sort of compressed cpio" ?!? | 18:39 |
| * TheJulia is tossing it out there | 18:39 | |
| dansmith | there are multiple ways | 18:40 |
| dansmith | JayF: I assume you've seen my glance spec on this topic | 18:40 |
| JayF | I will have in like 5 minutes | 18:40 |
| dansmith | assume you'll want to attend ptg talks on the matter | 18:40 |
| JayF | TheJulia: squashfses can be compressed like 10 different ways :/ | 18:40 |
| TheJulia | JayF: indeed | 18:41 |
| JayF | TheJulia: I just had to rebuild my squashfs-tools with xz because ubuntu and gentoo use different defaults :D | 18:41 |
| dansmith | tl;dr is "add gpt as a glance disk_format" and "make glance reject lies and damned lies on upload" | 18:41 |
| TheJulia | on first pass reading, I read it as wanting lies on upload | 18:41 |
| dansmith | TheJulia: we have lies on upload now | 18:42 |
| TheJulia | i know :) | 18:42 |
| dansmith | tbh, glance is "Lies as a Service" today | 18:42 |
| JayF | hey, we do plenty of lying too | 18:42 |
| JayF | as a standalone service, we can't rely only on other openstack services to lie for us /s | 18:42 |
| JayF | lol | 18:42 |
| TheJulia | lol | 18:42 |
| dansmith | guess we need oslo-lies then | 18:42 |
| clarkb | dansmith: re the gpt and block size thing I think the issue is you're capturing bytes 512-1023 but LBA1 may be at bytes 1024-2047, 2048-4095, or 4096-8191 depending on the hardware block size the image is intended to be used with. But reading the code more closely you don't actually seem to be using the content at LBA1 (yet?) and instead just verify the protective MBR record | 18:43 |
| clarkb | which is always in the first 512 bytes I think | 18:43 |
| dansmith | clarkb: yep | 18:43 |
| clarkb | maybe just need a note in there to adjust the region capture for "gpt" if you start to use it to figure out block size | 18:43 |
| dansmith | I can just remove it like the end-block one as it's just there for me to be able to easily inspect the next sector, | 18:43 |
| dansmith | but as you can see it really doesn't need to even be there | 18:44 |
| JayF | TIL that gpt is a superset of MBR | 18:44 |
| JayF | it makes sense knowing how all it works, I just never looked at it through that lens | 18:44 |
| clarkb | JayF: sort of. GPT writes out an MBR record that says "I'm not a valid MBR setup" essentially | 18:44 |
| clarkb | more of a warning sign alongside gpt than a true superset | 18:44 |
| dansmith | JayF: I was happy to learn than a couple months ago, because it made this change half as big | 18:44 |
| JayF | the glance spec implies that a legacy MBR partition table will be detected as GPT | 18:45 |
| dansmith | clarkb: you're referring to the "protective mbr" which is definitely a valid mbr | 18:45 |
| clarkb | dansmith: ya its valid but it's valid structurally not for booting anything right? | 18:45 |
| dansmith | it just "covers" the whole disk as a single paritition (to the extent it can represent the size) | 18:45 |
| dansmith | clarkb: no, it's plenty valid | 18:45 |
| dansmith | its not BIOS machines boot gpt disks | 18:46 |
| clarkb | right | 18:46 |
| dansmith | so everything since Windows Vista or something | 18:46 |
| dansmith | s/not/how/ | 18:46 |
| clarkb | oh huh ok | 18:46 |
| clarkb | TIL | 18:46 |
| JayF | yep | 18:46 |
| dansmith | it's ignored by UEFI, but BIOS machines still do the same thing they always have | 18:46 |
| JayF | in windows world they call that setup hybrid MBR | 18:46 |
| JayF | which is deceiving | 18:47 |
| dansmith | JayF: subtly different I think: https://www.rodsbooks.com/gdisk/hybrid.html | 18:47 |
| dansmith | "A hybrid MBR is a variant on the normal protective MBR" | 18:47 |
| dansmith | you are all super surprised that this is complicated right? I mean compatibility back to the intel 4004 ain't free :D | 18:47 |
| clarkb | we should probably be happy there are only as many variants of this as there are and not a different one for each bios/uefi manufacturer :/ | 18:48 |
| JayF | got it, hybrid MBR is the normal thing + some stuff to essentially mirror partition metadata for the first 3 | 18:48 |
| dansmith | clarkb: exactly | 18:48 |
| JayF | dansmith: if there's any team that expects complexity to be hidden everywhere I think/hope it's us :P | 18:48 |
| dansmith | clarkb: apple be like ROFL to the bank | 18:48 |
| JayF | hardware is lies | 18:48 |
| clarkb | dansmith: the best thing about that 4004 linux boot is that it does so emulating another cpu | 18:48 |
| JayF | I've never used a 4044 either :D | 18:48 |
| JayF | I did have an 8088 as my first computer when I was 5 years old lol | 18:48 |
| dansmith | clarkb: well, I really just mean compatibility back to the original PC in terms of this sort of on-disk-format, but yeah :D | 18:49 |
| JayF | anything I get wrong here, it's all DOS 3.3's fault | 18:49 |
| TheJulia | Lets just boil it down. | 18:49 |
| TheJulia | It is all digital computing through the byte. | 18:49 |
| TheJulia | Bring back Analog computers! | 18:49 |
| dansmith | btw, have you seen my spec about redefining the byte to be 9 bits | 18:50 |
| dansmith | ? | 18:50 |
| JayF | that's a baker's byte, right? | 18:50 |
| TheJulia | dansmith: it is too early to start drinking whiskey | 18:50 |
| dansmith | JayF: nice | 18:50 |
| TheJulia | is this a serious thing?! | 18:50 |
| dansmith | lol | 18:50 |
| dansmith | technically memory with parity kinda does it that way :D | 18:51 |
| clarkb | there were 9 bit byte machiens in the 70s right? | 18:51 |
| clarkb | 7 too (tahts why ascii fits in 7?) | 18:51 |
| JayF | TheJulia: I should say what I said to dansmith in the other channel: we need to get this deleted from the logs before hardware vendors start getting /ideas/ | 18:51 |
| dansmith | clarkb: lots of drug use in the 70s | 18:51 |
| JayF | "With our new Value Added Byte(tm) the new SuperO BMC is 112.5% better than other BMCs" | 18:52 |
| TheJulia | clarkb: I remember something about the apollo guidance computer on the LIM had 6 data + 1 byte checksum | 18:52 |
| dansmith | clarkb: not sure if you saw, but doing this I also learned that the first 512 bytes of FAT is *actually* a fully-functional MBR as well | 18:52 |
| JayF | s/Byte/Bit/ | 18:52 |
| TheJulia | err, bits, not bytes | 18:52 |
| dansmith | clarkb: same exact structure and signature so that BIOS could boot a partition-less floppy and a partitioned HDD the same way.. very inconvenient in 2024, | 18:52 |
| clarkb | dansmith: I missed that but that kinda makes sense from a "disks were really small back in the day" perspective and wanting to save 512 bytes | 18:53 |
| dansmith | but like literally mkfs.vfat and qemu-img will think it's an MBR | 18:53 |
| * JayF just thought about SS/SD 5.25" floppies at 360k and how they interact with this | 18:53 | |
| TheJulia | Yeah, that whole thing has long resulted in headaches | 18:53 |
| JayF | I guess it just works lol | 18:53 |
| JayF | holy cow, cid fixed virtualpdu \o/ | 21:51 |
| JayF | https://78a110595fc88b4411e7-edb00ca96527ed918ece6dbb3b21bd21.ssl.cf2.rackcdn.com/928823/4/check/ironic-tempest-wholedisk-bios-snmp-pxe-virtualpdu-src/5908996/controller/logs/screen-virtualpdu.txt | 21:51 |
| JayF | https://review.opendev.org/c/openstack/virtualpdu/+/928823 unit tests not passing | 21:52 |
| JayF | but the jobs themselves are | 21:52 |
| JayF | good stuff | 21:52 |
| * JayF put a lengthy comment on the format inspector ironic pr: https://review.opendev.org/c/openstack/ironic/+/929904/2#message-df453735a66b7c2e63fbc42cceb61ff4b82d70b6 | 22:13 | |
| opendevreview | Merged openstack/ironic master: Move the benchmark job to the experimental pipeline https://review.opendev.org/c/openstack/ironic/+/928897 | 23:14 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!