You are not logged in.

#26 2011-11-16 01:47:17

spoked
Member
Registered: 2011-09-03
Posts: 30

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

altercation wrote:

Success. The short solution to the current kernel version mismatch is just to install using the local file repository.

I'll work on modifying the script to handle this, but for now you can do it easily enough.

Run through the script but stop/exit before mounting the new partitions.

run /arch/setup, mount the swap and / root partitions (NOT the efi boot partition in /dev/sda1) and install from local file repository.

Don't install bootloader. Exit the install and start the script commands (manually is probably easiest) at the proc/sysfs/dev mounts.

I just reinstalled my system this way, no problems. I'll detail more in a bit.

Thanks for getting back so quickly on this. Meanwhile, I had the same deduction, but can't get it to work with the /arch/setup script.

I mount my usb dev to /src before running setup, but when I select local packages it gives me the error that nothing is in /src and squashfs cannot be mounted. On another console I check mount, and my usb drive is unmounted! Same if I mount it while /arch/setup is running.

Is there a simple way to modify the setup script to make it work, or is there a step I missed somewhere? Otherwise, I am quite confortable with the rest of the process.

Thanks for the help.

Offline

#27 2011-11-16 02:29:24

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

I've been starting up /arch/setup, switching to a different console, mounting /dev/sdb1 to /src and then proceeding. I have seen it fail a couple times as you describe. Have you tried to mount /dev/sdb1 (or whatever your usb is) after configuring your mount points in archboot? I have to check to see if the archboot script it umounting something along the way, but I imagine it's something like that.

So basically I'd try to mount the usb right before you select source (and thus after mounting everything else).

In the meantime, I'll work on adding in local repo functionality to this script. I'm not going to add any optional stuff, just switch over to local repo entirely, otherwise I'm just retooling archboot entirely smile EDIT: note that in the final implementation I use a hybrid of local and net (any packages not on the archboot media are sourced from the network).

Last edited by altercation (2011-11-16 04:37:26)


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#28 2011-11-16 04:14:37

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

Ok, I've updated the script in the top post ( https://bbs.archlinux.org/viewtopic.php … 5#p1013775 ) and it now sources from the local Archboot media when possible, resulting in a matched kernel and successful installation (here... ymmv).

@spoked et al, let me know if this new script works for you.


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#29 2011-11-16 04:41:44

spoked
Member
Registered: 2011-09-03
Posts: 30

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

Thanks for your replies. I have not tried the exact script, so I cannot testify that it works. I am working with a disk that I do not want to fully wipe so I prefer to do it all by hand.

I found a line in /arch/setup that unmounts devices before checking for media. Commenting it out allowed me to install successfully. I will edit later to specify exactly what line it is.

In the mean time, my remaining quest is now to get grub2 uefi to boot the LUKS encrypted root partition... almost there, but stuck at loading initramfs. But I don't want to bring this off topic smile

Offline

#30 2011-11-16 04:43:03

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

spoked wrote:

Thanks for your replies. I have not tried the exact script, so I cannot testify that it works. I am working with a disk that I do not want to fully wipe so I prefer to do it all by hand.

I found a line in /arch/setup that unmounts devices before checking for media. Commenting it out allowed me to install successfully. I will edit later to specify exactly what line it is.

In the mean time, my remaining quest is now to get grub2 uefi to boot the LUKS encrypted root partition... almost there, but stuck at loading initramfs. But I don't want to bring this off topic smile

Quite on topic for me. I'm adding LUKS to this script next (actually had it in before but pulled it to remove complexity while sorting out the efi stuff).


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#31 2011-11-16 05:19:48

spoked
Member
Registered: 2011-09-03
Posts: 30

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

I noticed that you had a partition labelled "LUKS" in your script, so I tried to bring up the subject wink

Bringing UEFI in the picture complicates things for sure. I have tried, unsucessfully, different configurations. I started using lvm on top of LUKS partition, but I felt that this too was complicating things, so I decided to try to make it work with a single / partition that is LUKS encrypted. Also, I created a second small partition following the EFI one, that is formattted ext2 and mounted to /boot. This way, vmlinuz and initramfs images are stored unencrypted for grub to use. Surely, there is a way to change this to reside in /boot/efi on the EFI partition, but I wouldn't know how to do this.

I added the dm_mod dm_crypt aes_x86_64 modules and encrypt HOOK to mkinitcpio.conf and rebuilt the images.

I've also tried the default grub.efi and a custom efi built with the crypto module.

Once the system is installed and grub efi image is installed on the system, GRUB cannot get past "loading initramfs". I see some disk activity and after a while, it just hangs there. My grub.cfg lines are like this:

insmod part_gpt
insmod dm_mod
insmod ext2
insmod crypto # my guess, is this ok?
set root='(hd0,gpt2)'  # ext2 /boot partition
/vmlinuz-linux root=/dev/mapper/root cryptdevice=/dev/sda3:root ro
/initramfs

I have tried swapping root and cryptdevice arguments, I don't know if their order matters.

Last edited by spoked (2011-11-16 05:30:36)

Offline

#32 2011-11-16 19:00:37

spoked
Member
Registered: 2011-09-03
Posts: 30

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

Success! I got it to work after a good night sleep... I used a combination of techniques, picking stuff from your script and elsewhere in the bbs and wiki. In the end, I used a separate ext2 /boot partition and lvm on top of the LUKS partition. I edited a couple of lines in the /arch/setup script and let it install grub2-efi. It did not seem to work entirely so I made sure to finish the install manually, but keep the generated grub.cfg. I also decided to tell the installer to point to devices by UUID. Somehow, I think this helps make sure everything ties in together between the system and grub.

My config resembles the following:

/etc/fstab

UUID=*sda2 UUID* /boot       ext2 defaults 0 1
UUID=*sda1 UUID* /boot/efi  vfat defaults 0 1
UUID=*/dev/mapper/vgcrypt-home UUID* /home     ext4 defaults 0 1
UUID=*/dev/mapper/vgcrypt-root  UUID* /boot        ext4 defaults 0 1

grub.cfg

menuentry "Arch Linux" {
  search --fs-uuid --no-floppy --set=root *sda2 ext2 /boot partition UUID*
  linux /vmlinux-linux root=/dev/mapper/vgcrypt-root rootfstype=ext4 cryptdevice=/dev/sda3:vgcrypt ro add_efi_memmap # i guess /dev/sda3 could be changed for /dev/disk/by-uuid/*sda3 UUID*
  initrd /initramfs-linux.img
}

mkinitpcio.conf

MODULES=" ... dm_mod dm_crypt aes_x86_64 ext2 ext4 vfat"

HOOKS="... usb usbinput keymap encrypt lvm2 filesystems" # not sure if usbinput is actually required for a laptop

Offline

#33 2011-11-16 23:25:13

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

spoked wrote:
HOOKS="... usb usbinput keymap encrypt lvm2 filesystems" # not sure if usbinput is actually required for a laptop

Glad you got it working, I'm still working on implementing all in a single script. Thought I'd have to generate a custom efi application for grub but it looks like you did it without that, so that's good info.

FWIW, you only need usbinput if you are using an external usb keyboard on your laptop, but it doesn't hurt to include it just in case you end up using one in future.

Last edited by altercation (2011-11-17 00:06:59)


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#34 2011-11-17 07:44:53

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

I've updated the first post of this thread with small changes that now unify the EFI and /boot partitions. It's cleaner and lays the ground work for a successful LUKS boot. I hope. I'm still hitting the hang @spoked was also hitting after loading the initramfs from grub2. Unfortunately, I've yet to move past that. EDIT: ok, what I took for a hang was the crypt prompt not being displayed, despite removing "quiet" from the kernel run time options. Hmmm. Anyhow, luks is working.

I'll add that script tomorrow if anyone is interested.

Last edited by altercation (2011-11-17 10:21:59)


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#35 2011-11-17 15:23:34

spoked
Member
Registered: 2011-09-03
Posts: 30

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

altercation wrote:

I've updated the first post of this thread with small changes that now unify the EFI and /boot partitions. It's cleaner and lays the ground work for a successful LUKS boot. I hope. I'm still hitting the hang @spoked was also hitting after loading the initramfs from grub2. Unfortunately, I've yet to move past that. EDIT: ok, what I took for a hang was the crypt prompt not being displayed, despite removing "quiet" from the kernel run time options. Hmmm. Anyhow, luks is working.

I'll add that script tomorrow if anyone is interested.


Hmm, interesting to see that you came across the same behavior with initramfs. It seems that the grub configuration output by /arch/setup is different from the one from grub-mkconfig.

I'd be interested in seeing your updated script, your work will make it much easier for people to get started with the complexity brought by GPT partitioning, UEFI, LUKS and grub2.

Offline

#36 2011-11-17 23:24:20

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

I've migrated the scripts to github, including two versions (non-encrypted and LUKS-encrypted):

See code at: https://github.com/altercation/arch-by-hand

Note that the encrypted version boots fine from grub2 menu but does not show the crypt passphrase prompt. On my machine, at least, it seems to be related to the graphics mode grub2 thinks it's in. I'll continue working on that. For now you type it in "blind". (EDIT: no longer true, now working and visible prompt)

This represents a complete, start-to-finish install of Archlinux in an absolutely stripped down EFI state. Only one EFI/boot partition, only one root partition (and a swap, though this could be rolled into LUKS using LVM).

It's all pretty clean and, most importantly, I have a much greater understanding of the EFI boot process. This is pretty KISS and I'm pleased with the results.

EDIT: Solved the hidden passphrase issue. GRUB_GFXPAYLOAD_LINUX=keep was screwing it up. Added fix to script on github (see link in this post above).

Nov 18 update: added encrypted swap.

Last edited by altercation (2011-11-18 08:33:33)


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#37 2011-11-18 16:29:27

the.ridikulus.rat
Member
From: Indiana, USA
Registered: 2011-10-04
Posts: 765

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

@altercation: Don't name the scripts as .efi, may be .efi.sh, .efi is for efi applications.

Offline

#38 2011-11-18 19:12:14

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

the.ridikulus.rat wrote:

@altercation: Don't name the scripts as .efi, may be .efi.sh, .efi is for efi applications.

Yeah, you'd think after all this messing around with .efi applications I'd have noticed that dropping .sh was a bad idea. Thanks for the catch, .sh suffix restored to the scripts.


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#39 2011-11-18 23:50:45

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

I just got rid of the /boot/efi directory entirely. EFI is surprisingly flexible now that I see it as less of a black box. GRUB2 still doesn't properly support non default PREFIX locations, but efibootmgr is more flexible and we can simply use /boot/grub as our EFI path.

If this doesn't work on your particular system, I'd be curious to hear it, but if EFI bootmgr is doing its job, everything should be the same as using an explicitly named EFI directory.

There is far too much voodoo advice about EFI.


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#40 2011-11-20 21:11:03

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

FYI, added a more complete post install section and visudo/sudoers scripted config. Anyone interested should now be able to use this for an almost complete Arch install from soup to nuts, given per machine customizations.


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#41 2011-11-22 16:21:41

the.ridikulus.rat
Member
From: Indiana, USA
Registered: 2011-10-04
Posts: 765

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

altercation wrote:

I just got rid of the /boot/efi directory entirely. EFI is surprisingly flexible now that I see it as less of a black box. GRUB2 still doesn't properly support non default PREFIX locations, but efibootmgr is more flexible and we can simply use /boot/grub as our EFI path.

Its advisable not to use /boot/grub itself as the UEFI SYSTEM PARTITION, reason being UEFISYS should be FAT32 which does not support symlinks and unix permissions (and other stuff supported by unix filesystems) and /boot/grub might contain symlinks and permissions (remember kernel 3.0 rename transition). Separating /boot/grub and UEFISYS allows user to use a single rootfs (no separate /boot, but still UEFISYS is mounted at /boot/efi, like /media) if they want to do so, or to use any *nix fs for /boot .

Don't use /boot/grub just for the sake of grub-mkconfig. I have sent a patch to grub-devel regarding this https://lists.gnu.org/archive/html/grub … 00111.html .

Last edited by the.ridikulus.rat (2011-11-22 16:25:22)

Offline

#42 2011-11-22 19:14:00

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

the.ridikulus.rat wrote:

Its advisable not to use /boot/grub itself as the UEFI SYSTEM PARTITION, reason being UEFISYS should be FAT32 which does not support symlinks and unix permissions (and other stuff supported by unix filesystems) and /boot/grub might contain symlinks and permissions (remember kernel 3.0 rename transition). Separating /boot/grub and UEFISYS allows user to use a single rootfs (no separate /boot, but still UEFISYS is mounted at /boot/efi, like /media) if they want to do so, or to use any *nix fs for /boot .

I understand your recommendations but have some questions. I did consider the symlink issue (precisely because I at first was considering ways to deal with the grub2 path problems) but my understanding of Grub2 is that it is supposed to be filesystem agnostic (and handles FAT partitions just fine). The symlinked 3.0 transition solution seemed to be a one-off to me and not canonical grub2. Even the Archboot media has Grub2 on a FAT, unless I'm mistaken.

The Grub2 EFI instructions on the wiki also end up with grub inside the EFI path, thus in a FAT partition (efi/grub/grub.cfg, thus /boot/efi/grub/grub.cfg). My solution is actually identical to the wiki recommendation, it just removes the extraneous EFI directory, allows the whole config to move up a path level and uses efibootmgr to point to the right location, keeping grub and efi both happy.

Your second point seems right to me (best practice is keeping /boot/grub and /boot/efi separate), but again on the grub2 arch wiki page it seems to recommend the opposite (it unifies /boot/efi and grub into /boot/efi/grub). I might very well be misreading either the wiki page or your point. I think the wiki page could do with some updating and clarification, perhaps this is another item to consider adding.

So the questions are: Does Grub2 really require a non-fat partition? Is the Arch Wiki Grub2 section accurate and I'm misunderstanding?

Thanks for the pointers, it's good to have someone with EFI experience taking a look at this thread.

the.ridikulus.rat wrote:

Don't use /boot/grub just for the sake of grub-mkconfig. I have sent a patch to grub-devel regarding this https://lists.gnu.org/archive/html/grub … 00111.html .

I actually had come across your patch already (I linked to it from a comment in the script but I think I pulled the actual URL from the comment recently, though my note about there being a patch remains). Anyhow, I remember thinking that the patch had been accepted, is that correct?


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#43 2011-11-23 09:09:34

the.ridikulus.rat
Member
From: Indiana, USA
Registered: 2011-10-04
Posts: 765

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

altercation wrote:

I understand your recommendations but have some questions. I did consider the symlink issue (precisely because I at first was considering ways to deal with the grub2 path problems) but my understanding of Grub2 is that it is supposed to be filesystem agnostic (and handles FAT partitions just fine). The symlinked 3.0 transition solution seemed to be a one-off to me and not canonical grub2. Even the Archboot media has Grub2 on a FAT, unless I'm mistaken.

The kernel rename was just an example. Its better to have /boot with any *nix fs rather than fat32. Yes grub2 is filesystem agnostic but we don't no whether the files in /boot are (as of now I have no problems with kernel and initramfs files in fat32 but cant say about future).

The Grub2 EFI instructions on the wiki also end up with grub inside the EFI path, thus in a FAT partition (efi/grub/grub.cfg, thus /boot/efi/grub/grub.cfg). My solution is actually identical to the wiki recommendation, it just removes the extraneous EFI directory, allows the whole config to move up a path level and uses efibootmgr to point to the right location, keeping grub and efi both happy.

I wrote most of the grub2 UEFI instructions in the wiki and I did not mean /boot/efi/grub/grub.cfg. The actual file structure according to UEFI spec should be as follows:

<UEFISYS_PART>/EFI/<VENDOR_DIR>/<GRUB2_MODULES_CONFIG>  ==>
/boot/efi/ -> efi/ -> grub/ -> grub.cfg or /boot/efi/efi/grub/grub.cfg

UEFI Spec requires bootloaders to be in <UEFISYS_PART>/EFI/<VENDOR_DIR>/ , not <UEFISYS_PART>/<VENDOR_DIR>/ (ie an EFI subdir is required by the spec, no idea why but lets just follow the defined standard).

Also most of the distros out use /boot/efi as the mountpoint for UEFISYS partition. I think this was started by Redhat for Fedora since I think Fedora as the 1st distro to support UEFI boot (http://fedoraproject.org/wiki/Features/EFI). Ubuntu also uses this. Initially I used /efi as the mountpoint in my system but right now I an using /boot/efi.

Now fedora uses "redhat" as vendor dir name and ubuntu uses "ubuntu" itself (not canonical). So in fedora the path is /boot/efi/efi/redhat/grub.cfg and similarly for ubuntu. In arch we simply use grub as vendor name since nobody actually checks these things. Therefore in arch the path is /boot/efi/ -> efi/grub/grub.cfg .

Since you use /boot itself as UEFISYS mountpoint (ie merging both partitions with fat32 as the fs), you have it /boot/ -> efi/grub/grub.cfg . You haven't actually removes any "extraneous EFI directory". Anyway thet directory is required by the spec so lets just leave it at that.

In grub_efi_x86_64-install

--root-directory => UEFISYS mountpoint => /boot/efi
--boot-directory => <UEFISYS_PART>/EFI => denotes the EFI subdir => /boot/efi/efi
--bootloader-id => vendor dir name => redhat or ubuntu or archlinux or grub (which we use) => finally /boot/efi/efi/{redhat,ubuntu,archlinux,grub}

Now you might ask why should we use both --root-dir and --boot-dir since any one option is enough. But grub-install is platform independent and in case of grub2-uefi both options are required for --bootloader-id (3rd option) to work. I talked about this at #grub irc and grub-install may go for a revamp after the next stable release (1.99 is actually considered more stable than grub-legacy 0.97).

If you give

# grub_efi_x86_64-install --root-directory=/boot/efi --bootloader-id=grub2

It will setup grub.efi in /boot/efi/boot/grub/grub.efi .

If you give

# grub_efi_x86_64-install --boot-directory=/boot/efi/efi --bootloader-id=grub2_2345

It will setup grub.efi in /boot/efi/efi/grub/grub.efi . (bootloader-id ignored)

Your second point seems right to me (best practice is keeping /boot/grub and /boot/efi separate), but again on the grub2 arch wiki page it seems to recommend the opposite (it unifies /boot/efi and grub into /boot/efi/grub). I might very well be misreading either the wiki page or your point. I think the wiki page could do with some updating and clarification, perhaps this is another item to consider adding.

No, /boot/efi/ -> grub/grub.cfg is not the recommended path as that violates the spec (no EFI subdir). Either /boot/efi/ -> efi/grub/grub.cfg or /boot/ -> efi/grub/grub.cfg (i recommend the former).

So the questions are: Does Grub2 really require a non-fat partition? Is the Arch Wiki Grub2 section accurate and I'm misunderstanding?

No, grub2 does not care about fat or non-fat fs. But grub.efi should be accesible by the UEFI firmware and that is possible only if grub.efi with its modules and its config (grub.cfg) exist in UEFISYS partition (which according to spec should be fat32 fs). I am not sure why they chose fat32 as the UEFISYS filesystem which is pretty stupid considering the fact that it is highly prone to data and metadata corruption.

the.ridikulus.rat wrote:

Don't use /boot/grub just for the sake of grub-mkconfig. I have sent a patch to grub-devel regarding this https://lists.gnu.org/archive/html/grub … 00111.html .

I actually had come across your patch already (I linked to it from a comment in the script but I think I pulled the actual URL from the comment recently, though my note about there being a patch remains). Anyhow, I remember thinking that the patch had been accepted, is that correct?

The first patch i sent added a -p or --prefix option to be used like

# grub-mkconfig -p /boot/efi/efi/grub2_2345 -o /boot/efi/efi/grub2_2345/grub.cfg

But that patch was rejected. The devs didn't like the --prefix option. So modified it to be used in a different way. The GRUB_PREFIX option is simply initialized to be /boot/grub without ability to modify it via any option. I simply modified it so that GRUB_PREFIX is set to /booot/grub only if that var is not set previously (patch at https://lists.gnu.org/archive/html/grub … 0C73B4.txt ). In the newer patch the command is

# GRUB_PREFIX="/boot/efi/efi/grub2_2345" grub-mkconfig -o /boot/efi/efi/grub2_2345/grub.cfg

much like you set CFLAGS in ./configure or make command. Both the patches have not yet been accepted but you might see them in grub2-common package

Last edited by the.ridikulus.rat (2011-11-23 09:30:04)

Offline

#44 2011-11-23 09:13:41

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

I'm going to work my way through your post but just wanted to say thanks for the incredibly detailed response. EFI is clearly happening but it seems amazingly poorly documented in general. This is some seriously awesome information. I really appreciate the time you've taken to respond like this.

You get some sort of award for forum awesomeness, thanks!

I'd love to have an Arch conference and have you present on this stuff.


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#45 2011-11-27 17:17:32

beta990
Member
Registered: 2011-07-10
Posts: 174

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

Thanks for your script, works perfect. Hope you can keep it up-to-date. smile

Now have UEFI Arch + Windows 7 in dual boot.

Solution if Windows 7 dual boot not working after installing Arch, plug-in your uefi ready  Windows 7 usb-stick, and recover the boot manager.

Offline

#46 2011-11-27 17:26:05

the.ridikulus.rat
Member
From: Indiana, USA
Registered: 2011-10-04
Posts: 765

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

beta990 wrote:

Thanks for your script, works perfect. Hope you can keep it up-to-date. smile

Now have UEFI Arch + Windows 7 in dual boot.

Solution if Windows 7 dual boot not working after installing Arch, plug-in your uefi ready  Windows 7 usb-stick, and recover the boot manager.

To @beta990 and all other UEFI users: This may not be exactly on topic, but can you please post your system specs (Which Motherboard, firmware (AMI/Phoenix) etc., UEFI specific options you used if any etc.). I (and maybe others) want this info since efibootmgr does not work with some firmware but works with others.

Many Asus and Lenovo systems fail to work with efibootmgr (user reports -  I have not tested this) and they use <UEFISYS>/efi/boot/bootx64.efi which is not the default path according to spec. If everything goes correctly, the "GRUB2" entry in UEFI Boot Manager should launch grub.efi from <UEFISYS>/efi/grub/grub.efi and should not fallback to <UEFISYS>/efi/boot/bootx64.efi .

Having a list of working and non-working systems spec list helps a lot.

Also one other thing to note: Everything about grub2-uefi except efibootmgr step can be done in BIOS boot mode, ie grub2-uefi installation itself can be done in BIOS/Legacy boot mode (upto setting up <UEFISYS>/efi/grub/grub.{efi,cfg} ). Only the efivars module and efibootmgr step require UEFI boot mode.

Offline

#47 2011-11-27 17:46:23

the.ridikulus.rat
Member
From: Indiana, USA
Registered: 2011-10-04
Posts: 765

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

Is there any way to detect whether a system in Apple Mac system or a normal UEFI 2.x system? efibootmgr will brick a Apple Mac system and should not be executed (may be even efivars not be loaded in Apple systems).

Offline

#48 2011-11-28 12:17:57

beta990
Member
Registered: 2011-07-10
Posts: 174

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

@the.ridikulus.rat:

Specs:
Asus P8H67-M Pro v3.0 - Intel H67 - AMI BIOS
Intel Core i2400K
8GB DDR3 RAM
SSD + HDD

Used the script to install, I don't have any experience with UEFI so far.
I have tried the script up to four times to get a successfully dual boot installation.

Now I have four entrance added as boot options: 4x ARCH LINUX and Windows Boot Manager. (Don't know the names for sure)

How can I find the default EFI path? Check if everything is installed correctly?

From what I understand from your previous post, the grub2-efi setup is wrong. (Wrong dir, place, setting..)

Could you please tell me the correct way to install?

Thanks. smile

If you need any info, please let me know. smile

Last edited by beta990 (2011-11-28 13:05:49)

Offline

#49 2011-11-28 23:48:35

altercation
Member
From: Seattle
Registered: 2011-05-15
Posts: 135
Website

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

the.ridikulus.rat wrote:

Is there any way to detect whether a system in Apple Mac system or a normal UEFI 2.x system? efibootmgr will brick a Apple Mac system and should not be executed (may be even efivars not be loaded in Apple systems).

I've got plenty of macs to test on here, but for now I can stick a prominent note in the timeout period, perhaps changing that to a y/n.

To be honest, I really don't recommend running this script as is... it's really meant as a framework for advanced users to modify, so hopefully they will have done their due diligence ahead of any install attempts.

Also, what do you mean by brick? I'm assuming you mean that the efi will fail to locate the apple efi entry and that will need to be reset manually?


Ethan Schoonover
Precision Colors - http://ethanschoonover.com/solarized

Offline

#50 2011-11-29 14:23:12

the.ridikulus.rat
Member
From: Indiana, USA
Registered: 2011-10-04
Posts: 765

Re: "Arch By Hand" UEFI GPT SSD LUKS Install Script

altercation wrote:
the.ridikulus.rat wrote:

Is there any way to detect whether a system in Apple Mac system or a normal UEFI 2.x system? efibootmgr will brick a Apple Mac system and should not be executed (may be even efivars not be loaded in Apple systems).

I've got plenty of macs to test on here, but for now I can stick a prominent note in the timeout period, perhaps changing that to a y/n.

If you have lots of maacs i guess you will be interested in https://bugzilla.redhat.com/show_bug.cgi?id=755093 , https://lists.gnu.org/archive/html/grub … 00123.html and http://bzr.savannah.gnu.org/lh/grub/bra … el/changes (grub2 upstream bzr mactel branch).

Also, what do you mean by brick? I'm assuming you mean that the efi will fail to locate the apple efi entry and that will need to be reset manually?

https://bugs.launchpad.net/efibootmgr/+ … mments=all . I don't know how severe it is since I don't use any Mac (not even PPC ones).

Last edited by the.ridikulus.rat (2011-11-29 14:23:58)

Offline

Board footer

Powered by FluxBB