)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"f7a6a1ed9387284a1b8b2e9d7e5eec0505822a5b","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Lenovo SR645 V3 systems enter a boot loop after provisioning because"},{"line_number":10,"context_line":"the generic \u0027Hdd\u0027 boot target (Boot0002) bypasses the Red Hat shim"},{"line_number":11,"context_line":"bootloader (Boot0004 \u0027redhat\u0027). Without the shim, RHCOS cannot boot."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"After setting the disk boot device on Lenovo systems, clear the boot"},{"line_number":14,"context_line":"override to allow the UEFI boot order (which has the Red Hat shim"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"b7366318_1728f36e","line":11,"updated":"2026-04-29 09:29:13.000000000","message":"Are we sure it\u0027s not a CoreOS bug? What does the generic Hdd target even do?","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"a9ef4a10ea32bfc565f1f5cf60673097e1566c57","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Lenovo SR645 V3 systems enter a boot loop after provisioning because"},{"line_number":10,"context_line":"the generic \u0027Hdd\u0027 boot target (Boot0002) bypasses the Red Hat shim"},{"line_number":11,"context_line":"bootloader (Boot0004 \u0027redhat\u0027). Without the shim, RHCOS cannot boot."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"After setting the disk boot device on Lenovo systems, clear the boot"},{"line_number":14,"context_line":"override to allow the UEFI boot order (which has the Red Hat shim"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"e40cd346_297d4e59","line":11,"in_reply_to":"6441d1c0_ee912878","updated":"2026-05-12 14:37:06.000000000","message":"Please fix.","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"ea220a7485462b4a9c2df43df91b61542a907d9a","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Lenovo SR645 V3 systems enter a boot loop after provisioning because"},{"line_number":10,"context_line":"the generic \u0027Hdd\u0027 boot target (Boot0002) bypasses the Red Hat shim"},{"line_number":11,"context_line":"bootloader (Boot0004 \u0027redhat\u0027). Without the shim, RHCOS cannot boot."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"After setting the disk boot device on Lenovo systems, clear the boot"},{"line_number":14,"context_line":"override to allow the UEFI boot order (which has the Red Hat shim"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"edaac11f_93ca1328","line":11,"in_reply_to":"b7366318_1728f36e","updated":"2026-04-29 11:21:42.000000000","message":"What Hdd does on Lenovo:                                                                                                                                                                                                      \n  - Maps to Boot0002 \"Hard Disk\" - tries to boot directly from physical disk\n  - Bypasses UEFI boot entries like Boot0004 \"redhat\" (the shim)                                                                                                                                                                \n  - RHCOS requires the shim to boot - it\u0027s there and works, but Hdd skips it\n                                                                                                                                                                                                                                \n  Why it\u0027s not CoreOS:                                                                                                                                                                                                          \n  - RHCOS boots fine when you manually select \"Continue boot\" - proves the OS works                                                                                                                                             \n  - The shim is correctly installed at Boot0004                                                                                                                                                                                 \n  - It\u0027s a Lenovo BMC limitation - their Hdd implementation doesn\u0027t use UEFI boot order like other vendors do","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"40ff90841ffc811e0d4b00bd22c5e8b89d54fa75","unresolved":false,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Lenovo SR645 V3 systems enter a boot loop after provisioning because"},{"line_number":10,"context_line":"the generic \u0027Hdd\u0027 boot target (Boot0002) bypasses the Red Hat shim"},{"line_number":11,"context_line":"bootloader (Boot0004 \u0027redhat\u0027). Without the shim, RHCOS cannot boot."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"After setting the disk boot device on Lenovo systems, clear the boot"},{"line_number":14,"context_line":"override to allow the UEFI boot order (which has the Red Hat shim"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"5e4e5b6b_c1174dc7","line":11,"in_reply_to":"e40cd346_297d4e59","updated":"2026-05-12 15:24:29.000000000","message":"Done","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"4290008113e841b2b601f2b2924f1e90c7fb0e84","unresolved":true,"context_lines":[{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Lenovo SR645 V3 systems enter a boot loop after provisioning because"},{"line_number":10,"context_line":"the generic \u0027Hdd\u0027 boot target (Boot0002) bypasses the Red Hat shim"},{"line_number":11,"context_line":"bootloader (Boot0004 \u0027redhat\u0027). Without the shim, RHCOS cannot boot."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"After setting the disk boot device on Lenovo systems, clear the boot"},{"line_number":14,"context_line":"override to allow the UEFI boot order (which has the Red Hat shim"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"6441d1c0_ee912878","line":11,"in_reply_to":"edaac11f_93ca1328","updated":"2026-05-11 19:35:57.000000000","message":"Ideally we\u0027d re-write this commit message in a generic manner, without mention of coreos/redhat -- as this reads, it reads like a RH-specific issue; but based on this context it\u0027s a hardware workaround.","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"ff850bece2c769a561ecdc126c1e3b66e7ed1e6f","unresolved":true,"context_lines":[{"line_number":14,"context_line":"override to allow the UEFI boot order (which has the Red Hat shim"},{"line_number":15,"context_line":"first) to handle the boot process."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Fixes bug: https://bugs.launchpad.net/ironic/+bug/2150628"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Change-Id: I500e1dc728ba4dc948a0a6bdbd993b519b01141e"},{"line_number":20,"context_line":"Signed-off-by: Jad Haj Yahya \u003cjhajyahy@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"d3ae4137_ea337739","line":17,"updated":"2026-05-11 19:36:45.000000000","message":"The correct format for our automation is:\n\nCloses-bug: #2150628\n\n(Related-bug: #bugnum would associate it with the bug, but not consider it resolved on merge)","commit_id":"e0b77c4cdb1076f5b5ac8153031eb6a4fa08548a"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"8323335b86429105b0d1137c350e1223ce5e310b","unresolved":false,"context_lines":[{"line_number":14,"context_line":"override to allow the UEFI boot order (which has the Red Hat shim"},{"line_number":15,"context_line":"first) to handle the boot process."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Fixes bug: https://bugs.launchpad.net/ironic/+bug/2150628"},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Change-Id: I500e1dc728ba4dc948a0a6bdbd993b519b01141e"},{"line_number":20,"context_line":"Signed-off-by: Jad Haj Yahya \u003cjhajyahy@redhat.com\u003e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"0645df33_b56eab7d","line":17,"in_reply_to":"d3ae4137_ea337739","updated":"2026-05-12 07:50:53.000000000","message":"Done","commit_id":"e0b77c4cdb1076f5b5ac8153031eb6a4fa08548a"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"f7a6a1ed9387284a1b8b2e9d7e5eec0505822a5b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a1885375_03433954","updated":"2026-04-29 09:29:13.000000000","message":"Needs a release note + two comments inline","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"a9ef4a10ea32bfc565f1f5cf60673097e1566c57","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"1d2ea350_414dbc8d","updated":"2026-05-12 14:37:06.000000000","message":"Restoring my -1.","commit_id":"3892479139e554bcbef00a74686d62de287fdb12"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"918d0ea89777f65a13911d0cae1454fd3fd3442e","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":15,"id":"173ebaab_84c5d8ba","updated":"2026-06-09 17:46:26.000000000","message":"GR-OSS team review. Please DRY.","commit_id":"ec36889ac1a983798d5845d8fc0e80f6a6f72f17"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"d35ad0d22dee4ec380004d7df3317774e8898553","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":15,"id":"20145fa6_a91efd8d","in_reply_to":"173ebaab_84c5d8ba","updated":"2026-06-10 07:46:34.000000000","message":"Acknowledged","commit_id":"ec36889ac1a983798d5845d8fc0e80f6a6f72f17"}],"ironic/drivers/modules/redfish/boot.py":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"918d0ea89777f65a13911d0cae1454fd3fd3442e","unresolved":true,"context_lines":[{"line_number":1117,"context_line":"            # For more information see"},{"line_number":1118,"context_line":"            # https://bugs.launchpad.net/ironic/+bug/2150628 and"},{"line_number":1119,"context_line":"            # https://bugs.launchpad.net/ironic/+bug/2053064"},{"line_number":1120,"context_line":"            vendor \u003d node.properties.get(\u0027vendor\u0027, None)"},{"line_number":1121,"context_line":"            target_boot_mode \u003d boot_mode_utils.get_boot_mode(node)"},{"line_number":1122,"context_line":""},{"line_number":1123,"context_line":"            if not (vendor and vendor.lower() \u003d\u003d \u0027lenovo\u0027"}],"source_content_type":"text/x-python","patch_set":15,"id":"99b6f1ba_91b60a9a","line":1120,"updated":"2026-06-09 17:46:26.000000000","message":"This code and the ~20 lines below are repeated multiple times in this file. Can we add a helper which will set the boot device only if not Lenovo? That will also make it much less likely that we miss a workaround case -- which is the root cause of the bug this is fixing in the first place.","commit_id":"ec36889ac1a983798d5845d8fc0e80f6a6f72f17"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"d35ad0d22dee4ec380004d7df3317774e8898553","unresolved":false,"context_lines":[{"line_number":1117,"context_line":"            # For more information see"},{"line_number":1118,"context_line":"            # https://bugs.launchpad.net/ironic/+bug/2150628 and"},{"line_number":1119,"context_line":"            # https://bugs.launchpad.net/ironic/+bug/2053064"},{"line_number":1120,"context_line":"            vendor \u003d node.properties.get(\u0027vendor\u0027, None)"},{"line_number":1121,"context_line":"            target_boot_mode \u003d boot_mode_utils.get_boot_mode(node)"},{"line_number":1122,"context_line":""},{"line_number":1123,"context_line":"            if not (vendor and vendor.lower() \u003d\u003d \u0027lenovo\u0027"}],"source_content_type":"text/x-python","patch_set":15,"id":"f63f4a2e_eaa57309","line":1120,"in_reply_to":"99b6f1ba_91b60a9a","updated":"2026-06-10 07:46:34.000000000","message":"Acknowledged","commit_id":"ec36889ac1a983798d5845d8fc0e80f6a6f72f17"},{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"a32501f431a49eb1332b407d8c92ed48656a34a3","unresolved":true,"context_lines":[{"line_number":1258,"context_line":"                return"},{"line_number":1259,"context_line":""},{"line_number":1260,"context_line":"        # Set the requested boot device for all other systems"},{"line_number":1261,"context_line":"        manager_utils.node_set_boot_device(task, device, persistent)"},{"line_number":1262,"context_line":""},{"line_number":1263,"context_line":"    @classmethod"},{"line_number":1264,"context_line":"    def _set_boot_device(cls, task, device, persistent\u003dFalse):"}],"source_content_type":"text/x-python","patch_set":18,"id":"f91852d0_06cac181","line":1261,"updated":"2026-06-25 16:04:23.000000000","message":"This method should call _set_boot_device, which is overridden in the iDRAC child class.","commit_id":"34755bd1a651698376a6f62a76eb76bdfd2aedd3"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"e2eae62eb2687061a2dd0dfca3f788777ba68d78","unresolved":false,"context_lines":[{"line_number":1258,"context_line":"                return"},{"line_number":1259,"context_line":""},{"line_number":1260,"context_line":"        # Set the requested boot device for all other systems"},{"line_number":1261,"context_line":"        manager_utils.node_set_boot_device(task, device, persistent)"},{"line_number":1262,"context_line":""},{"line_number":1263,"context_line":"    @classmethod"},{"line_number":1264,"context_line":"    def _set_boot_device(cls, task, device, persistent\u003dFalse):"}],"source_content_type":"text/x-python","patch_set":18,"id":"7adf510b_6b5ec3b6","line":1261,"in_reply_to":"14682688_af3093b7","updated":"2026-06-26 08:00:56.000000000","message":"Done","commit_id":"34755bd1a651698376a6f62a76eb76bdfd2aedd3"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"a46d445e53261aa3bcc0a251a263932212d279fe","unresolved":true,"context_lines":[{"line_number":1258,"context_line":"                return"},{"line_number":1259,"context_line":""},{"line_number":1260,"context_line":"        # Set the requested boot device for all other systems"},{"line_number":1261,"context_line":"        manager_utils.node_set_boot_device(task, device, persistent)"},{"line_number":1262,"context_line":""},{"line_number":1263,"context_line":"    @classmethod"},{"line_number":1264,"context_line":"    def _set_boot_device(cls, task, device, persistent\u003dFalse):"}],"source_content_type":"text/x-python","patch_set":18,"id":"14682688_af3093b7","line":1261,"in_reply_to":"f91852d0_06cac181","updated":"2026-06-25 16:22:45.000000000","message":"Something like this:\ncls._set_boot_device(task, device, persistent)","commit_id":"34755bd1a651698376a6f62a76eb76bdfd2aedd3"},{"author":{"_account_id":15519,"name":"Iury Gregory Melo Ferreira","display_name":"Iury Gregory","email":"iurygregory@gmail.com","username":"iurygregory"},"change_message_id":"1e565d738d29f3d96fc2fa6d50f71ef467a22f42","unresolved":true,"context_lines":[{"line_number":1499,"context_line":"        boot_option \u003d deploy_utils.get_boot_option(node)"},{"line_number":1500,"context_line":"        iwdi \u003d node.driver_internal_info.get(\u0027is_whole_disk_image\u0027)"},{"line_number":1501,"context_line":"        if boot_option \u003d\u003d \"local\" or iwdi:"},{"line_number":1502,"context_line":"            RedfishVirtualMediaBoot._apply_boot_device("},{"line_number":1503,"context_line":"                task, boot_devices.DISK, persistent\u003dTrue)"},{"line_number":1504,"context_line":""},{"line_number":1505,"context_line":"            LOG.debug(\"Node %(node)s set to boot from local %(device)s\","}],"source_content_type":"text/x-python","patch_set":18,"id":"a93b3a0f_3be2362a","line":1502,"updated":"2026-06-25 03:59:39.000000000","message":"Just wondering, but any reason why on L1116/L1133 you call `self._apply_boot_device` and here you call via the class ? (same on L1519)","commit_id":"34755bd1a651698376a6f62a76eb76bdfd2aedd3"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"03a2a3779bf45988fe60a9350b515fc6f9553ce9","unresolved":true,"context_lines":[{"line_number":1499,"context_line":"        boot_option \u003d deploy_utils.get_boot_option(node)"},{"line_number":1500,"context_line":"        iwdi \u003d node.driver_internal_info.get(\u0027is_whole_disk_image\u0027)"},{"line_number":1501,"context_line":"        if boot_option \u003d\u003d \"local\" or iwdi:"},{"line_number":1502,"context_line":"            RedfishVirtualMediaBoot._apply_boot_device("},{"line_number":1503,"context_line":"                task, boot_devices.DISK, persistent\u003dTrue)"},{"line_number":1504,"context_line":""},{"line_number":1505,"context_line":"            LOG.debug(\"Node %(node)s set to boot from local %(device)s\","}],"source_content_type":"text/x-python","patch_set":18,"id":"237e48b7_e4622077","line":1502,"in_reply_to":"a93b3a0f_3be2362a","updated":"2026-06-25 11:55:57.000000000","message":"The inconsistency is because RedfishHttpsBoot inherits from\n  base.BootInterface (not RedfishVirtualMediaBoot), so it doesn\u0027t have\n  _apply_boot_device as an instance method.\n\n  Currently _apply_boot_device is a @classmethod in RedfishVirtualMediaBoot,\n  which is why RedfishHttpsBoot explicitly calls it via the class name.\n\n  I see two options for consistency:\n  1. Move _apply_boot_device to a module-level function (since both classes\n     need it and it doesn\u0027t use any instance/class-specific data)\n  2. Use RedfishVirtualMediaBoot._apply_boot_device() explicitly in all\n     4 locations for clarity","commit_id":"34755bd1a651698376a6f62a76eb76bdfd2aedd3"}],"ironic/drivers/modules/redfish/management.py":[{"author":{"_account_id":10239,"name":"Dmitry Tantsur","email":"dtantsur@protonmail.com","username":"dtantsur"},"change_message_id":"f7a6a1ed9387284a1b8b2e9d7e5eec0505822a5b","unresolved":true,"context_lines":[{"line_number":245,"context_line":"        _do_set_boot_options()"},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"        # Clear boot override for vendors that require it to avoid boot loops"},{"line_number":248,"context_line":"        # (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":249,"context_line":"        requires_boot_override_clear \u003d ("},{"line_number":250,"context_line":"            vendor and any(vendor_id in vendor.lower()"},{"line_number":251,"context_line":"                           for vendor_id in"}],"source_content_type":"text/x-python","patch_set":1,"id":"8e9c3728_127f6dab","line":248,"updated":"2026-04-29 09:29:13.000000000","message":"Could you file an upstream bug on launchpad so that we don\u0027t have to link to RH jira?","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"ea220a7485462b4a9c2df43df91b61542a907d9a","unresolved":false,"context_lines":[{"line_number":245,"context_line":"        _do_set_boot_options()"},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"        # Clear boot override for vendors that require it to avoid boot loops"},{"line_number":248,"context_line":"        # (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":249,"context_line":"        requires_boot_override_clear \u003d ("},{"line_number":250,"context_line":"            vendor and any(vendor_id in vendor.lower()"},{"line_number":251,"context_line":"                           for vendor_id in"}],"source_content_type":"text/x-python","patch_set":1,"id":"7e85df86_8b121f7a","line":248,"in_reply_to":"8e9c3728_127f6dab","updated":"2026-04-29 11:21:42.000000000","message":"Done","commit_id":"156f05b0dc63bb6638d2efb5edf04aa106117466"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"4290008113e841b2b601f2b2924f1e90c7fb0e84","unresolved":true,"context_lines":[{"line_number":105,"context_line":"# (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":106,"context_line":"VENDORS_REQUIRING_BOOT_OVERRIDE_CLEAR \u003d ["},{"line_number":107,"context_line":"    \"lenovo\""},{"line_number":108,"context_line":"]"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"INDICATOR_MAP \u003d {"},{"line_number":111,"context_line":"    sushy.INDICATOR_LED_LIT: indicator_states.ON,"}],"source_content_type":"text/x-python","patch_set":3,"id":"6c2e0902_2cfe319c","line":108,"updated":"2026-05-11 19:35:57.000000000","message":"So the commit message, and the release note, mention a specific Lenovo model. This is going to apply to all Lenovos. How confident are we that this is the correct behavior?","commit_id":"e0b77c4cdb1076f5b5ac8153031eb6a4fa08548a"},{"author":{"_account_id":33663,"name":"Jad Haj Yahya","email":"jhajyahy@redhat.com","username":"jadh"},"change_message_id":"40ff90841ffc811e0d4b00bd22c5e8b89d54fa75","unresolved":true,"context_lines":[{"line_number":105,"context_line":"# (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":106,"context_line":"VENDORS_REQUIRING_BOOT_OVERRIDE_CLEAR \u003d ["},{"line_number":107,"context_line":"    \"lenovo\""},{"line_number":108,"context_line":"]"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"INDICATOR_MAP \u003d {"},{"line_number":111,"context_line":"    sushy.INDICATOR_LED_LIT: indicator_states.ON,"}],"source_content_type":"text/x-python","patch_set":3,"id":"e4c62aae_c7e1c19c","line":108,"in_reply_to":"5088f2fb_32e94542","updated":"2026-05-12 15:24:29.000000000","message":"we are not sure actually. The specific Lenovo model is based on customer that reported the issue. @juliaashleykreger@gmail.com already asked input regrading it:\nhttps://bugs.launchpad.net/ironic/+bug/2150628/comments/1","commit_id":"e0b77c4cdb1076f5b5ac8153031eb6a4fa08548a"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"b6166f4df2f2754c953bb4e61e3a656a7df0d63b","unresolved":true,"context_lines":[{"line_number":105,"context_line":"# (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":106,"context_line":"VENDORS_REQUIRING_BOOT_OVERRIDE_CLEAR \u003d ["},{"line_number":107,"context_line":"    \"lenovo\""},{"line_number":108,"context_line":"]"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"INDICATOR_MAP \u003d {"},{"line_number":111,"context_line":"    sushy.INDICATOR_LED_LIT: indicator_states.ON,"}],"source_content_type":"text/x-python","patch_set":3,"id":"e3b8382c_c99c1dc4","line":108,"in_reply_to":"6c2e0902_2cfe319c","updated":"2026-05-13 14:08:37.000000000","message":"Historically, we\u0027ve seen different model focused behavior, and we had accounted for that. Ultimately, as a maintainer, I just have insufficient information to review the issue and ultimately even wearing a downstream hat I\u0027m being shared links I cannot access with folks really just not providing clarity either.\n\nAlthough, perhaps we need to take a step back. The contributor is saying that the system is hitting the *first* entry in the default table and failing to secure boot. Has the nvram table contents been captured anywhere?\n\nI\u0027m specifically asking because it might actually be a bug in the firmware because the intent of the defualt path is to find the issue, if its not immediately a loader then in this case it is failing to boot because it is hyper focused on the entry, when really it needs to be the shim. But we\u0027re left with no control over that with with the way RHCOS gets installed. We can\u0027t do the record dance we\u0027ve got in code since this is not IPA.\n\nI guess, we previously saw boot issues on the SR650s, v1 through v3. That is causing me to wonder if its the entire lenovo suite of hardware which is becoming more... ?persnickety?.\n\nA hidden detail in this is in the SR650 issues, we had to update nvram entries in a very particular order which we were able to verify did not upset the nvram nor blue screen the machine.\n\nIn this case, deploying coreos, its doing it\u0027s own thing driver wise, there really is not an agent the same way, the sequence runs, it reboots....","commit_id":"e0b77c4cdb1076f5b5ac8153031eb6a4fa08548a"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"a9ef4a10ea32bfc565f1f5cf60673097e1566c57","unresolved":true,"context_lines":[{"line_number":105,"context_line":"# (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":106,"context_line":"VENDORS_REQUIRING_BOOT_OVERRIDE_CLEAR \u003d ["},{"line_number":107,"context_line":"    \"lenovo\""},{"line_number":108,"context_line":"]"},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"INDICATOR_MAP \u003d {"},{"line_number":111,"context_line":"    sushy.INDICATOR_LED_LIT: indicator_states.ON,"}],"source_content_type":"text/x-python","patch_set":3,"id":"5088f2fb_32e94542","line":108,"in_reply_to":"6c2e0902_2cfe319c","updated":"2026-05-12 14:37:06.000000000","message":"Please fix.","commit_id":"e0b77c4cdb1076f5b5ac8153031eb6a4fa08548a"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"b6166f4df2f2754c953bb4e61e3a656a7df0d63b","unresolved":true,"context_lines":[{"line_number":166,"context_line":"    Vendor-specific logic:"},{"line_number":167,"context_line":"    - Vendors listed in VENDORS_REQUIRING_FULL_BOOT_REQUEST:"},{"line_number":168,"context_line":"      Require setting full boot parameters"},{"line_number":169,"context_line":"      (mode, enabled, target) even if unchanged."},{"line_number":170,"context_line":"    \"\"\""},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"    # The BMC handling of the persistent setting is vendor specific."}],"source_content_type":"text/x-python","patch_set":5,"id":"15db1cda_0c907d0e","line":169,"updated":"2026-05-13 14:08:37.000000000","message":"Please add an entry here for vendor specific logic.","commit_id":"6df8263dc5e4e82efad649bfc2a9f021a42094fc"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"b6166f4df2f2754c953bb4e61e3a656a7df0d63b","unresolved":true,"context_lines":[{"line_number":217,"context_line":"        reraise\u003dTrue)"},{"line_number":218,"context_line":"    def _do_set_boot_options():"},{"line_number":219,"context_line":"        # NOTE(TheJulia): In sushy, it is uri, due to the convention used"},{"line_number":220,"context_line":"        # in the standard. URL is used internally in ironic."},{"line_number":221,"context_line":"        if requires_full_boot_request:"},{"line_number":222,"context_line":"            # Some vendors require sending all boot parameters every time"},{"line_number":223,"context_line":"            desired_mode \u003d system.boot.get(\u0027mode\u0027) \\"}],"source_content_type":"text/x-python","patch_set":5,"id":"20f7a7ac_107411d4","line":220,"updated":"2026-05-13 14:08:37.000000000","message":"Would it not be safer, given we know lenovo hardware can be somewhat strict around NVRAM/setting changes, to just build logic up here to make the determination of enabled and target. Well to be more precise make the determination upfront.","commit_id":"6df8263dc5e4e82efad649bfc2a9f021a42094fc"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"b6166f4df2f2754c953bb4e61e3a656a7df0d63b","unresolved":true,"context_lines":[{"line_number":245,"context_line":"        _do_set_boot_options()"},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"        # Clear boot override for vendors that require it to avoid boot loops"},{"line_number":248,"context_line":"        # (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":249,"context_line":"        requires_boot_override_clear \u003d ("},{"line_number":250,"context_line":"            vendor and any(vendor_id in vendor.lower()"},{"line_number":251,"context_line":"                           for vendor_id in"}],"source_content_type":"text/x-python","patch_set":5,"id":"51c3f4c8_c149e75b","line":248,"range":{"start_line":248,"start_character":14,"end_line":248,"end_character":62},"updated":"2026-05-13 14:08:37.000000000","message":"First off, this needs to be an upstream/community bug tracker or include a link to the upstream tracker where the item is tracked.\n\nThis is especially prudent since Red Hat recently left using a self hosted instance of Jira and the issues.redhat.com redirect is not expected to be online indefinitely.","commit_id":"6df8263dc5e4e82efad649bfc2a9f021a42094fc"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"b6166f4df2f2754c953bb4e61e3a656a7df0d63b","unresolved":true,"context_lines":[{"line_number":246,"context_line":""},{"line_number":247,"context_line":"        # Clear boot override for vendors that require it to avoid boot loops"},{"line_number":248,"context_line":"        # (see https://issues.redhat.com/browse/OCPBUGS-84552)"},{"line_number":249,"context_line":"        requires_boot_override_clear \u003d ("},{"line_number":250,"context_line":"            vendor and any(vendor_id in vendor.lower()"},{"line_number":251,"context_line":"                           for vendor_id in"},{"line_number":252,"context_line":"                           VENDORS_REQUIRING_BOOT_OVERRIDE_CLEAR)"},{"line_number":253,"context_line":"        )"},{"line_number":254,"context_line":"        if (requires_boot_override_clear"},{"line_number":255,"context_line":"            and device \u003d\u003d sushy.BOOT_SOURCE_TARGET_HDD):"}],"source_content_type":"text/x-python","patch_set":5,"id":"2a4337f9_01f8516d","line":252,"range":{"start_line":249,"start_character":6,"end_line":252,"end_character":65},"updated":"2026-05-13 14:08:37.000000000","message":"This should be updated to ensure that the node is in UEFI mode. Otherwsie hdd is the \"proper\" action as signaled from the BMC.\n\nGiven UEFI mode, the record set prior to reboot should take effect if cleared.","commit_id":"6df8263dc5e4e82efad649bfc2a9f021a42094fc"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"b6166f4df2f2754c953bb4e61e3a656a7df0d63b","unresolved":true,"context_lines":[{"line_number":257,"context_line":"                      \u0027setting disk boot device for node %(node)s to avoid \u0027"},{"line_number":258,"context_line":"                      \u0027boot loop\u0027,"},{"line_number":259,"context_line":"                      {\u0027vendor\u0027: vendor, \u0027node\u0027: task.node.uuid})"},{"line_number":260,"context_line":"            system.set_system_boot_options("},{"line_number":261,"context_line":"                enabled\u003dsushy.BOOT_SOURCE_ENABLED_DISABLED,"},{"line_number":262,"context_line":"                target\u003dsushy.BOOT_SOURCE_TARGET_NONE)"},{"line_number":263,"context_line":""}],"source_content_type":"text/x-python","patch_set":5,"id":"5023fa5c_343aded7","line":260,"updated":"2026-05-13 14:08:37.000000000","message":"Note: Interestingly enough, this is after the main action. Technically this might create the other issue we\u0027ve encountered in the past with two record changes. That being said their hosts have generally been forgiving when records/settings were removed more than added.\n\nPreviously this lenovo issue was handled here: https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/agent.py#L236-L250\n\nBut what I think is happening is the agent gets invoked with a singular step in the RHOCP case where we never actually call the agent to configure bootloaders or set the node to boot. Lets call this step \"install_openshift\". The step runs, triggers a reboot. Ironic thinks it is done, the guarding logic elsewhere in the default deploy path doesn\u0027t execute, and the operator reproduces the same exact bug we\u0027ve seen previously with inband actions.\n\nSo to translate, if the overall check logic becomes guarded by UEFI, then the overall impact is the same. We explicitly unset an override being set earlier on.\n\nExcept, I think the issue here is that this can also break the ability to deploy the node since this change is being done in management.py in the general handler for redfish system management.\n\nSo, say we tell the machine \"your going to HTTPBoot\" or \"your going to pxe boot\", or even \"your going to vmedia boot\", and then immediately turn around and unwind the override setting *and* the target.\n\nIn other words, I think we\u0027re heading down a path which breaks lenovo hardware completely. I think the right path is to be aware of where we are in the code path, which maybe means the overall management method needs a \"please set node for final deployment\", but we should be making the base determination as high up as possible in the flow. Ultimately, if the install model of OCP is what what I\u0027m remembering and we\u0027re executing a single step, we might be better served by explicitly injecting the second step where we skip applying settings. \n\nAlternatively that code is right, but it is not being invoked with UEFI set.","commit_id":"6df8263dc5e4e82efad649bfc2a9f021a42094fc"}]}