[arch-releng] My archiso TODO/ideas (_draft_)
Hello, This is a draft of some sorts of ideas, future changes, and fixes for archiso that I have in mind: FEATURES: * UEFI boot support (FS#20419) At some time I want to support UEFI boot. But I do not have any real hardware to test it. Neither UEFI firmware for qemu (two versions tested) or virtualbox works fine, testing with some UEFI compatible mediums without happy results. * syslinux keymaps (FS#21725) I worked on this some time ago, but I want some feedback from people that needs this, we need a trivial lilo patch for keymaps generation. * syslinux helps For now, put boot options that are on the new README. * md5sum Self check of all files (mostly important *.sfs), as boot option, executed at initramfs stage. $install_dir/checksums.md5 * swap on zram (FS#18463) A boot options that setup a zram storage for swap space. (I done some tests with my custom build and works nice, helps a lot on machine with 512MiB of RAM). This feature will be experimental since zram is in linux/stage. * dm-snapshots cow on zram Currently *.cow files are store on a a single tmpfs filesystem /cowspace. We can setup one zram device for each cow device directly without any filesystem. * cow options (cowdevice=/cowpath=) Allow to setup a device and path where cow files will be stored, this can be usefull for persistent feature. Live distros based on archiso can benefit. * mount options for images based on dm-snapshot. Allow to specify mount options in some place. Maybe in aitab (per image) or via bootparam (global). For example for using noatime (save fews megabytes on cow dev). * build.sh allows execute from absolute path (implemented on my experimental branch) Instead of copying all files from /usr/share/archiso/config/%blah-blah% to some place and work on it. Allow to execute directly from /usr/share/archiso/config/%blah-blah% and use current directory as working dir. FIXES: * configs/releng/build.sh: Needs a better error-recovery for download core repo (wget). Try again if fails, maybe pacman can be used instead of wget (FS#18959) * console serial port. Needs better command line parsing, current implementation works partially. (example console=ttyS0 does not work, needs at least speed [console=ttyS0,9600]). (FS#16232) Feedback is welcomed, good luck! -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Tue, 09 Aug 2011 21:43:09 -0300, Gerardo Exequiel Pozzi wrote:
* UEFI boot support (FS#20419) At some time I want to support UEFI boot. But I do not have any real hardware to test it. Neither UEFI firmware for qemu (two versions tested) or virtualbox works fine, testing with some UEFI compatible mediums without happy results.
No need to hurry here. Afaik UEFI and linux (or UEFI in general) has quite some problems and regressions over the default BIOS boot. I have such hardware, but what the bug report does not mention is that it works pretty fine without any downsides without it.
* syslinux keymaps (FS#21725) I worked on this some time ago, but I want some feedback from people that needs this, we need a trivial lilo patch for keymaps generation.
It would be cool if one could choose the keymap/language from a syslinux menu and then also propagate this info to the live system to use the same values here as well.
* md5sum Self check of all files (mostly important *.sfs), as boot option, executed at initramfs stage. $install_dir/checksums.md5
That would be cool and very useful imho. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 08/10/2011 02:18 AM, Pierre Schmitz wrote:
* UEFI boot support (FS#20419) At some time I want to support UEFI boot. But I do not have any real hardware to test it. Neither UEFI firmware for qemu (two versions tested) or virtualbox works fine, testing with some UEFI compatible mediums without happy results. No need to hurry here. Afaik UEFI and linux (or UEFI in general) has quite some problems and regressions over the default BIOS boot. I have such hardware, but what the bug report does not mention is that it works
On Tue, 09 Aug 2011 21:43:09 -0300, Gerardo Exequiel Pozzi wrote: pretty fine without any downsides without it. I read some weeks ago that some UEFI implementations always/only read a "default" location in UEFI partitions, assuming that the only OS that will be used is Windows, breaking the "ecosystem" under /EFI directory.
* syslinux keymaps (FS#21725) I worked on this some time ago, but I want some feedback from people that needs this, we need a trivial lilo patch for keymaps generation. It would be cool if one could choose the keymap/language from a syslinux menu and then also propagate this info to the live system to use the same values here as well.
* md5sum Self check of all files (mostly important *.sfs), as boot option, executed at initramfs stage. $install_dir/checksums.md5 That would be cool and very useful imho.
Thank you. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Thu, Aug 11, 2011 at 04:54, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 08/10/2011 02:18 AM, Pierre Schmitz wrote:
On Tue, 09 Aug 2011 21:43:09 -0300, Gerardo Exequiel Pozzi wrote:
* UEFI boot support (FS#20419) At some time I want to support UEFI boot. But I do not have any real hardware to test it. Neither UEFI firmware for qemu (two versions tested) or virtualbox works fine, testing with some UEFI compatible mediums without happy results.
What was the exact problem with QEMU and VBox UEFI firmware? Both use Tianocore UDK/EDK2 OVMF firmware https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF_FAQ .
No need to hurry here. Afaik UEFI and linux (or UEFI in general) has quite some problems and regressions over the default BIOS boot. I have such hardware, but what the bug report does not mention is that it works pretty fine without any downsides without it.
Not with Linux 3.0 . Might want ot read http://mjg59.dreamwidth.org/ .
I read some weeks ago that some UEFI implementations always/only read a "default" location in UEFI partitions, assuming that the only OS that will be used is Windows, breaking the "ecosystem" under /EFI directory.
The location you are btalking about is <UEFI_SYSTEM_PARTITION>/efi/boot/bootx64.efi . Windows by default copies <UEFI_SYSTEM_PARTITION>/efi/Microsoft/Boot/bootmgfw.efi to bootx64.efi incase the UEFI NVRAM entry fails to boot . I currently have grub2 as the bootx64.efi file and added a chainloading entry for bootmgfw.efi ( https://help.ubuntu.com/community/UEFIBooting#Chainloading%20Windows%20x86_6... ) . You can have a look at Archboot iso for ideas on implementing UEFI support. For generating iso, you need to use xorriso (from libisoburn) (not cdrkit mkisofs). But implementing bootloader support in the aif script is a much bigger task. I can help you with implementing UEFI support in archiso but right now I am too busy to hack on aif . For UEFI firmware chainloaded from BIOS (real hardware testing) checkout www.rodsbooks.com/bios2uefi/index.html . Regards. Keshav
On 08/11/2011 12:47 PM, KESHAV P.R. wrote:
On Thu, Aug 11, 2011 at 04:54, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 08/10/2011 02:18 AM, Pierre Schmitz wrote:
On Tue, 09 Aug 2011 21:43:09 -0300, Gerardo Exequiel Pozzi wrote:
* UEFI boot support (FS#20419) At some time I want to support UEFI boot. But I do not have any real hardware to test it. Neither UEFI firmware for qemu (two versions tested) or virtualbox works fine, testing with some UEFI compatible mediums without happy results. What was the exact problem with QEMU and VBox UEFI firmware? Both use Tianocore UDK/EDK2 OVMF firmware https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF_FAQ . Hello,
Problem is that is slow in all steps: POST, loading kernel+initramfs, booting kernel (tested some time ago, one or two months, maybe these things changed recently), and finally crash or nothing. Sometimes virtualbox and qemu crash, etc. Mediums tested (what I remember): Fedora 15, Archboot 2011.06, Scientific Linux 6.0.
No need to hurry here. Afaik UEFI and linux (or UEFI in general) has quite some problems and regressions over the default BIOS boot. I have such hardware, but what the bug report does not mention is that it works pretty fine without any downsides without it. Not with Linux 3.0 . Might want ot read http://mjg59.dreamwidth.org/ . OK, I will test with it. Yes these are the articles that I read :)
I read some weeks ago that some UEFI implementations always/only read a "default" location in UEFI partitions, assuming that the only OS that will be used is Windows, breaking the "ecosystem" under /EFI directory. The location you are btalking about is <UEFI_SYSTEM_PARTITION>/efi/boot/bootx64.efi . Windows by default copies<UEFI_SYSTEM_PARTITION>/efi/Microsoft/Boot/bootmgfw.efi to bootx64.efi incase the UEFI NVRAM entry fails to boot . I currently have grub2 as the bootx64.efi file and added a chainloading entry for bootmgfw.efi ( https://help.ubuntu.com/community/UEFIBooting#Chainloading%20Windows%20x86_6... ) . Yes, and also (Windows) put a fallback entry in the default location. So if the UEFI implementation does not set variables correctly., there is no other choices on that systems. :( You can have a look at Archboot iso for ideas on implementing UEFI support. For generating iso, you need to use xorriso (from libisoburn) (not cdrkit mkisofs). But implementing bootloader support in the aif script is a much bigger task. I can help you with implementing UEFI support in archiso but right now I am too busy to hack on aif . Or using original cdrecord mkisofs. The cdrkit is a museum piece! ;) For UEFI firmware chainloaded from BIOS (real hardware testing) checkout www.rodsbooks.com/bios2uefi/index.html .
Cool! Anyway when I talk about real hardware I also talk about what vendors are doing bad when implementing things (Like ACPI issues, many ACPI are Windows friendly only).
Regards.
Many many thanks!
Keshav
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On 08/11/2011 07:50 PM, Gerardo Exequiel Pozzi wrote:
You can have a look at Archboot iso for ideas on implementing UEFI support. For generating iso, you need to use xorriso (from libisoburn) (not cdrkit mkisofs). But implementing bootloader support in the aif script is a much bigger task. I can help you with implementing UEFI support in archiso but right now I am too busy to hack on aif . Or using original cdrecord mkisofs. The cdrkit is a museum piece! ;)
Oh but xorriso has an option -isohybrid-mbr (one step mkisofs/isohybrid), maybe we can switch now to xorriso preparing terrain for UEFI... -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, Aug 12, 2011 at 21:33, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 08/11/2011 07:50 PM, Gerardo Exequiel Pozzi wrote:
You can have a look at Archboot iso for ideas on implementing UEFI support. For generating iso, you need to use xorriso (from libisoburn) (not cdrkit mkisofs). But implementing bootloader support in the aif script is a much bigger task. I can help you with implementing UEFI support in archiso but right now I am too busy to hack on aif .
Or using original cdrecord mkisofs. The cdrkit is a museum piece! ;)
Oh but xorriso has an option -isohybrid-mbr (one step mkisofs/isohybrid), maybe we can switch now to xorriso preparing terrain for UEFI...
See line 349 of https://projects.archlinux.org/archboot.git/tree/usr/bin/archboot-allinone.s... . Regards. Keshav
On 08/12/2011 01:25 PM, KESHAV P.R. wrote:
On Fri, Aug 12, 2011 at 21:33, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 08/11/2011 07:50 PM, Gerardo Exequiel Pozzi wrote:
You can have a look at Archboot iso for ideas on implementing UEFI support. For generating iso, you need to use xorriso (from libisoburn) (not cdrkit mkisofs). But implementing bootloader support in the aif script is a much bigger task. I can help you with implementing UEFI support in archiso but right now I am too busy to hack on aif . Or using original cdrecord mkisofs. The cdrkit is a museum piece! ;)
Oh but xorriso has an option -isohybrid-mbr (one step mkisofs/isohybrid), maybe we can switch now to xorriso preparing terrain for UEFI... See line 349 of https://projects.archlinux.org/archboot.git/tree/usr/bin/archboot-allinone.s... .
Regards.
Keshav
Thanks, while working on changes, I found that xorriso does not support UDF. We currently using ISO 9660 (level 3) + UDF. Anyway, I succesfully builded iso with xorriso, booting as cd-rom and disk. Support for UDF layer was added by Sven some time ago, so CC to he, to know opinions. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
participants (3)
-
Gerardo Exequiel Pozzi
-
KESHAV P.R.
-
Pierre Schmitz