You are not logged in.
Hi Arch community,
Arch Linux (archboot creation tool) 2012.04-1, "2k12-R2" has been released.
To avoid confusion, this is not an official arch linux iso release!
Homepage and for more information on archboot:
http://wiki.archlinux.org/index.php/Archboot
Summary:
- Bugfixes and uefi updates
Hybrid image files and torrents are provided, which include
i686 and/or x86_64 core repository. Please check md5sum before using it.
Hybrid image file is a standard CD-burnable image and also a raw disk image.
- Can be burned to CD(RW) media using most CD-burning utilities.
- Can be raw-written to a drive using 'dd' or similar utilities.
This method is intended for use with USB thumb drives.
Please get it from your favorite arch linux mirror:
https://downloads.archlinux.de/iso/archboot/2012.04/
<yourmirror>/iso/archboot/2012.04/
/boot for PXE/Rescue files are provided here:
https://downloads.archlinux.de/iso/arch … 12.04/boot
<yourmirror>/iso/archboot/2012.04/boot
Changelog:
GENERAL:
- kernel 3.3.3/ LTS kernel 3.0.29
- pacman 4.0.3 usage
- RAM recommendations: 768 MB
Kernel changes:
- bump to latest 3.3.x series and bump lts to latest 3.0.x series
Removed features:
- floppy
Environment changes:
- synced with latest mkinitcpio changes
- fixed binary moving to new location in /usr
- added rEFInd boot manager support
hwdetect changes:
- fixed to work with latest userspace
setup changes:
- many grub2 fixes and grub2 cleanup
- added rEFInd support
quickinst changes:
- None
Further documentation can be found on-disk and on the wiki.
Have fun!
greetings
tpowa
Offline
Awesome!! I'll give it a try this weekend.
Offline
Me, too.
Offline
Thanks and great work.
O' rly ? Ya rly Oo
Offline
will this do the trick with grub2, gpt, and pure uefi boot on ASUS boards this time?
Offline
Please test rEFInd+EFISTUB boot (LTS kernel will not work, and Kernel and UEFI Arch should match). Feedback welcome. Also there might be issues with autoprepare and then using any UEFI bootloader, during check for UEFISYS partition. Better to manually create a FAT32 EF00 partition using gdisk before starting /arch/setup in the iso.
After installation the files should be
(UEFISYS)/EFI/arch/refind/refindx64.efi
(UEFISYS)/EFI/arch/refind/refind.conf
(UEFISYS)/EFI/arch/vmlinuz-linux.efi
(UEFISYS)/EFI/arch/initramfs-linux.img
(UEFISYS)/EFI/arch/linux.conf
(UEFISYS)/EFI/arch/refind_linux.conf
In archboot
(UEFISYS)==/tmp/install/boot/efi
In 2012.04-2 iso, UEFISYS partition detection has been revamped. The script now ALWAYS uses the first EF00 partition detected by sgdisk. It offers to format the partition as FAT32 (not FAT16) if required. Any manually mounted UEFISYS partition at /tmp/install/boot/efi will be unmounted, so no use doing that (in 2012.04-2 iso).
Last edited by the.ridikulus.rat (2012-04-29 16:30:05)
Offline
Please test rEFInd+EFISTUB boot (LTS kernel will not work, and Kernel and UEFI Arch should match). Feedback welcome. Also there might be issues with autoprepare and then using any UEFI bootloader, during check for UEFISYS partition. Better to manually create a FAT32 EF00 partition using gdisk before starting /arch/setup in the iso.
EDIT: In archboot git , I revamped UEFISYS partition detection. The script in git ALWAYS uses the first EF00 partition detected by sgdisk. It offers to format the partition as FAT32 (not FAT16) if required. But manually mounted UEFISYS partition (at /boot/efi before launching /arch/setup) will be unmounted, so no use doing that (if using git, not in 2012.04-1 iso).
The installer doesn't seem to want to set up rEFInd properly. No /refind directory is created, and the config files for refind are not copied over. When the installer presents the refind conf file for editing, the screen is blank.
I tried two ways and got the same results both times. First, I used the installer to create the needed partitions. When that didn't work, I wiped the disk and started over, this time using gdisk to set up the needed partitions before beginning the ArchLinux installation sequence.
Last edited by dhave (2012-04-26 18:20:07)
Offline
EDIT: Post removed.
Last edited by the.ridikulus.rat (2012-04-28 08:06:04)
Offline
@dhave: Sorry missed out. Setup downloads rEFInd files from sourceforge. Those files are not present in the iso. So you need to be CONNECTED TO NET to setup rEFInd.
O.K. I must have missed that. I'll try again this weekend.
What I'd really like to test is direct booting (i.e., no bootloader). That's why I was glad to see kernel 3.3 included with this release of Archboot. But I've had trouble moving from 65kid's examples here to my own setup.
Last edited by dhave (2012-04-26 18:39:30)
Offline
What I'd really like to test is direct booting (i.e., no bootloader). That's why I was glad to see kernel 3.3 included with this release of Archboot. But I've had trouble moving from 65kid's examples here to my own setup.
That method (using efibootmgr's args support) is inflexible, especially when you have to make changes to kernel parameters or if the firmware has a character limit on the args wherein you may not be able to enter all the required kernel parameters. Many firmwares are quirky so we can't rely on the firmware alone to properly pass the kernel parameters to the kernel file. Thats one of the reason why the kernel devs want to implement linux.conf support. It is much easier and flexible to store the kernel parameters in a text file (linux.conf) instead of directly in the formware in form of efibootmgr args.
It is possible to launch the efistub kernel using UEFI shell (with the shell added to firmware boot menu using efibootmgr instead of the refindx64.efi). See http://projects.archlinux.org/archiso.g … 4350a11056 for more info. rEFInd is the most flexible method for booting efistub kernels (which provides linux.conf functionality in refind_linux.conf, atleast until linux.conf is merged in kernel sources).
Last edited by the.ridikulus.rat (2012-04-27 07:12:22)
Offline
Due to some mistakes on my part rEFInd support in the setup script will not work (I used "install" utility which is not present in the initramfs, replaced it with cp). You need to update the setup script in the initramfs files in the iso.
(CWD) - dir containing archlinux-2012.04-1-archboot-x86_64.iso
1. Install libisoburn
2. Copy https://bitbucket.org/the_ridikulus_rat … ller/setup to (CWD)/setup
3. Copy https://bitbucket.org/the_ridikulus_rat … ate-iso.sh to (CWD)/archboot-update-iso.sh
5. Run
sudo _REMOVE_i686=1 _REMOVE_x86_64=0 _UPDATE_SETUP=1 _UPDATE_UEFI_SHELL=0 _UPDATE_UEFI_REFIND=1 _UPDATE_SYSLINUX=0 _UPDATE_SYSLINUX_CONFIG=1 _UPDATE_GRUB_UEFI=0 _UPDATE_GRUB_UEFI_CONFIG=1 (CWD)/archboot-update-iso.sh (CWD)/archlinux-2012.04-1-archboot-x86_64.iso
Updated iso will be saved at (CWD)/archlinux-2012.04-1-archboot-x86_64-updated-x86_64.iso .
EDIT: rEFInd and UEFISYS issues fixed in 2012.04-2 iso.
Last edited by the.ridikulus.rat (2012-05-04 18:35:01)
Offline
Due to some mistakes on my part rEFInd support in the setup script will not work (I used "install" utility which is not present in the initramfs, replaced it with cp).
Man! I thought I was going crazy. I should have reported a problem earlier, but I assumed the mistake was on my end, as it usually is.
You need to update the setup script in the initramfs files in the iso.
Rather than try to modify the iso myself, I'll just wait until another iteration of the archboot iso. Right now I'm happy that I finally got direct booting working. I know it's inflexible, but I still like it. I used efibootmgr to create a direct boot menu entry with my normal kernel options and another entry that loads grub2, which I had been using previously. That way I can enter options on the fly if I need to. Evenutally I'll jettison grub2, which I've never been that happy with.
Later I'll experiment with using linux.conf, but no time now.
Last edited by dhave (2012-04-27 21:50:58)
Offline
The 2012.04-2 iso should fix UEFISYS and rEFInd issues. It also contains the refind-bin.zip archive so no need to to be connected to net to setup rEFInd+EFISTUB.
Last edited by the.ridikulus.rat (2012-04-28 08:07:42)
Offline
Thanks for the great work!!!
My GRUBless install works perfectly with the new Archboot 2012.04 „2k12-R2“ version. And I think I finally, FINALLY!, get all of this UEFI stuff:
1. UEFI compatible motherboards can run 'applications' directly from a GPT VFAT formatted partition.
2. GRUB2 is one of those 'applications.'
3. The 3.3 kernel has the 'STUB' patch that allows it to masquerade as an application - you just need to rename it with a '.efi' extension to make the masquerade complete.
4. With efibootmgr you can add the command line and boot parameters to the motherboard's NVRAM instead of to the GRUB2 configuration.
5. You can set one of the applications in the NVRAM as the boot default or use your motherboard's firmware to select whichever boot application you want instead - you'll usually see your hard/solid state disk, CD/DVDs and USBs in the list you have to select from.
6. I even added a second entry to my NVRAM - without any parameters - in anticipation of the 3.4 kernel that will be patched to read them from a linux.conf file (when there are no parameters in the NVRAM) in the same location as the kernel renamed with the .efi extension. NVRAM isn't limitless so you'd likely run out of space if you had lots of entries with very long and complex boot parameters.
I would not have been able to figure any of this out without this amazing "Arch By Hand" install script which I modified to:
a) Use LVM2 to chop a RAID0 array into two (one for root and one for my data) so I could just encrypt the entire array and wouldn't have to enter two passphrases during boot and would be able to reformat/re-install ARCH while leaving my data intact.
b) Removed all reference to GRUB2.
c) Merge the chroot install_efi and post_install scripts into one.
And also this post that explains how to pipe the boot parameters to efibootmgr and add them to the motherboard's NVRAM.
Offline
Thanks for the great work!!!
My GRUBless install works perfectly with the new Archboot 2012.04 „2k12-R2“ version. And I think I finally, FINALLY!, get all of this UEFI stuff:
1. UEFI compatible motherboards can run 'applications' directly from a GPT VFAT formatted partition.
2. GRUB2 is one of those 'applications.'
3. The 3.3 kernel has the 'STUB' patch that allows it to masquerade as an application - you just need to rename it with a '.efi' extension to make the masquerade complete.
So finally you understood how UEFI works. You can see how easy it is actually to setup UEFI bootloader compared to a BIOS one. All the voodo stuff is mainly required to make sure there is a UEFISYS FAT32 gpt partition in the system to store the EFI files/apps.
4. With efibootmgr you can add the command line and boot parameters to the motherboard's NVRAM instead of to the GRUB2 configuration.
5. You can set one of the applications in the NVRAM as the boot default or use your motherboard's firmware to select whichever boot application you want instead - you'll usually see your hard/solid state disk, CD/DVDs and USBs in the list you have to select from.
6. I even added a second entry to my NVRAM - without any parameters - in anticipation of the 3.4 kernel that will be patched to read them from a linux.conf file (when there are no parameters in the NVRAM) in the same location as the kernel renamed with the .efi extension. NVRAM isn't limitless so you'd likely run out of space if you had lots of entries with very long and complex boot parameters.
Archboot 2012.04-2 generates this linux.conf file but it is right now useless with 3.3.x kernels since it does not contain the patch to read linux.conf . Its unlikely to be present in 3.4 too since the merge window is closed and the patch is not there in the mainline kernel git repo. Anyway refind_linux.conf should be flexible enough to compensate for lack of linux.conf support.
BTW I don't plan to add boot parameters in efibootmgr command in the archboot, so either you have to use rEFInd, setup efibootmgr args manually, or wait for linux.conf support.
I would not have been able to figure any of this out without this amazing "Arch By Hand" install script which I modified to:
a) Use LVM2 to chop a RAID0 array into two (one for root and one for my data) so I could just encrypt the entire array and wouldn't have to enter two passphrases during boot and would be able to reformat/re-install ARCH while leaving my data intact.
b) Removed all reference to GRUB2.
c) Merge the chroot install_efi and post_install scripts into one.
And also this post that explains how to pipe the boot parameters to efibootmgr and add them to the motherboard's NVRAM.
Please post your version of the script in that thread or pastebin/github (somewhere). You might need to incorporate my/dieterbe's fixes for that script ( https://github.com/the-ridikulus-rat/ar … e/uefi_fix ), in yours.
Offline
will this do the trick with grub2, gpt, and pure uefi boot on ASUS boards this time?
What trick is that exactly? Did efibootmgr not work for you? Most of the UEFI issues seem to have been fixed in grub2 2.00~beta4. If it still has issues, try rEFInd+EFISTUB.
Last edited by the.ridikulus.rat (2012-04-29 16:32:35)
Offline
Hi, I'm following the "Archboot Allinone ISO HOWOTO" instructions on the ArchWiki. I downloaded and mounted archlinux-2012.04-2-archboot-dual.iso but there aren't core-x86_64 or core-i686 folders in the iso. There only exists arch, boot, efi, packages directories. However, the packages dir contains archboot_packages_[any|i686|x86_64].squashfs files. I mounted the any.squashfs and it has a pkg dir with what appears to be binary packages. Should I use this in place of the <imagepath>/core-x86_64/pkg listed in the Wiki? If so the Wiki should be updated to reflect this.
Thanks in advance for any help.
Offline
@ ridikulus
It has just occurred to me that pacman will need to be aware that after a kernel update the new kernel with the ".efi" extension and the initramfs need to be in the /boot/efi/arch/ directory (or wherever you choose to store it for the GRUBless install). Even so, so far simply moving them manually after the kernel update doesn't seem to work. The boot fails because it cant' find any modules.
EDIT:
To quote Rod Smith...
Maintaining the Kernel's EFI Stub Loader
Because the kernel's EFI stub loader is not currently supported by any distribution, you're on your own when it comes to maintenance. In the future, it's possible that distributions will use efibootmgr or other tools to help maintain installations that use this approach, or support it by maintaining the configuration files for GRUB or rEFInd.
Last edited by KairiTech (2012-05-07 16:04:37)
Offline
I ran into a problem when performing an installation yesterday, I have a BIOS based system and I chose to install Syslinux in the partition where /boot is residing instead of in the MBR of the disk. The installation script reports the installation to be successful but it wasn't, I use the first 512 bytes of the partition to trigger Syslinux but it doesn't work.
After I booted into Archboot again and mounted the partitions I issued the following command:
extlinux -i /mnt/boot/syslinux
Besides of the expected output stating which device contains that directory I had the following output too:
[time] extlinux: sending ioctl 4c05 to a partition!
[time] extlinux: sending ioctl 4c05 to a partition!
[time] extlinux: sending ioctl 4c03 to a partition!
[time] extlinux: sending ioctl 4c03 to a partition!
Would that have something to do with it? What could be the cause of that?
Executing the same command more times gives similar output, and sometimes only the expected line:
[Arch Linux: /]# extlinux -i /mnt/boot/syslinux
/mnt/boot/syslinux is device /dev/sda5
[time] extlinux: sending ioctl 4c05 to a partition!
[time] extlinux: sending ioctl 4c05 to a partition!
[time] extlinux: sending ioctl 4c03 to a partition!
[time] extlinux: sending ioctl 4c03 to a partition!
[Arch Linux: /]# extlinux -i /mnt/boot/syslinux
/mnt/boot/syslinux is device /dev/sda5
[time] extlinux: sending ioctl 4c05 to a partition!
[time] extlinux: sending ioctl 4c05 to a partition!
[Arch Linux: /]# extlinux -i /mnt/boot/syslinux
/mnt/boot/syslinux is device /dev/sda5
[Arch Linux: /]#
I didn't wanted Syslinux in the MBR of the disk mainly because I have a Windows 7 installation in another partition and unless its partition is set to be the active one ("boot" flag on) hibernation or suspension won't work as expected, so right now I'm booting Syslinux from Windows' BCD until Syslinux 4.06 is out (will support booting from an NTFS partition).
Offline
I am trying to build and burn the archboot iso file on my x86_64 Arch.
[gabx@magnolia Desktop]$ sudo pacman -S archboot
Password:
resolving dependencies...
warning: cannot resolve "procps>=3.2.8-4", a dependency of "archboot"
:: The following package cannot be upgraded due to unresolvable dependencies:
archboot
Do you want to skip the above package for this upgrade? [y/N] n
procps-ng 3.3.2-2 is already installed. Why this error message? Shall I ignore? Is there any thing I have to change in my package list?
TY for advice.
EDIT : from what I read and understand, Arch went recently from procps to procps-ng, so it is normal that my system doesn't have anymore the procps package listed as installed and I can safely ignore.
Please can someone confirm?
Last edited by gabx (2012-05-09 15:54:33)
Offline
I am filling a bug report. procps is no longer in use in Arch, replaced by procps-ng.
So procps shouldn't be checked for dependencies, but procps-ng instead.
Building the ISO hybrid ignoring the dependency warning.
Offline
resolving dependencies...
warning: cannot resolve "libfetch>=2.33-3", a dependency of "archboot"
:: The following package cannot be upgraded due to unresolvable dependencies:
archboot
Do you want to skip the above package for this upgrade? [y/N] n
error: failed to prepare transaction (unexpected error)
I know that I can skip this but, why this happend? is not supposed that this use packages w no version?????
EDIT:
/etc/mkinitcpio.conf
MODULES="pata_sis sata_sis ehci-hcd ohci-hcd ext2 reiserfs"
HOOKS="base udev keymap fsck autodetect pata scsi sata usb fw usbinput filesystems"
Grub: Grub2-bios
df -h
/dev/sda1 32M 30M 2M 97% /boot
how you se the default 32M for boot are so less space now, and in a near future or if you use many modules and/or hooks can fill complettly yours 32M, I sugest bigger this to 48-64M, I know this is aboidable for if you change this in the installation, but if you are newbi and not care about the space, or think erroneous that 32 is enought and in a update the /boot are filled?
is more for prevention
and this affect to to the arch-official-install and to archiso-install (both use 32M for /boot)
Last edited by Jristz (2012-05-14 00:03:04)
Well, I suppose that this is somekind of signature, no?
Offline
When will be released 2012.05-2 iso?
Offline
When will be released 2012.05-2 iso?
New isos are generally released once in 2-3 months unless the setup script cannot work with updated packages in online repos (due to syntax changes etc.).
Offline
@ ridikulus
It has just occurred to me that pacman will need to be aware that after a kernel update the new kernel with the ".efi" extension and the initramfs need to be in the /boot/efi/arch/ directory (or wherever you choose to store it for the GRUBless install). Even so, so far simply moving them manually after the kernel update doesn't seem to work. The boot fails because it cant' find any modules.
If you are using systemd, you can try https://wiki.archlinux.org/index.php/UE … ng_Systemd .
Offline