Bug#989589: Real fix just got merged
I'm the upstream developer, and I've just released version 1.0.8, which incorporates the fixes under discussion. This version also includes a new feature that enables users to correct any partition name that's been corrupted by this bug. -- Rod Smith rodsm...@rodsbooks.com
Bug#847694: Bug #847694
Running refind-install directly would produce more output, which might be helpful; however, I'm 80% sure that this is a result of EFI architecture limitations. Specifically, tools like efibootmgr, upon which the refind-install script (and hence the package installation procedure) depends, work for like architectures only. That is, I would not expect efibootmgr in a 32-bit chroot environment on a 64-bit platform to work. If efibootmgr is installed but doesn't work, then refind-install will fail. Although it would be possible to modify refind-install to work around this limitation, I'm not sure that doing so would be advisable. For context, be aware that refind-install WILL work in a BIOS boot mode, in which efibootmgr also does not work; however, rEFInd will not actually be fully installed in this case. The files will be installed to the ESP using the fallback filename (EFI/BOOT/bootx64.efi), but the EFI NVRAM entries won't be set. This is desirable because there are situations in which you might need to install rEFInd from a BIOS-mode boot -- for instance, if you accidentally installed your OS in BIOS mode rather than in EFI mode. In this case, installing rEFInd to the ESP and then relying on the fallback boot loader filename to boot may work, depending on what else is installed; and even if something else takes precedence, there may be ways to override that or adjust the default in the non-Linux OS. OTOH, I don't see what the point of installing rEFInd from within a 32-bit (i386/IA32/x86) chroot on a 64-bit (AMD64/X64/x86-64) installation would be. By definition, a 64-bit environment is available on the computer, and a non-chroot environment is likely to be better for handling low-level hardware configuration in any event, so why not use it? If you can present a reasonable use case for why installing rEFInd in a chroot environment rather than in the host environment is desirable, then I'll consider adjusting refind-install to handle this situation. Of course, this assumes that my assumption about the cause is correct, too; it could be that something else is going wrong. Even if that's the case, though, the question of why you'd want to install a low-level firmware-interfacing tool from within a chroot environment -- especially one that doesn't match the EFI's bit depth. -- Rod Smith rodsm...@rodsbooks.com
Bug#843000: refind: fails to install on NVMe
On 11/14/2016 05:04 PM, Tianon Gravi wrote: > On 4 November 2016 at 02:34, Bjørn Mork wrote: >> + /bin/efibootmgr -c -l '\EFI\refind\refind_x64.efi' -L 'rEFInd Boot >> Manager' -d /dev/nvme0n1 -p 1 > > I just tested this on a friend's machine which has NVMe and uses > rEFInd and we had to change the "-d" value to be "/dev/nvme0n1p1" > (full path to the partition itself) for the entry to be created > correctly (otherwise "efibootmgr -v" afterwards shows > "HD(1,0,000...000,0x0,0x0)/File(...)" instead of the correct > "HD(1,GPT,xxx...xxx,0x800,0x20)/File(...)", which we got after > adjusting the "-d" path). > > Rod, any ideas for why that might be the case (and how it might be > handled properly in "refind-install")? :/ This is starting to sound like a bug in efibootmgr to me, but I haven't yet had a chance to look into it further. -- Rod Smith Server and Cloud Certification Engineer rod.sm...@canonical.com signature.asc Description: OpenPGP digital signature
Bug#715426: Version 0.10.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/06/2016 05:59 PM, Tianon Gravi wrote: > On 6 April 2016 at 14:23, Tianon Gravi wrote: >> This isn't really as important in the context of Debian, since >> we'll supply a separate "debian/", but it's definitely nice to >> keep them in parity, so I'll go do a re-sync and see where we're >> at! > > dh_install: Cannot find (any matches for) "refind-mkdefault" (tried > in "." and "debian/tmp") dh_install: refind missing files: > refind-mkdefault dh_install: missing files, aborting > > Was this file added after 0.10.2 was cut? Should I be syncing > against 0.10.2's source tree instead of just master? Yes, I added that file after releasing 0.10.2. I'm planning to do a 0.10.3 release soon that will include it. If you want to get this pushed into Debian soon, I could put something together by this weekend; or you could go with 0.10.2 (from the source tarball) and then deal with refind-mkdefault for a subsequent version bump. - -- Rod Smith Server and Cloud Certification Engineer rod.sm...@canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXBZC4AAoJEFgyRI+V0FjmDG8H/iaksACKstwQcOLXxubPFyem C2GZDuybQn35avRghTc5r3y7HpzB96kmCDTTrJmkWcg91ShDD2hiQs7QRwdO9Fsb ZZrn5UeRBYHsJBWPzYtv5X6T8ZFWe5l8IEp+FfH+Oh6YphJN1QVvBeZidrvf58IT 7Qb45cxsnbwsNGdr1LL0IaroKiS9jLpuso42JfEQRWWnRKPX0ROVLLp4x92OEWlI Y3YiwcjY1GeJOc/FX3wZidHQwMlGq+2bRaaSgDa1mjb4+CWEUPCZTVu1s8H6Xwvd XvtbmYmBeXoI8JZUDcuPSi9WJYDdemwNgjjd5Axqvm0sN0nKkySTX2TNykIfazk= =HAkB -END PGP SIGNATURE-
Bug#715426: Bug # 715426: Interested in getting this done
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've made some more packaging changes on my upstream Sourceforge git repository. The debian/copyright file should be in good shape now except for the outstanding question of Secure Boot public keys from some sources. I've received an e-mail from Steve Langasek stating that these keys aren't copyrightable, which is why there's no such claim on the Canonical key; but I'm not sure how to express that in debian/copyright. In a worst-case scenario, we can drop the Microsoft, ALT, and Canonical keys from the Debian package. I've also added some basic debconf support. The package tools should now ask whether to install rEFInd to the ESP when the package is installed or reconfigured. (I've tested this and it works for me.) If somebody else could review this, I'd appreciate it. This could be improved in the future, but for now I think it's a good start. Upstream, I've replaced debian/changelog with the version I use on my PPA. I realize the Debian package will need something else. I need to review how patches to the debian subdirectory are usually handled for situations like this. - -- Rod Smith Server and Cloud Certification Engineer rod.sm...@canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWaJe/AAoJEFgyRI+V0FjmvT0IAJIKXcvQxVns6KXGqAlrveL6 vYo7Vj61enGQjemZuI7C405GCNfv51bKku78kh/hDrhhWxcnTVik5jIa4BD8xkHY z0PkFpAMsUaOeDb35+fr8osV9ISJr/i1nlLxdLNdopA8DhigCwF5Kp+6PyzbafN5 QNosxniowXKKnIXy3aiv/ClLHCWKQ89pgKgWjGgSUZE0b7ZU4Dg95pjeXfKtQydy LdNUQYKngs+11MrLsVIdAnR0ERzXobIVSQz0W2ZH7QhjeTip6HfSj405Z2ebeCYJ 9vw2gdHGwEU44QGIwbVvMIqgJXeOba3UclvVC1Qq0k0McPIb7VgG12GMpNcxd9A= =jbiK -END PGP SIGNATURE-
Bug#715426: Bug # 715426: Interested in getting this done
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/30/2015 05:22 PM, Tianon Gravi wrote:
> On 30 November 2015 at 11:31, Tianon Gravi
> wrote:
>> Oh nice; since it's working in QEMU, I'm personally all for
>> arch-enablement! :D
>
> Hmm, I tried compiling on an arm64 porterbox, and got the
> following:
I think I figured out why this failed: I think you were using an
unmodified 0.10.0 tarball. At the moment, my revisions since that
release, including the ARM64 support, are in the rEFInd git repository
on Sourceforge. An attempt to build on ARM64 from 0.10.0 will of
course fail.
I use a script called mkdistrib (which is in the git repository) to
create my tarballs, binary files, etc. You should be able to run it
yourself like this:
./mkdistrib {version} --nosign
It'll create a directory tree called ../snapshots/{version} and put
files there. It will almost certainly error out on you sooner or
later, but not before it's built a source tarball. Alternatively,
here's my latest snapshot:
http://www.rodsbooks.com/refind-src-0.10.0.7.tar.gz
I've made some changes this evening that should clean up many of the
lintian issues. That said, when I ran lintian, I got a much shorter
list than you did. (I tried both from Ubuntu 14.04 and Debian 8.2.)
What options were you passing to it?
Concerning the errata.js file error, that's part of the Creative
Commons license files. I just tossed the whole contents of the
relevant CC Web page into a directory, but I suppose I can replace
that with plain text or something. I think I saw something about a
Debian page with a bunch of archived licenses, so maybe I'll look for
that
- --
Rod Smith
Server and Cloud Certification Engineer
rod.sm...@canonical.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJWXRYsAAoJEFgyRI+V0Fjm/6EH/Ryhnm9TIFD623Y7j5NXd7/0
NKt75ZUcngV5LDwbKcBWaaGbILv6iOiJxmRvWclg3ZP2DVOOOs0HJDHj0spb3Ibi
ZvCp8igz0dayPkTZ8tu6+TEEmjsXZ8N2dmK7sLXplzAsn1Wx8+SC1tcF2eCfaBlh
bqfcdH0Ad79hljZaBQGKTP7yUcgvSydrZFUNalj53dwG9CkXHCNcdyI9L6Xh9//l
zecLGD8eeRwRuyjejHa2ueWNoII2BlnqbNqRRjgrwbHqa/oeO4XivhclZoGgPHyY
KvKJh8tdAfa6RrV9Tf2baC3niZOHZjMr/DmcXqODlbC2xv2W3tVA32cIox5WPF4=
=gV9B
-END PGP SIGNATURE-
Bug#715426: Bug # 715426: Interested in getting this done
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/30/2015 05:22 PM, Tianon Gravi wrote: > On 30 November 2015 at 11:31, Tianon Gravi > wrote: >> Oh nice; since it's working in QEMU, I'm personally all for >> arch-enablement! :D > > Hmm, I tried compiling on an arm64 porterbox, and got the > following: That's VERY strange > make[3]: Entering directory '/home/tianon/refind/libeg' > /usr/bin/gcc -I. -I./../include -I/usr/include/efi > -I/usr/include/efi/aarch64 -I/usr/include/efi/protocol > -I../include -I../refind -I../libeg -DCONFIG_aarch64 > -D__MAKEWITH_GNUEFI -O2 -fno-strict-aliasing -fno-stack-protector > -fpic -fshort-wchar -mno-red-zone -Wall -c screen.c -o screen.o > gcc: error: unrecognized command line option '-mno-red-zone' > ../Make.common:89: recipe for target 'screen.o' failed What's weird about this is that there are signs of both ARM64 and x86-64 compilation -- "-I/usr/include/efi/aarch64" is obviously ARM64, but "-mno-red-zone" should be added as an option only on x86-64 systems. I tried building a Debian package myself in my QEMU environment and had no problems with it. I tried pushing it up to my testing PPA (https://launchpad.net/~rodsmith/+archive/ubuntu/testing/+packages), but it didn't even try to build for ARM64, since that ability is not enabled by default. I've asked that it be enabled, but I'm not sure how long that will take. > The only changes I've applied over what's in master right now are: > > diff --git a/debian/control b/debian/control index 3c130f3..7ca3fa4 > 100644 --- a/debian/control +++ b/debian/control @@ -10,7 +10,7 @@ > Vcs-Browser: > https://anonscm.debian.org/cgit/collab-maint/refind.git Vcs-Git: > git://anonscm.debian.org/collab-maint/refind.git > > Package: refind -Architecture: amd64 i386 +Architecture: amd64 > arm64 i386 This change should not have been necessary if you were using recent files, since I pushed a similar change up to my git repository a while ago. This makes me wonder if your problem might have been caused by out-of-date files. I've added your change to debian/rules to my own git repository. Could you try again? > So maybe we should hold off on that bit until we're sure it's > working more generically? (unless there's something obvious I > missed O:) ) I'm willing to hold off on ARM64 builds if you continue to have problems. It's not like the world's knocking down my door for ARM64 versions of rEFInd. ;-) - -- Rod Smith Server and Cloud Certification Engineer rod.sm...@canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWXPYgAAoJEFgyRI+V0FjmzuMH+gK/EVKEjAWiMm3oeHck5/7F t3knRDmFPjJDCPErL6t4Co2F36O0/yj8B+NBZ4aRHl/y3z53bt73DCR5iLRnQvWb XsnLmWsAu6fWXdd+Gk5dcIXs7YaWjtF26uWniQkyseki7qhc6WocjAIB0s9bwpEW h5lhJKnL7HstVwl+j+kLQTyt3O0N56JittyU+xIokPOS8F7Zsa8AEJ5Y1A/m9xEq PBxYTbeUQNvBrS4gh4/wGaH1PG2xmZPe3qQvp0um0xxG1aEgNgcouZI4GBHKVDYj 8h5ngCALsiAPAxFXfRk+6ooY7qkSLdN/djM2JJSogbOtVp16qWGGSMNdwvKr98Y= =/D6t -END PGP SIGNATURE-
Bug#715426: Bug # 715426: Interested in getting this done
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2015 12:21 PM, Tianon Gravi wrote: > Control: owner -1 tia...@debian.org > > On Thu, 17 Sep 2015 16:26:35 -0400 "Roderick W. Smith" > wrote: >> I'm rEFInd's upstream maintainer and a Canonical employee, and >> I'm interested in getting this packaged and the bug cleared. > > Hey Roderick! I'm interested in getting this package into the > archive too, so I'd be glad to help out and be the Debian > maintainer, especially with such an obviously engaged upstream. :) > > I've created a repo in collab-maint (will show up at > https://anonscm.debian.org/cgit/collab-maint/refind.git > eventually), and I'm currently working on getting your packaging > ported over so I can evaluate what needs to change for Debian. > It's probably worth taking a look at how "grub" and "lilo" handle > the install stuff so we can mimic. Thanks! FWIW, I made some changes to 0.10.0 to help get the packaging ready, although I realize it's not quite there yet. I need to do another pass through the files to get all the copyright details properly documented and create some patches to get the post-install script doing the right stuff (that is, not installing to the ESP automatically). I was actually looking at the GRUB 2 packaging the other day, but it's VERY complex! I haven't looked at LILO, ELILO, SYSLINUX, or anything else yet. One concern/question I have is how the OS knows which, if any, boot loader should be installed. I'm not sure if this is an issue with Debian, but Ubuntu has a habit of re-installing GRUB if it's removed, which of course is annoying if you're using something else. If there's some approved Debian way of recording what boot loader(s) are in use, we should tie into that. I was planning on doing more work on this packaging issue this weekend, which is a long one in the US because of Thanksgiving. - -- Rod Smith Server and Cloud Certification Engineer rod.sm...@canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJWVfHzAAoJEFgyRI+V0FjmTBwH/jJtL1r+5+Ye5Pg83o7P7amZ /g95pwKuAv04IQX5I3reb2B/qxPWPRlY/fKeaDfOZchav/v04n6Fk1iuMc9iknaI 17XGhQx6s94wlKLEWQCoX0zlqJ3teUSaYdN+nzZd1Nph94HIqjtLEOQ9FK4qGeim dLuVA/zKg/Jp6b0O8qpjXBaGrgOjvLLE1A07QEhUeO2SpWokva6QPUsTeZu/j8HG LREq6jLoC2QEspEqGa+PgYv/yjP94d/zuI/bE7s1BGXvPSeOidbCcoxBvf6DLnp5 Tu/EhheE3DsZzmXB9cff1vLcMHuRSYc5iQ0oh/7rLms3HBjWbJFcTexZeEvXnrA= =EIz6 -END PGP SIGNATURE-
Bug#715426: Bug # 715426: Interested in getting this done
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm rEFInd's upstream maintainer and a Canonical employee, and I'm interested in getting this packaged and the bug cleared. I've done some Debian packaging, and in fact I've created an Ubuntu PPA for rEFInd (see https://launchpad.net/~rodsmith/+archive/ubuntu/refind), so much of the technical work is already done. (I realize there will need to be some changes for a package in Debian's main archive, though, such as a change so that the installation script does not run automatically when the package is installed.) I'm less familiar with the procedures for adding a package to the Debian archives, though. I'm reading up on this, but if somebody would be willing to help guide me through the process, I'd appreciate getting some help. Thanks! - -- Rod Smith Server and Cloud Certification Engineer rod.sm...@canonical.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJV+yH7AAoJEFgyRI+V0FjmyVMH/A94tcfjwi2SJfoNcF2wsYNh 1Y0aoOuJXwQqJ76WITpIaJHb7dzSPFg/63LlI2c3wXNMFVg/mlJWwux3SkM+Tc1v ibudZ/nO3C4iHw/+roMp/VBFXqjgaAUOiQwQqFhH0guQTZjECNUTJbwMK3/ileqh qoi+5W9ih+ETg0I3GvCVcP8v+/36UcSosJsgzT10x2QRHe4S2iGxGBMui5QAJaJ+ TXdIuARG7d2nZ12cZ1OvtBDe4kAdWfpDaQZhrX7A4RLIXWl/9TeYvTy0afu2+fva b7gRht3TdjDXUU1yV+rev9BYP3r1jR4pLDCymAnb4tNeKlCTYv8UTsR7yh9CzYY= =1fEL -END PGP SIGNATURE-
