No warning/error when the output file could not be written completely #2197
Comments
omcaif
changed the title
|
My bad. The issue is there was not enough space in the Should dracut give a warning if the file will not fit? If not, feel free to close this issue. |
|
@omcaif was it dracut executable (shell scrip) that was not handling the out of space situation, or perhaps some other app - e.g. cpio. I am trying to understand if dracut or some other process/executable should handle this |
I am not sure... Here is an easy way to try it out for yourself: The output from the original "To Reproduce" section is still valid to this issue. There is no warning or error in that output, so I do not know who is at fault... |
|
It's |
`sbsign` does not issue any error if there is not enough disk space to create the signed file using its `--output` option. So, verify the signed image after its creation using `sbverify`. Fixes issue dracutdevs#2197
`sbsign` does not issue any error if there is not enough disk space to create the signed file using its `--output` option. So, verify the signed image after its creation using `sbverify`. Fixes issue #2197
|
@aafeijoo-suse it's an harmless error from sbsign, the problem I'm suspecting here is that he forgot to boot into an efi shell and manually set the image as a boot option and or created the entry with wrong path to efi file in anycase we need something more to work on. |
Hmm.. it's not harmless: The problem for us is we are trusting the |
`sbsign` does not issue any error if there is not enough disk space to create the signed file using its `--output` option. So, verify the signed image after its creation using `sbverify`. Fixes issue dracutdevs#2197 (cherry picked from commit a6dd5bf)
`sbsign` does not issue any error if there is not enough disk space to create the signed file using its `--output` option. So, verify the signed image after its creation using `sbverify`. Fixes issue dracutdevs#2197
Edit: Look at comment.
Describe the bug
Creating a new UEFI image with dracut makes a smaller image than previously (see Additional Context section), and it does not boot. The image does not seem to have an initial ramdisk. Trying to boot from UEFI shell gives the error of something like "Command Error Status: Unsupported".
Distribution used
Gentoo
Dracut version
dracut 059
Init system
OpenRC 0.46
To Reproduce
The kernel config I am using is the same as the one from Arch Linux.
Expected behavior
lsinitrdon the generated image would show the kernel modules and executing it would boot into Linux.Additional context
I recently switched my kernel config from a minimal non-modular config to the huge modular one from Arch Linux (because being able to unload modules is sometimes useful and I am currently too lazy to minimize the configuration). The first time I tried to generate an image, dracut, unsurprisingly, could not create a host only image because it could not read currently loaded modules, so I decided to boot from a Arch Linux USB installer and
chrootinto my Gentoo install, then run dracut to createlinux.efi.bak. This worked.Later, I booted using
linux.efi.bakand tried to recreate the UEFI image, and the result is as seen above. I do not think I changed any of the dracut configuration, and I think I ran the same command as above, so I am not sure what is wrong...I tried booting back into the Arch Linux USB installer to see if I can recreate the image, but I could not.
The text was updated successfully, but these errors were encountered: