Package: shim-signed
Version: 1.36+15.4-5
Severity: wishlist
Currently, if dkms is installed, shim-signed prompts to disable
kernel/module verification on next boot on some trigger events - to
ensure the system will successfully boot (something, not necessarily
untampered with) after a kernel upgr
Package: shim-signed
Version: 1+2.04+17
When upgrading a bullseye installation on a machine with dkms
installed, an update to shim-signed posted the following pop-up for me
twice:
---
UEFI Secure Boot is not compatible with the use of third-party drivers.
The system will assist you in toggling UE
On Wed, Apr 17, 2019 at 07:32:34AM +0100, Colin Watson wrote:
> On Wed, Apr 17, 2019 at 08:04:57AM +0200, Heinrich Schuchardt wrote:
> > Since this commit a51f953f4ee8 ("mkimage: Align efi sections on 4k
> > boundary") grubarm.efi crashes.
> >
> > Hence I suggest to revert this patch for when buil
Package: grub2
Severity: wishlist
Some arm64 laptops/tablets ship with UEFI firmware that require the code
offset to be aligned to EFI_PAGE_SIZE, presumably in order to be able to
enforce no-execute settings for the PE/COFF header itself.
The following (minimal) patch set sent to grub-devel (and
On Wed, Dec 19, 2018 at 12:15:02AM +0100, Heinrich Schuchardt wrote:
> I have reinstalled grub-efi-arm 2.02+dfsg1-9.
>
> With my current U-Boot and a custom built the 4.18.20 kernel I am able
> to boot.
>
> The stock Debian kernel does not boot.
>
> What it takes is a U-Boot v2018.11 with these
Package: grub2
Severity: important
Two major aspects of grub initrd handling on arm* have been addressed
upstream, but are not part of any release:
- Adhering to the initrd/initramfs placement rules
- Ensuring fdt address/size cells are set to 64-bit
The former can prevent booting a system with l
Package: build-essential
Severity: wishlist
I have migrated to mainly using arm64 platforms for my daily work, but
some of it I also need to test/validate for x86 platforms.
This would be a lot smoother if I had an x86_64-linux-gnu- toolchain
packaged as well.
X-Debbugs-CC: glik...@secretlab.ca
Please don't ship dtb files at all, including the kernel images.
If firmware does not come with hardware description, that is a
shortcoming of the firmware. If a newer kernel cannot be booted with
an existing device tree, then that is a bug and the kernel should
Package: grub2
Version: 2.02~beta3-5
The stretch arm64 build of grub lacks the following commit (which
happened after the -beta3 release):
http://git.savannah.gnu.org/cgit/grub.git/commit/util/grub-mknetdir.c?id=0d663b50b9abf830fd10de384606a0632a605b77
This means that grub-mknetdir fails silently
Package: linux-image-arm64
Version: 4.9+78
Severity: wishlist
Linux commit 9822504c1, included in v4.7, introduced EFI framebuffer
support on arm/arm64.
The Debian arm64 kernel config currently explicitly sets CONFIG_FB to
'm', overriding the defconfig 'y'. Since CONFIG_FB_EFI is "depends on
(FB
X-Debbugs-CC: ard.biesheu...@linaro.org
On Sun, Aug 21, 2016 at 02:46:06PM +0100, Ben Hutchings wrote:
> > > I seem to remember that AArch64 has the ill-advised rule that VA bits
> > > outside the range of the current page table format are ignored, so
> > > presumably you're concerned that the cod
X-Debbugs-CC: ard.biesheu...@linaro.org
On Sun, Aug 21, 2016 at 03:04:02PM +0100, Ian Campbell wrote:
> On Sun, 2016-08-21 at 11:42 +0100, Leif Lindholm wrote:
> >
> > You're not wrong, but unfortunately the ability to write semi-portable
> > code left the pla
On Sun, Aug 21, 2016 at 01:11:15AM +0100, Ben Hutchings wrote:
> > > > I think this would be opening up a real can of worms. Not all sizes
> > > > are supported by the architecture, and only certain VA_BITS/pagesize
> > > > combinations work in the kernel.
> > > >
> > > > We could switch to 42-bit
On Fri, Aug 19, 2016 at 12:50:49PM +0100, Ben Hutchings wrote:
> >> > > > everything using mozilla-js).
> >> [...]
> >>
> >> Could we possibly work around that by reducing
> >> CONFIG_ARCH_MMAP_RND_BITS_MAX? (That's not directly configurable; it
> >> requires patching arch/arm64/Kconfig.)
> >
> >
On Fri, Aug 19, 2016 at 02:04:07AM +0100, Ben Hutchings wrote:
> > > > So please enable CONFIG_ARM64_VA_BITS_48 for arm64 kernels.
> > > >
> > > > Note: this change _will_ cause breakage in certain userland software
> > > > making non-portable assumptions about available of top address bits
> > >
Package: linux
Version: 4.6.4-1
X-Debbugs-CC: st...@einval.com, woo...@wookware.org, zheng...@linaro.org
Upstream commit 211102d85 ("arm64: defconfig: enable 48-bit virtual
addresses") changed the default configuration for arm64 to be 48-bit
VA (CONFIG_ARM64_VA_BITS_48). This is required in order
Package: grub2
Version: 2.02~beta2-36
GRUB's efidisk support does not respect the buffer alignment specified
by the UEFI block io protocol. This causes complete disk i/o failure
on platforms where this actually matters - such as with the built in
SATA controller on the ARM Juno development platfor
On Fri, Dec 19, 2014 at 04:35:51PM +0100, Michael Biebl wrote:
> > Could we build systemd without --disable-efi, please?
>
> It's probably to late to do that for jessie unless there is some major
> breakage caused by that for UEFI systems (which I don't know, not being
> familiar with UEFI).
Well
Package: systemd
Severity: normal
The efivarfs kernel module is built for all UEFI-capable platforms
(i386, amd64, arm64), but since systemd is build with --disable-efi,
the filesystem is not mounted at boot-time on
/sys/firmware/efi/efivars.
This makes the efivars package (used by commands like
*grumble, accidental send*
On Thu, Dec 18, 2014 at 08:08:31PM +, Leif Lindholm wrote:
> > > > (I don't have an x86 EFI system available to poke around and answer
> > > > these for myself).
> > > >
> > > > I'm wonder
On Thu, Dec 18, 2014 at 06:35:25PM +, Ian Campbell wrote:
> > > Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
> > > pstore is, so sorry if this is a silly question).
> >
> > I am actually not concerned about pstore itself, but rather by the
> > lack of similarity betwee
On Wed, Dec 17, 2014 at 02:57:17PM +, Ian Campbell wrote:
> > Could we enable CONFIG_PSTORE for arm64 as well, please?
>
> Is PSTORE (going to be) a thing on arm64? (I'm not entirely sure what
> pstore is, so sorry if this is a silly question).
I am actually not concerned about pstore itself,
Tags: patch
The attached patch restricts the dialog to i386/amd64 platforms, and
additionally enables to EFI System Partition size check for all
platforms (where UEFI had been identified as present).
0001-UEFI-partitioning-fixes-for-non-x86.patch
Description: Binary data
Package: partman-efi
Severity: wishlist
When attempting to install Jessie (daily snapshot from today) on
arm64, with an already partitioned disk without an EFI System
Partition, the following dialogue appears:
---
│ This machine's firmware has started the installer in UEFI mode but it │
│ look
Package: src:linux
Severity: normal
X-Debbugs-CC: i...@debian.org
I noticed efivars was being automatically loaded on boot on my
installed amd64 Jessie, but not on my arm64 Jessie. The
installer/rescue image automatically loads it for both.
Turns out on amd64, efivars is being pulled in as a depen
X-Debbugs-CC: i...@debian.org
Package: src:linux
Version: 3.16.7
Severity: wishlist
Linux 3.17 gained support for using a device-tree provided default
console, from the ePAPR 1.1 'stdout-path' property. This removes the
need for explicitly passing a console= parameter to pick the
appropriate conso
Package: dmidecode
Severity: wishlist
dmidecode is today enabled for armhf, ia64, i386 and amd64, but arm64
UEFI platforms also suppose SMBIOS. Could the package be enabled for
arm64 also? It builds cleanly.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
Package: lshw
Severity: minor
lshw-common.patch adds new entries for PCIID_PATH and USBID_PATH, but
rather than replacing existing entries, it adds duplicate ones,
causing build warnings:
pci.cc:23:0: warning: "PCIID_PATH" redefined
#define PCIID_PATH
DATADIR"/pci.ids:/usr/share/lshw-common/pci.
Upstream ticket: http://www.ezix.org/project/ticket/666
(Also this message, unlike previous, sent from correct email account.)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The problem is not actually restricted to arm64 - I would expect it
will also effect all other non-x86 platforms.
The attached patch disables the memory scanning for all architectures
other than i386 and x86_64, and enables it for all UEFI architectures
that provide an SMBIOS entry point address i
Control: severity -1 serious
Control: retitle -1 Segfault if system has FAT partition(s)
I can confirm that this patch resolves the issue for me also.
Changing the title to reflect that it does not affect certain
machines, but rather any system with FAT partition(s), such as any new
pc with a UEF
Package: debian-installer
Version: 20140316
Severity: wishlist
There are many platforms out there with broken UEFI implementations.
It would be useful to in the UEFI installer have a way of instructing
the installer to place GRUB in the "removable media loader path" (as
defined by the UEFI specifi
Package: google-perftools
Version: all
Severity: wishlist
The google-perftools packages are currently built explicitly only for
i386, amd64 and powerpc,
but the current source code (in wheezy) actually contains full support
for both armel and armhf.
Could these targets be added please?
--
To UN
Package: tbb
Version: all
Severity: wishlist
The tbb packages are currently not built for armhf, as the upstream version
does not support it.
Patches to enable support are available at
https://wiki.linaro.org/OfficeofCTO/ThreadingBuildingBlocks
Until this support has been included upstream, could
Installed from the 30th of July 2012 DVD ISO.
Same workaround was successful - drop to a shell, manually copy firmware
across and reload modules.
35 matches
Mail list logo
