Activity for rEFInd
-
Alexei S. posted a comment on discussion General Discussion
Not sure if this is something that's supposed to work or not. I have a MacPro 1,1 and I wanted to use refind to boot from Win10 installer USB stick that I made on a PC with Microsoft tool for that. I used ExtFat. Refind does show the USB stick as legacy OS, but after selecting it, gives a Not found error.
-
dakanji posted a comment on discussion General Discussion
Thanks. Will get round to building one with an attempted fix presently. Will ping you when ready as might take some time.
-
Scott Ellis posted a comment on discussion General Discussion
I get "IO Error" with the rEFInd 0.14.2 ext4 driver trying to cp a kernel (same ones that were our btrfs test case) from ext4. For sanity, copying one from btrfs to the same partition succeeds (so it's not a destination partition error).
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Thanks ... Use the current driver from rEFInd as baseline if/when you are able.
-
I do not - only FAT32 and BTRFS here. If I get some cycles I'll try making an Ext4 partition and see if I can recreate the problem. Using the driver from the latest RefindPlus release should show the symptom?
-
@scotteai ... You wouldn't happen to have an Ext4 implementation with the problem kernel version(s) sitting around, would you? Basically tried to migrate the fix across from BtrFS but given the differences between the two fs types, it would be nice to confirm it works.
-
@scotteai ... You wouldn't happen to have an Ext4 implementation with the problem kernel version(s) sitting around, would you? Basically tried to migrate the fix across from BtrFS but how the given the differences between the two fs types, it would be nice to confirm it works.
-
Brilliant ... Let's take the win. The log output was useful. While there were some other items found and handled along the way, the issue was ultimately that the driver could not handle holes in the file. I note that the commit to the kernel identified seemed to be one where some section was added to the build and was marked to be stripped out later. Perhaps this introduced a hole. Likely affects the other FS drivers. Will clean up and roll into RefindPlus later. Can then see about backporting to...
-
The bad news is that I can't get a screenshot of errors from 5B-2. The good news is that I can't get a screenshot because it actually loads the kernel properly (which then clears the UEFI console). :-) Attached is the tail of the cp fs2:\boot\vmlinuz fs0:\ output. Likely not interesting.
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to our...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
The 5A run "fails different" to an extent. Please give the attached a go.
-
The 5A run "fails different" to an extent. Please give the attached a go.
-
I did a quick test of installing a kernel into /boot (BTRFS) with compress=zstd (what I normally use) vs compress=none (via remaount before cp'ing over the new kernel image) and the same kernel errors out the same way with 5A. I'm not savvy enough to know how to check that there are legitimately no extents compressed in the file, but if I trust that the filesystem is doing the right thing with the mount options then indeed zstd seems not the culprit.
-
The console buffer filled up quickly, so here's the last part of the 5A log. All the earlier parts are similar (only the "failure" at the end is interesting :-) ). Nonetheless, still failed. :-(
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Only one is relevant to this...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Needs looking into whether porting...
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Needs looking into whether porting...
-
Sorry, bit of an oversight in the previous. Please run the [REMOVED] instead.
-
Sure this doesn't feel like zstd failing to uncompress a chunk? There might be a ZSTD angle to things but it is likely to just be incidental. Have looked further into this angle and it almost definitely not a ZSTD version issue as it turns out GRUB is still on ZSTD 1.3.6. The code was ported to rEFInd shortly after it was added back in 2018. Two small patches, in 2020 and 2021, have been added since: https://github.com/rhboot/grub2/commits/fedora-44/grub-core/lib/zstd Needs looking into whether porting...
-
More FSW_VOLUME_CORRUPTED debug. For fun, I tried a cp vmlinuz fs0:\ and obviously it errors out too (vs trying to exec the kernel). Sharing a screenshot of that as well just for fun, failing on the same extent as trying to load the kernel does. You sure this doesn't feel like zstd failing to uncompress a chunk?
-
@scotteai ... Please run the [REMOVED]. Logs a bit more info around the failure point
-
Sorry, bit of an oversight in the previous. Please run the attached instead.
-
Screenshots showing messages for "Not Found" with two separate kernel load attempts (same btrfs FS).
-
smells like outdated zstd Not clear cut. A decompression error does return EFI_VOLUME_CORRUPTED (Line 1711 to 1720): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1711-L1720 or here, where it will ultimately be EFI_DEVICE_ERROR as is negative (Line 1771 to 1783): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1771-L1783 However, this particular failure is earlier (Line...
-
smells like outdated zstd Not clear cut. A decompression error does return EFI_VOLUME_CORRUPTED (Line 1711 to 1720): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1711-L1720 or here, where it will end as EFI_DEVICE_ERROR being negative (Line 1771 to 1783): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1771-L1783 However, this particular failure is earlier (Line 1678...
-
smells like outdated zstd Not clear cut. A decompression error does return EFI_VOLUME_CORRUPTED (Line 1711 to 1720): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1711-L1720 However, this particular failure happens beforehand (Line 1678 to 1681): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1678-L1681 Interestingly, the vol->extend <= pos check passed earlier in the...
-
smells like outdated zstd Not clear cut. A decompression error does return EFI_VOLUME_CORRUPTED (Line 1711 to 1720): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1711-L1720 However, this failure is beforehand (Line 1678 to 1681): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1678-L1681 Interestingly, the vol->extend <= pos check passed earlier in the function: https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1631-L1633...
-
smells like outdated zstd Not clear cut. A decompression error does return EFI_VOLUME_CORRUPTED(Line 1711 to 1720): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1711-L1720 However, this failure is beforehand (Line 1678 to 1681): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1678-L1681 Interestingly, the vol->extend <= pos check passed earlier in the function: https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1631-L1633...
-
smells like outdated zstd Not clear cut. A decompression Error does return EFI_VOLUME_CORRUPTED(Line 1711 to 1720): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1711-L1720 However, this failure is beforehand (Line 1678 to 1681): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1678-L1681 Interestingly, the vol->extend <= pos check passed earlier in the function: https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1631-L1633...
-
@scotteai ... Please run the attached. Logs a bit more info around the failure point
-
@scotteai ... Please try the [REMOVED]. Attempts to locate the failure point.
-
@scotteai ... Please run the attached. Logs a bit more info around the failure point
-
corrupted extent smells like outdated zstd Not clear cut. A decompression Error does return EFI_VOLUME_CORRUPTED(Line 1711 to 1720): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1711-L1720 However, this failure is beforehand (Line 1678 to 1681): https://github.com/RefindPlusRepo/rEFInd/blob/253abe5c4af58d044912517daa567c4440612c46/filesystems/fsw_btrfs.c#L1678-L1681 Interestingly, the vol->extend <= pos check passed earlier in the...
-
Well, with 4A, the corrupted extent sure smells like outdated zstd.
-
@scotteai ... Could well be. Let's see what the [REMOVED] gives
-
@scotteai ... Please try the attached. Attempts to locate the failure point.
-
Yes, the "Buffer Too Small" is misdirection here. I had intended to only remove one item that was being logged a lot but then decided to also tag some misc places where things where exiting on error. I didn't tag exit on success points for these. In these cases, the buffer is likely being tried in a loop with additional spaces added if found to be too small. It would ultimately hit success but this was not logged as mentioned ... to reduce the noise in the log. Potential failures are what was needed....
-
Yes, the "Buffer Too Small" is misdirection here. I had intended to only remove one item that was being logged a lot but then decided to also tag some misc places where things where exiting on error. I didn't tag exit on success points for these. In these cases, the buffer is likely being tried in a loop with additional spaces added if found to be too small. It would ultimately hit success but this was not logged as mentioned ... to reduce the noise in the log. Potential failures are what was needed....
-
Yes, the "Buffer Too Small" is misdirection here. I had intended to only remove one item that was being logged a lot but then decided to also tag some misc places where things where exiting on error. I didn't tag exit on success points for these. In these cases, the buffer is likely being tried in a loop with additional spaces added if found to be too small. It would ultimately hit success but this was not logged as mentioned ... to reduce the noise in the log. Potential failures are what was needed....
-
Attached. Same result as in 3A and earlier ("Not found"). I see "Buffer too small", but feel like that's a red herring since it also happens when just tab-completing the filename in the shell.
-
@scotteai ... Could well be. Let's see what the attached gives
-
I assume the yellow parts are the shell trying to figure out what to display for the path, etc.? Like, doing some FS lookup since the prompt is the working directory. That was my guess anyway for why there's post "Not Found" debug.
-
Sorry. Perhaps I got something mixed up there. You can try the [REMOVED].
-
Thanks. It seems to have been able to read the file block, load the file and returned EFI_SUCCESS. However, given that some things still run AFTER the Host Env appears to have given up on the kernel load attempt, see yellow bit in attached, it could well be that these final outputs are from these. Thanks again for all the tests. Will look into a version that reduces the output shown.
-
Thanks. It seems to have been able to read the file block, load the file and returned EFI_SUCCESS. But, given that some things still run AFTER the Host Env appears to have given up on the kernel load attempt, see yellow bit in attached, it could well be that these final outputs are from these. Thanks again for all the tests. Will look into a version that reduces the output shown.
-
Thanks. It seems to have been able to read the file block, load the file and returned EFI_SUCCESS. But, given that some things still run AFTER the Host Env has thrown in the towel on the kernel load attempt, see yellow bit in attached, it could well be that these outputs are from these. Thanks again for all the tests.
-
Using 3B I get the same behavior (can navigate around, can't launch a kernel). There's a lot of Success messages, so the UEFI console buffer filled up - the only interesting thing I could see was the attached at the end of that buffer.
-
Thanks. Seems the area looked at over last few is fine. The duplicated call is also fine and how it should be. Focus now moves to considering another area as it now seems clear that the 4x loop is tied to the external caller. Hypothesis is that it is somehow receiving a non-fatal error considered retry-able. It then retries up to a limit of 3 retries. Need to look at what is being passed back. Figuring why it gets such (if correct) and how to fix this will come later. The [REMOVED] is mainly looking...
-
Sorry. Perhaps I got something mixed up there. You can try the attached.
-
Sorry. Perhaps I got something mixed up there. You can try the attached.
-
Sorry @dakanji , was travelling last week so didn't get time to test. Using 3A doesn't even detect the filesystem (see attached).
-
@eugene_shalygin ... An impact on Ext4 does suggest it is something else. rEFInd can decompress gzipped kernels via support_gzipped_loaders but apparently, the setting should not be needed on x64. There is no support_zstded_loaders setting. It could also be that there is a combination of the issues. This would explain the contradictory experiences. Throwing the towel in on this for now. Would still try the ZSTD lib update at some point ... for the fun of it. Good luck!
-
@eugene_shalygin ... An impact on Ext4 does suggest it is something else. rEFInd can decompress gzipped kernels via support_gzipped_loaders but apparently, the setting should not be needed on x64. There is no support_zstded_loaders setting. It could also be that there is a combination of the issues. This would explain the contradictory experiences. Throw the towel in on this for now. Would still try the ZSTD lib update at some point ... for the fun of it. Good luck!
-
@eugene_shalygin ... An impact on Ext4 does suggest it is something else. rEFInd can decompress gzipped kernels via support_gzipped_loaders but the apparently, setting should not be needed on x64. It could also be that there is a combination of the issues. This would explain the contradictory experiences. Throw the towel in on this for now. Would still try the ZSTD lib update at some point ... for the fun of it. Good luck!
-
Eugene Shalygin posted a comment on discussion General Discussion
But the BTRFS filesystem uses compression itself, with one of the methods can be Zstd, and then rEFInd needs to use the zstd library to read file contents from the filesystem. In case of ext4, there is no compression on the filesystem level, rEFInd does not need to decompress the kernel file. That's why I believe the explanation, given by @dakanji above, can't apply to my case.
-
I have the same btrfs behavior with none, gzip, or zstd kernel compression. Also the same zstd kernel loads fine from the ESP for me.
-
Err... There is no ZSTD compression in ext4, AFAIK. It's the compression of the kernel image. Notice, the kernel image can be launched from the EFI shell, but rEFInd fails.
-
The zstd thing also makes sense why it'd work on one of my BTRFS filesystems (the "working" FS and kernel load was written before I enabled zstd on there) but not the other, and why my build of btrfs-efi works (I used the current zstd sources).
-
@eugene_shalygin ... Yes, this confirms: https://bugzilla.kernel.org/show_bug.cgi?id=220700#c4. ZSTD likely needs updating (assuming there isn't a bug present). Workaround is to use another compression lib for now. EDIT: Appears related: https://bugzilla.kernel.org/show_bug.cgi?id=220731
-
@eugene_shalygin ... Yes, this confirms: https://bugzilla.kernel.org/show_bug.cgi?id=220700#c4. ZSTD likely needs updating (assuming there isn't a bug present). Workaround is to use another compression lib for now.
-
I've got a similar problem with ext4, ZSTD, and Gentoo (https://bugzilla.kernel.org/show_bug.cgi?id=220700).
-
Seems @scotteai has checked out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items (at least FSW_BTRFS) apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code in the driver, despite the lower order items, at least FSW_BTRFS, apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code despite the lower order items, at least FSW_BTRFS, apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from the FSW_EFI code despite the lower order FSW items apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR from FSW_EFI despite the lower order FSW items apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure on those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while definitive confirmation is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure for those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary...
-
Seems @scotteai has bailed out but while confimration is not available, it appears almost certain the Host Environment is getting a status such as DEVICE_ERROR despite the lower order items of the FSW setup apparently working as they should. That is, there is a failure when trying to actually read/load the kernel, which I believe is likely down to a decompression failure for those specific Gentoo builds. I believe the Host Environment treats this status as potentially being a temporary glitch and...
-
Thanks. Seems the area looked at over last few is fine. The duplicated call is also fine and how it should be. Focus now moves to considering another area as it now seems clear that the 4x loop is tied to the external caller. Hypothesis is that it is somehow receiving a non-fatal error considered retry-able. It then retries up to a limit of 3 retries. Need to look at what is being passed back. Figuring why it gets such (if correct) and how to fix this will come later. The attached is mainly looking...
-
Thanks. Possible to log to file in theory and had actually started towards that before realising the potential problems. Log files introduce issues and have shortcomings in certain setups such as this. While can be ignored, they need housekeeping elements like rotation and other considerations. In this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if you had just been passing a log file, the Command Error Status notice would...
-
Thanks. Seems the area looked at over last few is fine. The duplicated call is also fine and how it should be. The attached moves to considering another area as it now seems clear that the 4x loop is tied to the external caller. Hypothesis is that it is somehow receiving a non-fatal error considered retry-able. It then retries up to a limit of 3 retries. Need to look at what is being passed back. Figuring why it gets such (if correct) and how to fix this will come later. The attached is mainly looking...
-
I wasn't meaning a "real" log file, just a way to more thoroughly capture debug output being sent to the console currently...but I get it. :-) Attached are screenshots from trying to load the kernel using the 2B driver above.
-
Thanks. Possible to log to file in theory and had actually started towards that before realising the potential problems. Log files introduce issues and have shortcomings in certain setups such as this. While can be ignored, they need housekeeping elements like rotation and other considerations. In this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if you had just been passing a log file, the Command Error Status notice would...
-
Thanks. Possible to log to file in theory and had actually started towards that before realising the potential problems. Log files introduce issues and have shortcomings in certain setups such as this. While can be ignored, they need housekeeping elements like rotation and other considerations. Additionally, in this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if just passing a log file, the Command Error Status notice would...
-
@scotteai ... Out of curiosity, is the path to vmlinuz a symlink? There is a clear pattern of 4 tries, then abort: vmlinuz-6.17.8-scotte-lt-nvidia-meteor // LOOP 1 FSW_BTRFS_C: btrfs_lookupdir_item ... Found Entry FSW_BTRFS_C: btrfs_lookupdir_item ... Leaving with Status: FSW_SUCCESS FSW_BTRFS_C: btrfs_lookupdir_item ... Found Entry FSW_BTRFS_C: btrfs_lookupdir_item ... Leaving with Status: FSW_SUCCESS FSW_CORE_C: fsw_dnode_lookup_path ... Leaving with Status: FSW_SUCCESS // LOOP 2 FSW_BTRFS_C: btrfs_lookupdir_item...
-
Thanks. Possible to log to file in theory and had actually started towards that before realising the potential problems. Log files introduce issues and have shortcomings in certain setups such as this. While can be ignored, they need housekeeping elements like rotation and other considerations. Additionally, in this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if just passing a log file, the Command Error Status notice would...
-
Thanks. Possible to log to file in theory and had actually started towards that before realising the potential problems. Log files introduce issues and have shortcomings in certain setups such as this. While can be ignored, they need housekeeping elements like rotation and other considerations. Additionally, in this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if you had just been passing a log file, the Command Error Status...
-
I had never actually really looked into how the FS drivers worked in detail until these last few days. So, just been learning about it. One note from the previous is that btrfs_lookup_dir_item is called twice in each loop and this is not expected. Tracing why this happens might be helpful. Please try the [REMOVED], which just has some extra debug print points added to the previous (no change in outcome expected) and share the image of the part around the vmlinuz call.
-
Thanks. Possible to log to file in theory and had actually started towards that before realising the potential problems. Log files introduce issues and have shortcomings in certain setups such as this. While can be ignored, they need housekeeping elements like rotation and other considerations. In this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if you had just been passing a log file, the Command Error Status notice would...
-
Thanks. Possible to log to file in theory and had actually started towards that before coming to my senses. Log files introduce issues and have shortcomings in certain setups. While can be ignored, they need housekeeping elements like rotation and other considerations. In this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if you had just been passing a log file, the Command Error Status notice would have not been picked up ......
-
Thanks. Possible to log to file in theory and had actually started towards that before coming to my senses. Log files introduce issues and have shortcomings in certain setups. While can be ignored, they need housekeeping elements like rotation and other considerations. In this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if you had just been passing a log file, the Command Error Status notice would have not been picked up ......
-
Thanks. Possible to log to file in theory and had actually started towards that before coming to my senses. Log files introduce issues and have shortcomings in certain setups. While can be ignored, they need housekeeping elements like rotation and other considerations. In this specific case, there are other elements that need to be seen that would not be captured by the log file. For instance, if you had just passing a log file, the Command Error Status notice would have not been picked up ... being...
-
Screenshots attached with the 2A attempting to load a kernel. FWIW, I tried this on FS1 (another btrfs filesystem that's the root of an Ubuntu install) and it was able to load a kernel on there find. Unfortunately it loads and gets to the kernel messages before I can grab any UEFI output. :-( Is there a way for FS drivers to write to a file (like it could log to a file in the ESP root or something)?
-
Please rinse and repeat with the [REMOVED]. Issue being seen is that it gets stuck on SelfVol ( . ) at some point and gives up after the 3rd retry, 4th successive hit. Made some adjustments accordingly.
1 >
