[arch-general] Fwd: [arch-dev-public] Secure Boot Support
On Tue, Dec 11, 2012 at 3:15 PM, Thomas Bächler wrote: > Am 10.12.2012 17:21, schrieb kristof: > >> Could you refer to any documentation about this? Why would the boot > >> loader need to call back into shim? > > > > I'm going off of my correspondence with Matthew Garrett in the comments > > section of a post he wrote concerning the shim. His reply to me when I > > asked what distros who don't use rEFInd or GRUB in their installation > > media (like ours) is as follows(from: > > http://mjg59.dreamwidth.org/20303.html?view=813903&posted=1#cmt813903): > > Just as I thought: Calling back into shim is necessary/useful if you > want your second-stage bootloader to verify kernel signatures. If you > don't do that, you can probably use just about any UEFI bootloader. > > Boot Managers (not bootloaders) like rEFInd and Gummiboot require the kernel to be signed with one of the keys present in the UEFI firmware database, since its finally the firmware that is going to launch the kernel EFISTUB as a normal .efi file, and the firmware won't launch unless the key with which the kernel is signed, is present in the firmware database (not the shim's MOK database, which is independent of firmware key database). Please correct me if I am wrong, but I am not sure even shim's keys might work for EFISTUB. One can create their own keys and enroll that key into the database. More info at http://rodsbooks.com/efi-bootloaders/secureboot.html and http://rodsbooks.com/refind/secureboot.html . > This would be an infinitely nicer solution, if it were not for the fact > > that there aren't any bootloaders available which can insure a > > completely trusted chain of execution. I can manually specify in the > > UEFI to load bootloader X signed with Arch's key but bootloader X, > > unless hardcoded to do so, can't make sure that kernel X and module X > > are signed by the very same key. This leads to arbitrary code execution > > and we all know why this is a bad idea. > > Future bootloaders will probably solve this problem by providing proper > verification of kernel and initramfs. For the moment, all that I would > really _want_ to achieve is to make Arch boot flawlessly on Secure Boot > machines without relying on Secure Boot's "Setup Mode" (meaning disabled > verification, which would in turn make Windows 8 angry). Matthew's shim > seems to make this possible. > > I have a secure-boot capable system ( https://wiki.archlinux.org/index.php/HCL/Firmwares/UEFI#Lenovo_Thinkpad_Edge_E430_3254-DAQ), but have secure-boot disabled for now. I am also dual-booting Windows 8 x64 Pro, and the only message the upgrade assistant showed was that secure boot was disabled in the system when installing. Windows 8 boots perfectly fine with secure boot disabled in UEFI mode. I even have CSM (BIOS compatibilty layer) disabled in the firmware setup. So I suggest asking people to disable or change secure-boot mode to setup mode in their system before installing Arch, instead of using Microsoft signed shim binary etc. Adding further to this, I would prefer if the user generates, signs the uefi apps and the kernels he/she wants to use him/herself, and also manage the keys by themself, instead of creating a central Arch specific secure-boot key or any key from a dev. Regards. Keshav > > >
Re: [arch-general] time zone problem with systemd
On Sat, Aug 18, 2012 at 8:50 AM, Shridhar Daithankar
wrote:
> Hello,
>
> I am having trouble with time on a machine when I boot with systemd. The clock
> is ahead of actual time by the value of time zone offset.
>
> Funny thing is when I boot with initscripts, time is reported correctly.
>
> I have this problem on one machine but other machine works correctly. The only
> difference I can spot is hwclock reports local time, on the machine where time
> is correct.
>
> Whats the magic that I am missing?
>
> with systemd
> ---
> [shridhar@waman ~]$ date
> Sat Aug 18 14:23:16 IST 2012
>
> [shridhar@waman ~]$ cat /etc/timezone
> Asia/Kolkata
>
> [shridhar@waman ~]$ ls -al /etc/localtime
> lrwxrwxrwx 1 root root 32 Aug 11 02:02 /etc/localtime ->
> /usr/share/zoneinfo/Asia/Kolkata
>
> [shridhar@waman ~]$ cat /etc/adjtime
> 0.00 0 0.00
> 0
> UTC
>
> [shridhar@waman ~]$ grep -i hwclock /etc/rc.conf
> DAEMONS=(hwclock syslog-ng dbus network crond @cpufreq @openntpd @dnsmasq
> @sshd @laptop-mode kdm)
>
> [shridhar@waman ~]$ grep -i hardware /etc/rc.conf
>
> [root@waman shridhar]# hwclock
> Sat 18 Aug 2012 02:26:28 PM IST -0.110228 seconds
>
> [root@waman shridhar]# hwclock -u
> Sat 18 Aug 2012 02:29:35 PM IST -0.375925 seconds
> ---
>
> with initscripts
> ---
> [shridhar@waman ~]$ date
> Sat Aug 18 08:44:09 IST 2012
>
> [root@waman shridhar]# hwclock
> Sat 18 Aug 2012 02:33:05 PM IST -0.146140 seconds
>
> [root@waman shridhar]# hwclock -u
> Sat 18 Aug 2012 02:33:10 PM IST -0.438390 seconds
>
> ---
>
>
>
> --
> Regards
> Shridhar
Your problem might be due to RTC (motherboard) clock being in local
time (generally the case if you dual-boot with Windows. Systemd
assumes that RTC is in UTC, but in case of initscripts it can be
configured to be localtime. Hence the time offset with systemd boot.
This is how I changed the clock to UTC and setup the correct time.
1. Boot into Windows and follow
https://wiki.archlinux.org/index.php/Time#UTC_in_Windows . After this
change Windows will no longer touch RTC clock at all, even if NTP is
enabled. From this moment on your RTC will be managed by any Arch.
Even after this change the RTC still remains localtime.
2. Boot into Arch and setup the files
/etc/{timezone,localtime,adjtime} according to your timezone, but with
RTC clock as UTC (very important). RTC as local time does not work
with systemd and may not work sometimes even with initscripts.
3. Run "sudo hwclock --localtime --hctosys". This (temporarily) makes
the system clock the correct time.
4. Synchronise the system (software) clock using NTP. I use chrony as
NTP daemon, but any NTP daemon should do. This is needed even after
step 3.
5. Stop the NTP daemon systemd service.
6. Run "sudo hwclock --utc --systohc". This changes the RTC time to
current UTC time.
7. Start the NTP daemon systemd service.
Regards.
Keshav
PS: Same timezone.
Re: [arch-general] [arch-dev-public] grub/grub2 final
>> On 06/24/2012 10:51 PM, Ronald van Haren wrote: >>> >>> I'd like to move 2.00 to [core] via [testing] when it is released, >>> letting the grub-bios (atm grub2-bios) replace the old grub package. >>> Adding an install message and a news item is probably a good idea at >>> the time. >>> >>> I'll be pushing grub2 rc1 to [testing] in a moment if you want to give >>> it a try. Final 2.00 release should be in one of the next days. >>> GRUB 2.00 released - https://lists.gnu.org/archive/html/grub-devel/2012-06/msg00093.html Regards. Keshav
Re: [arch-general] grub/grub2 final - some questions
On Wed, Jun 27, 2012 at 2:27 PM, mike cloaked wrote: > Subject: Re: [arch-dev-public] grub/grub2 final > On Sun, Jun 24, 2012 at 8:51 PM, Ronald van Haren wrote: > >> I was about to post a similar message... >> >> Anyway, I was planning to drop support of grub1. There has been no >> upstream for a long time and all newer features are patched in or >> require additional patches. I don't see a need to have it in [extra] >> as grub-legacy. No problem uploading it to AUR so people can continue >> to use it if they want, although you need i686 to build it so that >> could be the only reason to keep it in [extra] for a bit... >> >> I've seen no major breakages in grub2 since beta2 iirc. Upstream >> development has been going towards stability in recent betas and I >> would consider it stable at the moment: there were no real bug reports >> in the bugtracker for the last few months. >> >> I'd like to move 2.00 to [core] via [testing] when it is released, >> letting the grub-bios (atm grub2-bios) replace the old grub package. >> Adding an install message and a news item is probably a good idea at >> the time. >> >> I'll be pushing grub2 rc1 to [testing] in a moment if you want to give >> it a try. Final 2.00 release should be in one of the next days. > > I am slightly confused by some of the options that will become > available once grub2 becomes the supported package in [core]. > > For someone who currently has hardware without EFI firmware (or any > choice of switching in the BIOS menus), and boots via BIOS-grub- and > with MBR and conventional partitions with an x86_64 arch system - then > will it still be possible to boot with the only change being to move > from grub to grub2 (using grub2-bios)? I am certainly confused about > how UEFI fits in with that scenario. Would it be the same for someone > running as above with 32 bit packages only? > I assume you are talking about non-UEFI systems which are currently booting via grub-legacy, ie current core/grub or aur/grub-gfx . For such systems, once grub-bios (aka grub2-bios) is installed, the user has to follow https://wiki.archlinux.org/index.php/GRUB#Install_to_440-byte_MBR_boot_code_region to install grub(2)'s boot code in the MBR. Then follow https://wiki.archlinux.org/index.php/GRUB#Generate_GRUB2_BIOS_Config_file to generate grub.cfg . This is in case of BIOS+MBR booting. > For a system based on hardware without EFI so that there is no option > in the "BIOS" to switch from BIOS to EFI is there some magic that > needs to happen for the BIOS to boot and then load UEFI code and > support GPT partitions? > Unless the firmware supports UEFI boot, there is no way to use UEFI boot method. But grub(2) fully supports BIOS-GPT configuration. The need for UEFI in case of GPT is true only in case of Windows. In linux, both grub(2) and syslinux support BIOS-GPT, but in different ways. See https://wiki.archlinux.org/index.php/GUID_Partition_Table#BIOS_systems for more info. You can convert an existing MBR setup to GPT using gdisk https://wiki.archlinux.org/index.php/GUID_Partition_Table#Convert_from_MBR_to_GPT . > Maybe I am the only one who is confused about these linked changes to > BIOS/UEFI grub/grub2 and the system partitioning MBR/GPT? Is there a > good clear link to an explanation of how this all fits together and > what the options will be? > > I guess that in the future hardware will increasingly be purchased > which has UEFI enabled by default (and at some point BIOS will > presumably vanish altogether) with huge hard drive capacities, but at > the moment many systems purchased in the past decade and still in use > are not UEFI based, so the choices available to users need to be clear > as grub2 and new options and code are developed for the boot process. > > Thanks in advance. > Archwiki has very good info on GRUB(2), GPT and UEFI. The GRUB(2) article particularly might seem big and this gives an idea to users that grub(2) is very complex to setup. The article is big because it explains all the possible scenarios/configs in which grub(2) can be installed. But setting up any one scenario is a simple task involving just four steps 1. Partition according to requirements - ie. Post-MBR gap in MBR or bios_grub partition in GPT systems for grub(2) bios booting 2. Install grub-* package (currently grub2-*) as per requirement and run grub-install as per archwiki grub(2) article. This populates /boot/grub and install gurb(2) boot code to the MBR. In short it sets up everything except you config file 3. Run grub-mkconfig or grub-menulst2cfg to generate grub.cfg (menu/config file) 4. Copy additional grub(2) font and/or locale files as detailed in the wiki. Do not get confused with bios boot and uefi boot. UEFI is a totally different beast and has to be tackled differently. Everything I have mentioned in this post is only for an user changing from grub-legacy BIOS-MBR booting to grub(2) BIOS-MBR or BIOS-GPT booting. Regards. Keshav
Re: [arch-general] [arch-dev-public] grub/grub2 final
On Mon, Jun 25, 2012 at 1:34 AM, Ionut Biru wrote: > On 06/24/2012 10:51 PM, Ronald van Haren wrote: >> On Sun, Jun 24, 2012 at 9:19 PM, Tobias Powalowski >> wrote: >>> HI >>> https://lists.gnu.org/archive/html/grub-devel/2012-06/msg00071.html >>> grub2 will hit final status soon, should packages be renamed then? >>> Any plan how to handle this. >>> Imho we move grub-legacy to aur or at least extra then. >>> >>> Thanks >>> greetings >>> tpowa >>> >>> -- >>> Tobias Powalowski >>> Archlinux Developer & Package Maintainer (tpowa) >>> http://www.archlinux.org >>> tp...@archlinux.org >>> >>> >> >> I was about to post a similar message... >> >> Anyway, I was planning to drop support of grub1. There has been no >> upstream for a long time and all newer features are patched in or >> require additional patches. I don't see a need to have it in [extra] >> as grub-legacy. No problem uploading it to AUR so people can continue >> to use it if they want, although you need i686 to build it so that >> could be the only reason to keep it in [extra] for a bit... >> >> I've seen no major breakages in grub2 since beta2 iirc. Upstream >> development has been going towards stability in recent betas and I >> would consider it stable at the moment: there were no real bug reports >> in the bugtracker for the last few months. >> >> I'd like to move 2.00 to [core] via [testing] when it is released, >> letting the grub-bios (atm grub2-bios) replace the old grub package. >> Adding an install message and a news item is probably a good idea at >> the time. >> > > Do not replace grub. Most users won't read the pacman output and the > configuration syntax was changed, resulting in a non booting system. > https://wiki.archlinux.org/index.php/GRUB#Generate_GRUB2_BIOS_Config_file . You can convert menu.lst/grub.conf to grub.cfg using grub-menulst2cfg. But since grub1 files will be removed from /boot/grub, that may lead to non-bootable system, unless the user installs grub2 to the MBR using grub-install. > Let them move to grub-bios. > >> I'll be pushing grub2 rc1 to [testing] in a moment if you want to give >> it a try. Final 2.00 release should be in one of the next days. >> >> Cheers, >> Ronald >> > > > -- > Ionuț > > >
Re: [arch-general] [arch-dev-public] grub/grub2 final
On Mon, Jun 25, 2012 at 3:00 AM, Pierre Schmitz wrote: > Am 24.06.2012 22:54, schrieb Ionut Biru: >> On 06/24/2012 11:37 PM, Ronald van Haren wrote: >>> sorry I meant pkgbase >>> >>> Ronald >>> >> >> it's fine to have pkgbase=grub. > > I fear it's not as grub already has this pkgbase. They have to be > unique and also refer to their name in the svn repo. pacman itself does > not care about pkgbase though. > This can be solved by renaming grub(1) to grub-legacy and current grub2 to grub. - Keshav > -- > Pierre Schmitz, https://pierre-schmitz.com
Re: [arch-general] EFI-Support (Arch on a MacBook Pro)
On Sat, Apr 14, 2012 at 23:50, Arvid Warnecke wrote: > Hi Scott, > > On Fri, Apr 13, 2012 at 02:54:28PM -0400, Scott Lawrence wrote: >> >What I have been wondering about now is, if it will be possible to >> >install Arch without rEFIt and the Mac OS X at all? I read a lot in the >> >wiki pages, but all I found was that if I install Arch only with EFI >> >support I will have to install GRUB2. And on the page about GRUB2 I >> >read, that I will have to bless GRUB2 from OS X... >> > >> >If that is necessary I might keep rEFIt and OS X as it is and only >> >replace the Mint installation with Arch. >> > >> It's my understanding that with linux 3.3, it's possible to get EFI >> to boot straight to linux. I don't know the specifics - I mean to >> give it a stab early this weekend. If I still have a working >> computer afterwords, I'll let you know what happens (provided nobody >> else interjects with something more useful). >> > Thanks, looking forward to it. > > Best regards, > Arvid Just FYI https://bbs.archlinux.org/viewtopic.php?id=136833 http://www.rodsbooks.com/efi-bootloaders/efistub.html https://lkml.org/lkml/2012/3/16/194 rEFInd Boot Manager - better than rEFIt - https://aur.archlinux.org/packages.php?ID=57632 . Related info at http://www.rodsbooks.com/refind/linux.html . Experimental "bless" utility for linux - https://aur.archlinux.org/packages.php?ID=54847 (needs more testing) Regards. Keshav
Re: [arch-general] Grub2
On Wed, Mar 28, 2012 at 13:34, Don deJuan wrote: > On 03/28/2012 01:00 AM, Kirill Churin wrote: >> >> On Wed, Mar 28, 2012 at 1:52 PM, Don deJuan wrote: >>> >>> ok well not obvious to me as they were there and working before grub2's >>> most >>> recent 2 updates that came through. Now no longer, sorry if its just >>> noise >> >> >> You can try to regenerate them: >> mkinitcpio -p linux >> mkinitcpio -p linux-qosmio >> grub-mkconfig -o /boot/grub/grub.cfg >> >> > i did a link to /etc/arch-release and solved the grep message. I ran > mkinitcpio again like you said and still the same in boot. Neither the arch > kernel or mine is generating the fallback vmlinuz. Maybe it is a different > problem in relation to today's I think it was mkinitcpio update. Guess mines > is unrelated to OP. https://bugs.archlinux.org/task/29037?getfile=8444 - Keshav
Re: [arch-general] grub2 efi image files
On Tue, Mar 13, 2012 at 22:24, Carsten Mattner wrote: > On Tue, Mar 13, 2012 at 3:05 PM, Keshav P R > wrote: >> On Tue, Mar 13, 2012 at 19:10, Carsten Mattner >> wrote: >>> Hi, >>> >>> I could swear that some time back some version of archboot media >>> gave me the choice to select grub2-efi-32-bit. >>> >>> Was this dropped? >>> >> >> Yes it was removed wrt booting the iso from 32-bit EFI. But the setup > > Do I have to chroot to the installed partition and install it > from extras? > No. You just have to be connected to net while installing because Archboot will pull the package from the repos and install it for you automatically. > Why not keep it on the medium? > It is not present in the iso because very few systems have 32-bit EFI. Thats also the reason why 32-bit EFI booting support was removed from the iso, so reduce space. >> script still supports installing grub2-efi-i386 if you can download >> the package. > > What is the support, if it's removed? I don't understand that. > The installer script (/arch/setup) supports grub2-efi-i386 installation. But the iso itself will not boot in EFI mode in 32-bit EFI, and the package is not present in the iso (so you need to be connected to net) >>> I've been trying to install arch only (single boot) on a EFI-32 mac. >>> Due to not being able to convinve (bless) rEFIt without having OS X >>> installed to not come up with a delay of >= 20seconds, I wanted to >>> use EFI. >>> >> >> Can you try https://aur.archlinux.org/packages.php?ID=54847 ? > > I can use Apple's bless command, but will try that if Apple's doesn't > work. Don't want to risk bricking the firmware. efibootmgr (and efivars module) may brick the firmware, but i don't think bless or mactel-boot will corrupt it since they modify only at a filesystem level. Regards. Keshav
Re: [arch-general] grub2 efi image files
On Tue, Mar 13, 2012 at 19:10, Carsten Mattner wrote: > Hi, > > I could swear that some time back some version of archboot media > gave me the choice to select grub2-efi-32-bit. > > Was this dropped? > Yes it was removed wrt booting the iso from 32-bit EFI. But the setup script still supports installing grub2-efi-i386 if you can download the package. > > I've been trying to install arch only (single boot) on a EFI-32 mac. > Due to not being able to convinve (bless) rEFIt without having OS X > installed to not come up with a delay of >= 20seconds, I wanted to > use EFI. > Can you try https://aur.archlinux.org/packages.php?ID=54847 ? > The mac has onboard intel i915 graphics which I know to work > out of the box. Would this give me any issues like the nvidia guys > with using EFI? > No idea. Non-Mac UEFI user here (with ATI card). > What is the exact issue I have to be careful about to not brick the > firmware with EFI? I know I shouldn't use efitbootmgr on mac efi. > What else is dangerous? > > Thanks, > > Carsten Regards. Keshav
Re: [arch-general] [arch-dev-public] kernel config change in testing
On Tue, Feb 21, 2012 at 23:08, Tobias Powalowski wrote: > Hi > new kernel in testing has: > https://bugs.archlinux.org/task/25341 > - ext4 manages now ext2/ext3 and ext4 > > Please report if any issues happen, here all went fine on all machines. > I had not to change any config file like fstab or mkinitcpio.conf. > No x86_64 kernel https://www.archlinux.org/packages/testing/x86_64/linux/? Why is x86_64 still treated as a second class citizen? tpowa? Regards. Keshav > greetings > tpowa > > -- > Tobias Powalowski > Archlinux Developer & Package Maintainer (tpowa) > http://www.archlinux.org > tp...@archlinux.org > > > >
Re: [arch-general] How to set grub2 resolution to 1366x768
On Tue, Feb 21, 2012 at 20:18, Bill Sun wrote: > Hi, > > According your posts, should I file a bug report directly to lenovo? Not to Lenovo. To grub2 upstream. > > Regards, > Bill
Re: [arch-general] How to set grub2 resolution to 1366x768
On Tue, Feb 21, 2012 at 08:51, Bill Sun wrote: > Hi, > > @Keshav P R: > I tried: > set gfxmode="1366x768;auto" > It didn't give me a 1366x768 console; instead, grub2 just gave me a > 1024x768 console. > Maybe grub2 does not support non-standard modes. Better to ask in #grub irc. > @Thomas Courbon: > Yes, I just tried the 'auto' parameter, and, indeed, it didn't change > anything. > I just update my BIOS to the latest version---1.2.6, and it didn't > change anything. Maybe It's my BIOS's fault. > > @Ralf Mardorf: > According to `vbeinfo` under grub2, the maximum resolution my laptop (or > my laptop's BIOS, I have no idea about this) supports is 1024x768. > However, in Linux, I got a 1366x768 console by default (without further > configuration). That's why I am thinking about insert some modules into > grub2 and it may give me a proper console resolution. > > Regards, > Bill
Re: [arch-general] How to set grub2 resolution to 1366x768
On Mon, Feb 20, 2012 at 18:13, Bill Sun wrote: > Hi, > > I want to have a 1366x768 resolution for grub2. Unfortunately, `vbeinfo` > shows that my computer doesn't support that resolution (up to > 960x640/1024x768). So, can I load some additional modules for grub2 so > that it can support 1366x786 resolution in my computer? > > I tried to do the following steps in grub2 command line: > 1) insmod 915resolution > 2) 915resolution 5c 1366 786 > After step2, grub2 command line became completely black and > unresponsive. I had to press the power button to force halt my machine. > > System information: > Archlinux x86_64 > grub2-common 1.99 > grub2-bios 1.99 > Thinkpad X220 (with Intel Sandy Bridge CPU graphic card) > > Regards Can you try set gfxmode="1366x768;auto" in grub.cfg? Regards. Keshav
[arch-general] [arch-dev-public] kernel config changes in testing
On Thu, Feb 16, 2012 at 18:09, Tobias Powalowski wrote: > Hi > new kernels in testing have: > - ipv6 builtin https://bugs.archlinux.org/task/27994 > - removed the old framebuffer devices (as wished on mailinglist) > https://bugs.archlinux.org/task/25341 ? and it may be early but 3.3 kernel has CONFIG_EFI_STUB ( http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=291f36325f9f252bd76ef5f603995f37e453fc60;hp=55839d515495e766605d7aaabd9c2758370a8d27 ) which should also be enabled once it is released. Regards. Keshav
Re: [arch-general] Cannot upgrade.
On Tue, Feb 14, 2012 at 23:19, Madhurya Kakati wrote: > Greetings, > The command pacman -Su fails(I ran -Sy separately before this). I last > updated the system day before yesterday. > > $ sudo pacman -Su > :: The following packages should be upgraded first : > pacman > :: Do you want to cancel the current operation > :: and upgrade these packages now? [Y/n] Just say N here and continue. There seems to be some issues with pkg updates and SyncFirst in pacman.conf https://bugs.archlinux.org/task/27214 . > resolving dependencies... > looking for inter-conflicts... > :: gcc-libs and gcc-libs-multilib are in conflict. Remove > gcc-libs-multilib? [y/N] N > error: unresolvable package conflicts detected > error: failed to prepare transaction (conflicting dependencies) > :: gcc-libs and gcc-libs-multilib are in conflict > > Do I have to remove gcc-libs-multilib? > -- > Madhurya Kakati > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments
Re: [arch-general] Unable to upgrade community/rekonq (PGP signature issue)
On Tue, Dec 20, 2011 at 21:27, Peter Lewis wrote: > On Wednesday 21 Dec 2011 01:36:35 Gaetan Bisson wrote: > > [2011-12-20 19:38:19 +0530] Keshav P R: > > > error: rekonq: key "22AD5874F39D989F" is unknown > > > error: key "22AD5874F39D989F" could not be looked up remotely > > I opened a bug about this a couple of days ago: FS#27612. > > > This seems to be Peter Lewis signing with (one of his many) subkeys... > > You're right, it seems to be to do with the use of a subkey. > > > (Not sure why he does that.) > > Heh heh. This basically explains the reason quite well: > > http://wiki.debian.org/subkeys > > I have my master key stored offline, and I hope it will last forever > without > being compromised and I won't have to go around getting my key signed > again. > Also, the subkeys are only stored on a smart-card and, so I'm told, can't > be > taken off it. (I know, call me paranoid...) > > > > Do `gpg --recv-key E19DAA50` (primary ID) to get his key. > > Did this: > > % pacman-key -r 22AD5874F39D989F > > not work for you? I was discussing this problem with Seblu earlier and we > could both just do this, only it wouldn't be imported automatically by > pacman. > > Pete. > I guess this has something to do with using keys.gnupg.net instead of pgp.mit.edu. I had issues with keys.gnupg.net (versy slow dueing initial keyring creation) and came across pgp.mit.edu as an alternative and faster keyserver. I changed the keyserver and tried "pacman -S rekonq" again thinking that would solve the problem but it didn't. I didn't know about subkeys etc. and thats why I started this thread. But manually importing the key using pacman-key after changing the keyserver didn't cross my mind since I thought pacman should obviously do that by itself. Anyway all's well now. Thanks for your help. Regards. Keshav
Re: [arch-general] Unable to upgrade community/rekonq (PGP signature issue)
On Tue, Dec 20, 2011 at 20:25, Gaetan Bisson wrote:
> [2011-12-20 20:19:13 +0530] Keshav P R:
> > There seems to be many new User IDs and Signatures. Should I do
> "pacman-key
> > --refresh-keys" periodically?
>
> Actually, `--refresh-keys` will only update signatures; to get the new
> keys you must either import them from pacman as you install packages
> signed by previously unseen keys, or use an ugly script like that to get
> all new keys at once:
>
> curl https://www.archlinux.org/{developers,trustedusers}/ |
> awk -F\" '(/pgp.mit.edu/) {sub(/.*search=0x/,"");print $1}' |
> xargs sudo pacman-key --recv-keys
>
> --
> Gaetan
>
Now that I have refreshed the list of keys. How should I import them all?
Should I do
# pacman-key --updatedb
or whenever I install a package which is signed with one of the new keys,
will pacman import the key automatically? Sorry I am not used to this
package signing of PGP thingy? Anyway thanks for you help (and for the
"ugly" script). I have updated rekonq and now downloading Qt 4.8 and all
other packages.
Regards.
Keshav
Re: [arch-general] Unable to upgrade community/rekonq (PGP signature issue)
On Tue, Dec 20, 2011 at 20:20, Denis A. Altoé Falqueto < denisfalqu...@gmail.com> wrote: > On Tue, Dec 20, 2011 at 12:08 PM, Keshav P R > wrote: > > Hi all, > > I am unable to upgrade community/rekonq from 0.8.0-1 to 0.8.1-1 > > due to > > > > error: rekonq: key "22AD5874F39D989F" is unknown > > error: key "22AD5874F39D989F" could not be looked up remotely > > error: failed to commit transaction (invalid or corrupted package (PGP > > signature)) > > Errors occurred, no packages were upgraded. > > I've had some issues like that, but retrying the update somehow makes > it download the key. Have you retried the update? > > I retried the update many times and also tried "--recv-keys 22AD5874F39D989F" but both didn't work. - Keshav
Re: [arch-general] Unable to upgrade community/rekonq (PGP signature issue)
On Tue, Dec 20, 2011 at 20:06, Gaetan Bisson wrote: > [2011-12-20 19:38:19 +0530] Keshav P R: > > error: rekonq: key "22AD5874F39D989F" is unknown > > error: key "22AD5874F39D989F" could not be looked up remotely > > This seems to be Peter Lewis signing with (one of his many) subkeys... > (Not sure why he does that.) > > Do `gpg --recv-key E19DAA50` (primary ID) to get his key. > > -- > Gaetan > Thanks. I did # pacman-key --recv-keys E19DAA50 # pacman-key --refresh-keys There seems to be many new User IDs and Signatures. Should I do "pacman-key --refresh-keys" periodically? Regards. Keshav
[arch-general] Unable to upgrade community/rekonq (PGP signature issue)
Hi all, I am unable to upgrade community/rekonq from 0.8.0-1 to 0.8.1-1 due to error: rekonq: key "22AD5874F39D989F" is unknown error: key "22AD5874F39D989F" could not be looked up remotely error: failed to commit transaction (invalid or corrupted package (PGP signature)) Errors occurred, no packages were upgraded. /etc/pacman.d/gnupg/gpg.conf has no-greeting no-permission-warning lock-never # keyserver hkp://keys.gnupg.net keyserver hkp://pgp.mit.edu /etc/pacman.conf has GPGDir = /etc/pacman.d/gnupg/ SigLevel = Optional TrustAll I see that many other users have successfully upgraded this package. Any idea whats wrong? Thanks in advance. Regards. Keshav
Re: [arch-general] [arch-dev-public] [ANNOUNCE] filesystem-2011.12 manual intervention required
On Mon, Dec 19, 2011 at 23:21, Tom Gundersen wrote: > On Mon, Dec 19, 2011 at 6:40 PM, Dave Reisner wrote: > > On Mon, Dec 19, 2011 at 12:38:11PM -0500, Dave Reisner wrote: > >> On Mon, Dec 19, 2011 at 05:57:51PM +0100, Tom Gundersen wrote: > >> > Hi guys, > >> > > >> > We are finalizing the move to libmonut based mount, paving the way for > >> > read-only root, by moving /etc/mtab into the filesystem package. This > >> > used to be a dynamic file generated at boot and updated at runtime, > >> > but as of the last initscripts package it was simply a symlink to > >> > /proc/self/mounts. > >> > > >> > This symlink was created at boot (at the same place the old mtab was > >> > generated), but this turned out to cause a few problems. > >> > > >> > Sadly, moving the symlink to 'filesystem' requires user intervention, > >> > which I will write a news item about. The essential message will be: > >> > > >> > "Please upgrade the filesystem package using 'pacman -Sf filesystem' > >> > in order to overwrite /etc/mtab." > >> > >> I'd prefer to ask people to rm /etc/mtab and -Su, rather than advertise > >> -f (which has been removed in pacman-git, leaving only --force). > >> > >> > Please test and signoff, as I'd like to make the move to core rather > quickly. > >> > > >> > Cheers, > >> > > >> > Tom > > > > Gah.. and of course saying that, and then going and doing it -- the > > missing mtab makes pacman choke on diskspace checking. --force might be > > the easier option here... > > Yeah, I'll make this clear in the news item. --force is always, > always, always wrong. Except for this one time, when it is the only > solution ;-) > > -t > Sorry to interrupt guys but can't this be done in pre_upgrade function in .INSTALL script of the package? Quote: man PKGBUILD pre_install Run right before files are extracted. One argument is passed: new package full version string. pre_upgrade Run right before files are extracted. Two arguments are passed in this order: new package full version string, old package full version string. Regards. Keshav
