- 12 May, 2014 1 commit
-
-
Michael Shigorin authored
The newly-introduced STAGE1_KCONFIG variable serves to keep those kernel configuration options that are required to be present in the kernel to boot.
-
- 19 Mar, 2014 1 commit
-
-
Michael Shigorin authored
That reflects the packaging and distribution practice having formed during last year or so...
-
- 05 Mar, 2014 1 commit
-
-
Michael Shigorin authored
This change is done to reduce ambiguity in some cases; the previous intention has been to ease navigation when staying in a particular directory, now it's been changed in favour of convenient toplevel `git grep' in fact. Both variants have their pros and cons, I just find myself leaning to this one by now hence the commit. Feel free to provide constructive criticism :) Some path-related bitrot has also been fixed while at that.
-
- 24 Dec, 2013 1 commit
-
-
Michael Shigorin authored
I've noted that this bit of code should be fixed up before pushing but managed to overlook that in the end :( mkimage version bump is due to the somewhat changed layout of EFI packages and binaries within those (linked message in Russian): http://lists.altlinux.org/pipermail/devel-distro/2013-December/001283.html
-
- 18 Dec, 2013 2 commits
-
-
Michael Shigorin authored
It's at least as worthy as sbsigntools are.
-
Michael Shigorin authored
It's implemented just like EFI_SHELL and will definitely change someday but so far it's like this...
-
- 17 Dec, 2013 1 commit
-
-
Michael Shigorin authored
We chose to provide methods to sign packages but to avoid signing these by default (with some arbitrary test keys) the signatures are being added *after* the build by means of rpmrebuild-pesign; all of this is made significantly more complicated if there are separate -signed subpackages. So these are being dropped in the packages; account for that.
-
- 17 Jun, 2013 1 commit
-
-
Michael Shigorin authored
This feature is more generally applicable indeed; might result in duplication due to the installer components adding "efivars" independently but that is to be sorted out later in those components: - check whether it's added already sometime soon; - maybe stop adding that at some point in the future. install2 and rescue roots still need this too though.
-
- 25 Feb, 2013 1 commit
-
-
Michael Shigorin authored
Bump it to account for the useful fixes in mkimage-0.2.7.
-
- 21 Feb, 2013 1 commit
-
-
Michael Shigorin authored
It's possible that use/efi/signed target has fired already at the time when use/efi/shell is invoked; shouldn't clobber the signed shell with unsigned one.
-
- 18 Feb, 2013 1 commit
-
-
Michael Shigorin authored
Its support is quite mature and practically useful by now. Let's also add a convenient alias.
-
- 11 Feb, 2013 1 commit
-
-
Michael Shigorin authored
Helps with #28470 (FAT not being recognized) which is critical due to ESP being FAT by spec :-/ Thanks timonbl4@ for the hint.
-
- 04 Feb, 2013 1 commit
-
-
Michael Shigorin authored
Was an oversight to miss it.
-
- 21 Jan, 2013 3 commits
-
-
Michael Shigorin authored
It's aimed at providing UEFI shell implementation which is very useful for repairs and debug; if the "signed" mode is requested then the signed variant is used either. Please note that there are two distinct uses: - a shell lying around on a filesystem to be copied by hand; - a shell available in EFI part of boot media to be launched by firmware's or standalone boot manager (e.g. refind).
-
Michael Shigorin authored
UEFI shell is pretty valuable debugging and fixup tool. When one has to mess with Restricted Boot, openssl and some PE signing tools might come handy either; see also http://www.rodsbooks.com/efi-bootloaders/secureboot.html
-
Michael Shigorin authored
Its bootloader autodetection capabilities can prove quite useful; this particular addition has been "sponsored" by this thread: http://lists.altlinux.org/pipermail/sisyphus/2013-January/subject.html#359481
-
- 14 Jan, 2013 3 commits
-
-
Michael Shigorin authored
The variables are best influenced by targets and not directly to avoid architecture dependent clashes.
-
Michael Shigorin authored
mkimage > 0.2.5 should have received enhanced UEFI support including the ability to setup refind (#28349); make the feature ready for that.
-
Michael Shigorin authored
The implementation goes the shim[1] way as described here[2]; many thanks to Matthew Garrett and Rod Smith. [1] http://mjg59.dreamwidth.org/20303.html [2] http://www.rodsbooks.com/efi-bootloaders/secureboot.html
-
- 26 Dec, 2012 2 commits
-
-
Michael Shigorin authored
The rescue feature intentionally doesn't pick up THE_PACKAGES and THE_LISTS into stage2, so add EFI ones explicitly.
-
Michael Shigorin authored
There's a possibility to run into IA32 EFI but that's rather uninteresting hardware (ancient Xeon servers and <s>outdated</s> early Intel Mac laptops). Just drop it on the floor. As x86_64 UEFI support would result in "2D hybrid(r)(tm)" image which boots with all combinations of BIOS/UEFI by CD|DVD/Flash (or at least should boot), some downgrace seems due: use/efi will turn use/isohybrid on non-x86_64 -- which will require further tweaks on PPC/ARM some day.
-
- 17 Dec, 2012 1 commit
-
-
Michael Shigorin authored
The initial approach required some quite involved postprocessing as described in http://www.altlinux.org/UEFI#HOWTO; after having ironed out the kinks so that initial EFI support could be merged into mkimage proper we're better off just using it, eh?
-
- 19 Nov, 2012 1 commit
-
-
Michael Shigorin authored
EFI/UEFI is mostly about partitioning and bootloader setup, at least from a distribution's point of view; so the appropriate tools should be handy and firmware interface module should not be exterminated from installer images but get autoloaded instead. Please note that while there exists 32-bit x86 EFI we don't bother with it at the time being: it's relevant to some irrelevant Xeon systems as well as for the older Intel Macs (<2008) that are long out of fashion anyways. That is, initially we deal with x86_64 EFI only.
-