-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ubuntu ISO with >4GB casper file freezes on boot through UEFI:NTFS when Secure Boot is active #2210
Comments
As referenced above, I also reported this issue in rhboot/shim#558 as there is circumstantial evidence of a possible Linux shim regression... |
Opened pbatard/ntfs-3g#4 to fix the underlying issue. |
While we were at it, we also submitted a PR to improve the Shim code (that currently just bails out on non-compliance, but could try to allocate buffers with increased size, thus ensuring that the directory listing succeeds regardless). |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
This is basically an investigation of the issue that reported on askubuntu.com and that I have also been able to replicate on another system.
To cut a long story short:
ubuntustudio-22.04.2-dvd-amd64.iso
) now uses a casper file (casper/filesystem.squashfs
) that is larger than 4 GB.most likely in mmx64.efi but needs to be validated) and you never get to the GRUB menu.Error: file /boot/ not found!
message, that doesn't seem to have much of an impact).So we have an incompatibility somewhere between the UEFI:NTFS bootloader or the UEFI:NTFS ntfs-3g read-only driver and one of shim/mokmanager/GRUB, with the current most likely suspect being
mokmanager (which doesn't seem to be invoked when Secure Boot is disabled)shim (WTF?!?) possiblyneeding/expecting r/w access to the ESPwith one of the code changes introduced in https://github.com/rhboot/shim/commits/main between 2021.07 and 2023.01.18.Unfortunately, and unlike what UEFI:NTFS does with is very detailed and verbose output, the Red Hat/GRUB/Ubuntu folks borrowed the most patronizing page from Microsoft's rulebook that says "you should hide scary boot details from the user and give them a nice empty screen since it'll looks pretty" and ran with it, with the result that they chose not to provide a single point of information about what's currently happening that could give us any clue as to where their process chokes.
Which means that we now have to find a needle in the blind haystack of shim + mokmanager + GRUB to try to figure out what is really happening.
Things we tested:
ubuntu-22.10-desktop-amd64.iso
(with casper < 4 GB) written in UEFI:NTFS mode boots fine under the same conditionsubuntu-22.04.2-desktop-amd64.iso
(with casper < 4 GB) written in UEFI:NTFS mode has the same issuebootx64.efi
,mmx64.efi
andgrubx64.efi
are different, so it's possible that this is a known Shim/MOK Manager/GRUB issue that has been fixed in the most up to date versions, and that will be picked by LTS eventually.grubx64.efi
andmmx64.efi
→ Still froze, which seems to indicate that the issue is with the shim (unless shim is designed to halt if it can't find MM/GRUB).Wednesday 18 January 2023 02:37:51
whereas the Shim that does work (933 KB) was signedThursday 12 August 2021 22:00:22
, which would tend to hint that it's the newer shims that introduced breakage and that future versions of Ubuntu will all have the issue. WTF did Red Hat do to break boot?!?ntsf_readdir()
most likely after thentfs_attr_open()
call and in a code secton triggering agoto err_out;
jump but not on agoto dir_err_out;
jump, since the latter would override theE2BIG
errno
we get toEIO
instead. On that subject, I can't locate any part of the ntfs-3g code that would explicitly returnE2BIG
, so it looks like this error code is being returned from theif (HookData->Info->Size < ((UINT64)NameLen + 1) * sizeof(CHAR16))
check inDirHook()
.Read()
of the directory with a 0 sized buffer and this is throwing our driver off:EFI_FILE_PROTOCOL.Read()
(Section 13.5 File Protocol) it seems that our issue is that we are returning0
for the size, whereas we should return the minimum required size, per:The text was updated successfully, but these errors were encountered: