Arch & UEFI [Was: Bug on missing staging modules rpm]

Alonzo Cuellar mariachiac at
Sat Jul 23 07:36:48 EDT 2016

Hello Janina,

Sorry for the long responce again.


bootctl install coppies the needed files in /boot/loader and /boot/EFI. 
It also adds an entry in the efi menu to boot the kernel.

the file

/boot/loader/entries/arch.conf tells the system to simply boot the 
kernel as you described previously in one of your messages.

blkid -s PARTUUID -o value/dev/sdxx will get your PARTUUID. This should be the PARTUUID of your 
root partition which for me is /dev/sda2. /dev/sda1 = EFI and is mounted 
on /boot /dev/sda2 = my root partition and is the partition you want to 
get the PARTUUID value /dev/sda3 = home The partition table has to be in 
gpt. The ESP (EFI system Partition) is in fat32 I've not used 
"efibootmgr" so I can not currently comment on that. It took me a while 
to get an EFI system working a few years ago. Now that it works... Its 
probably the easiest way of booting the system. For me anyways. Note- 
You will need to have secure boot turned off for Arch Linux. You can 
have the system installed successfully. However, if you have secure boot 
enabled Arch will not boot. I hope this clears up most things. Alonzo

On 07/20/2016 03:01 PM, Janina Sajka wrote:
> Hi Again,
> A couple specific questions below ...
> Alonzo Cuellar writes:
>> ...
>> After that I just configure /boot/loader/entries/arch.conf
>> title   Arch Linux
>> linux   /vmlinuz-linux
>> initrd  /intel-ucode.img
> I didn't have this entry, but I do see the file in the directory. So, I
> added it as you have it. But, I'm curious. What does it do?
>> initrd  /initramfs-linux.img
>> options root=PARTUUID=d98f4878-0b54-4f26-b036-8c5eea7b581f rw
>> PARTUUID is found with
>> blkid -s PARTUUID -o value /dev/ where sdxx is your root partition (not your
>> efi partition.)
> This may be my problem, an incorrect identifier. I've seen this language
> in the docs and was confused by it. At first I took "root" to mean /, as
> in the root of the file system. But, I now think that's not what's meant.
> If I google for "What is PARTUUID," I find guidance that says it's a GPT
> value. So, I surmise maybe it's the same as what is listed by gdisk as
> the GUID.
> If I do "efibootmgr -v" I get an incorrect value in the output, if
> indeed this should be listing the GUID:
> BootCurrent: 0008
> Timeout: 9 seconds
> BootOrder: 0001,0008
> Boot0001* Linux Boot Manager
> HD(1,GPT,a95c2ac4-a6b7-4191-9c2a-34b694a39d08,0x800,0x64000)/File(\EFI\systemd\systemd-bootx64.efi)
> Boot0008* UEFI: SMI USB DISK 1100
> PciRoot(0x0)/Pci(0x14,0x0)/USB(1,0)/HD(1,MBR,0x82,0xac,0x14000)AMBO
> So, the value I had in my arch.conf on last boot was incorrect. I have
> now corrected it. Should I now try rebooting? Is the above report a
> reflection of what was ound on the last boot, and thus explains the
> error I got from bootctl?
> Seems it's worth a try, but I do so hate putting the chroot environs
> together every time the boot fails. And, the USB stick has sometimes not
> auto booted, as the above order suggests it would. I have also done some
> other work to clear out some of the intervening, nonfunction
> definitions, which is why the USB is listed as 0008. I presume that will
> get renumbered on next boot as well?
> PS: I was unable to get anything useful from the blkid syntax you
> provided. Maybe I did it wrong?
> Janina
>> I hope this helps,
>> Alonzo
>> On 07/19/2016 04:37 PM, Janina Sajka wrote:
>>> Hi, All:
>>> I have had a bug filed against the lack of rpms for staging modules in
>>> the rpmfusion Fedora repositories. I will not be updating this bug. In
>>> fact, the lack of staging support in Fedora has caused me to move to
>>> Arch Linux--assuming I'll figure out how to get Arch to boot on my
>>> desktop--but that's another story.
>>> I'm just letting you all know, as someone should keep after rpmfusion,
>>> or maybe even offer to take over that package. I have not felt it
>>> something I wanted to take on.
>>> Janina
>>> RPM Fusion Bugzilla writes:
>>>> --- Comment #2 from Emmanuel Seyman <emmanuel at> 2016-07-19 23:01:04 CEST ---
>>>> Fedora 22 has been EOL-ed and RPMFusion will no longer be releasing updates for
>>>> this version of Fedora. This bug will be set to RESOLVED:EXPIRED at the end of
>>>> the week to reflect this.
>>>> If the problem persists after upgrading to the latest version of Fedora, please
>>>> update the version field of this bug (and re-open it if it has been closed).
>>>> -- 
>>>> Configure bugmail:
>>>> ------- You are receiving this mail because: -------
>>>> You are on the CC list for the bug.
>>>> You reported the bug.
>> _______________________________________________
>> Speakup mailing list
>> Speakup at

More information about the Speakup mailing list