On Mon, May 20, 2024 at 04:25:57PM -0700, Quanah Gibson-Mount wrote:
>
> --On Monday, May 20, 2024 3:45 PM -0700 Elliott Mitchell
> wrote:
>
> Side note - I did raise this issue with the rest of the OpenLDAP project,
> and Howard noted:
>
> "DNS names are require
On Mon, May 20, 2024 at 12:46:34PM -0700, Ryan Tandy wrote:
> However, I tested your patch, and I'm not sure it's correct.
>
> If the IPv6 address contains a letter a-f before the first colon, I
> think the code you changed is never reached. On seeing the first
> non-digit, we break the loop
em+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
From: Elliott Mitchell
Date: Sun, 19 May 2024 09:49:36 -0700
Subject: [PATCH] tls: fix handling of numeric IPv6 addre
On Sat, May 18, 2024 at 10:47:55AM +0200, Andreas Metzler wrote:
> On 2024-05-18 Elliott Mitchell wrote:
> > On Sat, May 18, 2024 at 08:16:25AM +0200, Andreas Metzler wrote:
> [...]
>
> >> You seem to argue that it is major problem for a gnutls client to *send*
> >
On Sat, May 18, 2024 at 08:16:25AM +0200, Andreas Metzler wrote:
> On 2024-05-18 Elliott Mitchell wrote:
> > On Sat, May 18, 2024 at 07:40:13AM +0200, Andreas Metzler wrote:
> >> On 2024-05-18 Elliott Mitchell wrote:
> >>> On Sat, May 18, 2024 at 06:55:06A
On Sat, May 18, 2024 at 07:40:13AM +0200, Andreas Metzler wrote:
> On 2024-05-18 Elliott Mitchell wrote:
> > On Sat, May 18, 2024 at 06:55:06AM +0200, Andreas Metzler wrote:
> [...]
> > > > > I notice the `_gnutls_dnsname_is_valid()` function in
> > > >
On Sat, May 18, 2024 at 06:55:06AM +0200, Andreas Metzler wrote:
> On 2024-05-17 Elliott Mitchell wrote:
> > On Thu, May 16, 2024 at 07:06:49PM -0700, Elliott Mitchell wrote:
> > > On Tue, May 14, 2024 at 06:22:09PM +0200, Andreas Metzler wrote:
> [...]
> > > > Co
On Thu, May 16, 2024 at 07:06:49PM -0700, Elliott Mitchell wrote:
> On Tue, May 14, 2024 at 06:22:09PM +0200, Andreas Metzler wrote:
> > On 2024-05-14 Elliott Mitchell wrote:
> > > On Wed, May 01, 2024 at 01:45:00PM +0200, Andreas Metzler wrote:
> > [...]
> > >&
On Tue, May 14, 2024 at 06:22:09PM +0200, Andreas Metzler wrote:
> On 2024-05-14 Elliott Mitchell wrote:
> > On Wed, May 01, 2024 at 01:45:00PM +0200, Andreas Metzler wrote:
> [...]
> >> well you could post the complete output of
> >> gnutls-cli --port 636 fd12:3456:
affects 1070033 nslcd
quit
On Wed, May 01, 2024 at 01:45:00PM +0200, Andreas Metzler wrote:
> On 2024-04-30 Elliott Mitchell wrote:
> > On Tue, Apr 30, 2024 at 05:55:15AM +0200, Andreas Metzler wrote:
> > > On 2024-04-29 Elliott Mitchell wrote:
> [...]
> > &g
On Tue, Apr 30, 2024 at 05:55:15AM +0200, Andreas Metzler wrote:
> On 2024-04-29 Elliott Mitchell wrote:
> > Package: libgnutls30
> > Version: 3.7.9-2+deb12u2
> > Severity: important
>
> > Long story to finding this one. Trying to get LDAP setup on this
> &
Package: libgnutls30
Version: 3.7.9-2+deb12u2
Severity: important
Long story to finding this one. Trying to get LDAP setup on this
network. As a recent deployment it seemed appropriate to use IPv6.
>From `nslcd` on clients I was getting the message:
nslcd[12345]: [1a2b3c] failed to bind to
Package: grub
Version: 2.06-13+deb12u1
>From `dmesg`:
md: kicking non-fresh from array!
This is using MD-RAID1. Appears GRUB is opting to load grub.cfg, kernel
and initial ramdisk off of this device, rather than the still operational
mirror. The result is without manual intervention an older
tags 988477 - moreinfo
found 988477 4.17.2+76-ge1f9cb16e2-1~deb12u1
affects 988477 src:linux
severity 988477 critical
quit
I am also observing #988477 occur. This machine has a AMD Zen 4
processor. The first observation was when motherboard/processor was
swapped out, the older
reassign 810964 src:linux
tags 810964 -moreinfo
affects 810964 src:xen
found 810964 5.10.191-1
found 810964 6.1.52-1
found 810964 6.5.3-1
found 810964 5.10.127-2~bpo10+1
found 810964 6.1.38-4~bpo11+1
found 810964 6.4.4-3~bpo12+1
quit
Upon further investigation, while some part of #810964 may be
On Fri, Aug 18, 2023 at 02:05:31PM -0700, Elliott Mitchell wrote:
> >From reading the available information I suspect Tianocore/EDK2 may have
> tried to move some functionality to a distinct build and neither setup
> quite works. Notably there is now a "OvmfPkg/OvmfXen.dsc"
affects 1050030 src:xen
quit
I'm seeing a similar situation, though instead using FreeBSD/x86 in the
VM.
For FreeBSD the bootloader appears to operate normally, but something
fails quickly after loading the kernel:
Loading kernel...
/boot/kernel/kernel text=0x18aa98 text=0xdfd150 text=0x675154
On Tue, Jul 04, 2023 at 11:56:39PM +0300, Michael Tokarev wrote:
> Out of curiocity, what value is it to boot a xen domU (or qemu) guest in uefi
> mode?
> I mean, bios mode is still recommended for at least commercial virt solutions
> such
> as vmware, and it works significantly faster in qemu
Synthesizing things since I hadn't been copied on previous message...
On Mon Jul 31 18:10:34 BST 2023, zithro wrote:
>
> On 31 Jul 2023 03:39, Elliott Mitchell wrote:
>
> > Presently I hope to convince the Xen core to allow full Python in domain
> > configurati
On Wed, Aug 16, 2023 at 08:57:16AM +0200, Salvatore Bonaccorso wrote:
>
> On Tue, Aug 15, 2023 at 04:13:59PM -0700, Elliott Mitchell wrote:
> > Package: nfs-kernel-server
> > Version: 1:2.6.2-4
> >
> > Hopefully SSIA.
> >
> > `rpc.mountd` has a -N opt
Package: nfs-kernel-server
Version: 1:2.6.2-4
Hopefully SSIA.
`rpc.mountd` has a -N option to disable versions of NFS.
I had been previously using "-N 2", but that is now broken. The error
message was quite non-helpful ("nfsd2" if I recall correctly). Upon
removing "-N 2", luckily NFSv2
Even though there hasn't been any discussion recently, bug #452721 is
very much still of major concern to me.
First issue is how to parse domain configuration files. Reason being a
foo.cfg file might have the configuration 'name = "bar"'. This would
also let the script retrieve the UUID if that
Package: zfsutils-linux
Version: 2.0.3-9+deb11u1
Would the Debian ZFS maintainers be so kind as to remove the GPT creation
bug from zfsutils-linux?
Full details are at: https://github.com/openzfs/zfs/issues/94
The issue is simply zpool's create/replace and other subcommands try to
Package: src:linux
Version: 6.0.3-1~bpo11+1
Severity: wishlist
Looks like someone had the idea of a virtualized HW RNG. Yet looking at
the kernel source, there isn't a single actual implementation. Unless
I'm missing something, having CONFIG_HW_RANDOM_VIRTIO simply wastes
processor time during
On Sun, Apr 16, 2023 at 07:08:03AM +0200, Salvatore Bonaccorso wrote:
> CONFIG_AGP is built-in in Debian, in particular for:
>
> debian/config/alpha/config:CONFIG_AGP=y
> debian/config/amd64/config:CONFIG_AGP=y
> debian/config/hppa/config.parisc64:CONFIG_AGP=y
>
Package: src:linux
Version: 5.10.158+2
Severity: wishlist
Could AGP support be turned into a module for Debian kernels?
I'm tempted to suggest it shouldn't even be built for amd64, but does
seem reasonable for i686 kernels. Given this, module seems to make
sense.
--
(\___(\___(\__
On Tue, Mar 07, 2023 at 01:13:56PM -0800, Elliott Mitchell wrote:
>
> ad15a0a8ca2515d8ac58edfc0bc1d3719219cb77
> x86/time: prevent overflow with high frequency TSCs
Okay, looks like this one had already been grabbed. Sorry for the way
too late alert. Thanks for staying on to
Package: src:xen
Version: 4.17.0+46-gaaf74a532c-1
Severity: important
Two major bugs have shown with the release of new hardware from AMD.
Since the new hardware is likely to become common during the life of
Debian/bookworm, you may wish to grab them early:
>From looking, it doesn't appear necessary to remove the dependency of
QEMU on libxenmiscX.YY to make backports possible. According to DPKG,
multiple versions of libxenmisc can be installed at the same time, so
the issue is simply whether multiple versions of QEMU can be installed
at the same
Package: arcanist
Version: 0~git20200925-1
Severity: grave
If one has one or more commits in /some/repo one can create a
Phabricator diff by running `arc diff $oldver`. If there are are
untracked files in the directory the arcanist client gives the message:
Not a proper In-Reply-To since that message ended up /somewhere/ and I'm
thus going back to the bug DB for this reply.
I guess I'm neutral-ish on Linux versus Mini-OS for doing stub domains
for Debian on Xen. I suspect development on Xen's Mini-OS isn't all that
active. On the flip side due to
X-Debbugs-Cc: pkg-xen-de...@lists.alioth.debian.org
Guess we're finding out where everyone's update windows are. Some though
may report before resolving the issue or somewhat after.
Yet another reproducer of the issue here. I also observed the failure in
Xen's dmesg and confirm the issue
For some time the Linux kernel hasn't guaranteed the order of block
devices. #737564 is a good solution to this issue.
(yeah, suddenly running into devices getting different designations due
to restart)
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (|
Package: src:linux
Version: 5.10.106-1
Between 5.10.103-1 and 5.10.106-1 (image -13) something changed which
reliably causes what used to show as /dev/sda to show as /dev/sdb. Other
block devices plugged into the SCSI subsystem may have swapped around,
but I've yet to untangle the others.
A few
Package: initscripts
Version: 3.02-1
Often /run is mounted with the "nodev" option, at which point doing a
`mknod` "/run/rootdev", then trying to `fsck` that doesn't work as a
fallback. Perhaps "/dev/fsckfallbackdev"?
--
(\___(\___(\__ --=> 8-) EHM <=--
found 1008910 3.02-1
found 1008910 2.96-7+deb11u1
found 1008910 2.93-8
quit
On Mon, Apr 04, 2022 at 12:48:07AM +0200, Thorsten Glaser wrote:
> On Sun, 3 Apr 2022, Elliott Mitchell wrote:
>
> > Perhaps the test should be: "[A-Z][A-Z]*[A-Z][A-Z]=*"?
>
> No, that???s
Package: initscripts
Version: 3.01-1
This is *almost* #677420, but not quite.
The test in /lib/init/mount-functions.sh, _read_fstab() tests for
"LABEL=*|UUID=*" before resorting to `findfs`. Thing is `findfs` has
two other cases it can handle and that test misses those two.
Perhaps the test
Come to think of it, my initial message may have pointed to the root
cause. May very well be `fsck` skips checks on filesystems on USB
devices.
Problem is this behavior is taking precedence over checking filesystems
listed in /etc/fstab. If the root filesystem is located on USB it is
irrelevant
Package: util-linux
Version: 2.36.1-8+devuan2
Severity: important
For some reason on this aarch64 device, the automated filesystem checks
which should be done via `fsck -T -M -A -a -t ext4` are getting skipped.
When trying to run this manually, no error messages of any sort was
observed.
During
On Sat, Mar 26, 2022 at 05:38:21PM +0100, Jonas Smedegaard wrote:
> Quoting Elliott Mitchell (2022-03-26 16:35:53)
> > Has been reported upstream:
> > https://github.com/Kozea/Radicale/issues/1183
> >
> > Upstream has been completely unresponsive. No fix is available
Package: radicale
Version: 3.0.6-3
Severity: important
Has been reported upstream:
https://github.com/Kozea/Radicale/issues/1183
Upstream has been completely unresponsive. No fix is available. Their
changelog fails to mentions any fix for this. Reputedly upstream plans
to force upgrades and
145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>From b7477e7fab01b48b663d3e89e4f4c7bd352c8b7e Mon Sep 17 00:00:00 2001
From: Elliott Mitchell
Date: Sat, 26 Feb 2022 17:15:46 -0800
Subject: [PATCH]
On Fri, Feb 25, 2022 at 06:40:23PM +0100, Hans van Kranenburg wrote:
>
> However, I hope you understand that there's no way we can help when you
> use something else than the actual packages in Debian, do not provide
> any error messages seen, and describe what you see instead as "it felt
>
found 466064 2:1.20.11-1+deb11u1
quit
I almost wonder whether I'm seeing a distinct bug since #466064 is so
old. -novtswitch continues(?) to be problematic. Current version the
option doesn't work.
Not switching VTs is rather valuable for having multiple X-servers
started by init and running
On Mon, Jan 03, 2022 at 05:17:19PM +, Steve McIntyre wrote:
>
> On Mon, Jan 03, 2022 at 08:52:48AM -0800, Elliott Mitchell wrote:
> >
> arm64 machines categorically do *not* have any capability to run this
> way. It has never been a thing. Instead, systems running GRU
Package: src:xen
Version: 4.16.0-1~exp1
I'm guilty of pulling in later Xen source and building it based on the
experimental 4.16 packaging. As such this may actually only be an issue
for a package version beyond 4.16.0.
I'm uncertain which it is, but xen-utils-4.16 appears to need an update
to
Nothing further has been heard. Was bug #989560 resolved by updating to
the GRUB 2.04 packages? Possibly as part of upgrading to bullseye?
The provided information looks like what one might expect from trying to
load Xen on ARM via GRUB 2.02. As such I'm left suspecting this was
resolved by
On Mon, Jan 03, 2022 at 05:17:19PM +, Steve McIntyre wrote:
>
> On Mon, Jan 03, 2022 at 08:52:48AM -0800, Elliott Mitchell wrote:
> >On Mon, Jan 03, 2022 at 02:35:48PM +, Steve McIntyre wrote:
> >>
> >> What you're asking for here won't work;
On Mon, Jan 03, 2022 at 02:35:48PM +, Steve McIntyre wrote:
>
> On Sun, Dec 26, 2021 at 05:12:38PM -0800, Elliott Mitchell wrote:
> >
> >Hopefully the subject tells the tale. Due to some odd hardware, I need
> >to force `grub-install` to install the EFI version of G
Package: grub2-common
Version: 2.04-20
Severity: important
Hopefully the subject tells the tale. Due to some odd hardware, I need
to force `grub-install` to install the EFI version of GRUB into the
MBR/boot area gap. Unfortunately the documentation suggest none of
`grub-install`'s options can
Having finally gotten to test this, the issue does NOT effect 5.10.70-1.
So far I've only gotten to try reboot, but that went fine.
Might have been an ACPI or Xen mismerge into 4.19. Alas this may simply
disappear into history.
--
(\___(\___(\__ --=> 8-) EHM <=--
On Thu, Nov 18, 2021 at 07:26:50PM +0100, Jonas Smedegaard wrote:
>
> Quoting Elliott Mitchell (2021-11-18 16:45:58)
> > Appears the documentation for `start-stop-daemon` is misleading or
> > wrong, and the "--exec" option is needed if "--startas" is given
Package: radicale
Version: 3.0.6-3
Severity: important
The init script `/etc/init.d/radicale` which is included with the 3.0.6-3
package failed to start Radicale for me.
Radicale's "--daemon" option was apparently removed with 3.0.6-3.
Attempting to use the "--daemon" option resulted in an
Yet another person who has noticed this. Highlighting the current date
is rather handy for interactive use.
The basis of #904839 is incorrect. Without that change `cal` uses
isatty() to determine whether output is a terminal. If not a terminal,
highlighting is disabled (compare `ncal -b` and
Package: pv-grub-menu
Version: 1.3
SSIA. On ARM(64) systems typical Linux kernel packages Recommends
"flash-kernel", but for VMs this is quite undesireable. As such I would
suggest pv-grub-menu should be marked as providing flash-kernel on
ARM(64).
(I suspect this is harmless on other
Package: grub-xen-host
Version: 2.04-20
I'm unsure which versions from stable were tried, but at a minimum
2.02+dfsg1-20+deb10u4 was and also had this issue. I'm also unsure
whether this is actually a GRUB bug versus a Linux kernel bug.
When booting in x86 PVH mode the Linux kernel fails to
Package: linux-source-5.10
Version: 5.10.70-1
SSIA. Debian's 5.10 configuration will NOT build without the "dwarves"
package (`pahole`). In light of this some package, likely
linux-source-5.10 should recommend "dwarves".
--
(\___(\___(\__ --=> 8-) EHM <=--
On Tue, Sep 28, 2021 at 11:39:49PM +0200, Diederik de Haas wrote:
> On Tuesday, 28 September 2021 13:41:57 CEST Andy Smith wrote:
> >
> > > Could the domain ID be used for that?
> >
> > I don't like it because it only says how recent a domain was
> > started relative to others, not any intention
On Mon, Sep 27, 2021 at 05:13:04PM +, Andy Smith wrote:
> On Sun, Sep 26, 2021 at 08:07:58PM -0700, Elliott Mitchell wrote:
> > During a full downtime when all VMs were fully shut down, this effect
> > can be achieved by including numbers in the filename. Say
> > /et
I'm surprised #452721 is tagged moreinfo since it seems simple, but that
may depend on installation capability.
Note, I am not the original reporter, so I might actually be observing
something distinct. I doubt this, but I cannot be certain.
Issue is this, a hypervisor machine could have tens
found 939186 4.14.2+25-gb6a8c4f72d-2
found 939186 4.14.3-1
tags 939186 upstream
quit
Upon a bit more experimentation, seems my minimal example had become too
minimal. Bring in the less minimal example and things explode again.
Finally setup an appropriate downtime window and it reproduced.
Control: found 939186 4.11.4+107-gef32c7afa2-1
Certainly reproduced with 4.11. Most recently I tried 4.14 and it
*didn't* occur.
Problem is I've got two guesses:
First, system had most VMs shutdown for some experimentation. Could be
having >50% of memory allocated is needed for this to occur.
On Tue, Sep 21, 2021 at 06:33:20AM -0400, Chuck Zmudzinski wrote:
> I presume you are suggesting I try booting 4.19.181-1 on the
> current version of Xen-4.14 for bullseye as a dom0. I am not
> inclined to try it until an official Debian developer endorses
> your opinion that the bug I am seeing
On Mon, Sep 20, 2021 at 10:23:39PM -0400, Chuck Zmudzinski wrote:
>
> On 9/20/21 7:39 PM, Diederik de Haas wrote:
> > On dinsdag 21 september 2021 01:15:15 CEST Elliott Mitchell wrote:
> >> Merely having the path is a sufficiently strong indicator for me to
> >>
On Mon, Sep 20, 2021 at 06:29:49PM -0400, Chuck Zmudzinski wrote:
> On 9/20/21 1:43 PM, Chuck Zmudzinski wrote:
> >
> > On 9/20/21 12:27 AM, Elliott Mitchell wrote:
> >> On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> >>
> >>>
On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> xen hypervisor version: 4.14.2+25-gb6a8c4f72d-2, amd64
>
> linux kernel version: 5.10.46-4 (the current amd64 kernel
> for bullseye)
>
> Boot system: EFI, not using secure boot, booting xen
> hypervisor and dom0 bullseye with
On Sun, Sep 19, 2021 at 01:05:56AM -0400, Chuck Zmudzinski wrote:
> On Sat, 11 Sep 2021 13:29:12 +0200 Salvatore Bonaccorso
> wrote:
> >
> > On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
> > > An experiment lead to a potential alternat
On Sat, Sep 11, 2021 at 01:29:12PM +0200, Salvatore Bonaccorso wrote:
> On Fri, Sep 10, 2021 at 06:47:12PM -0700, Elliott Mitchell wrote:
> > An experiment lead to a potential alternative explanation for #991967.
> > The issue may be ACPI (non-UEFI) powerdown/reset was broken at
An experiment lead to a potential alternative explanation for #991967.
The issue may be ACPI (non-UEFI) powerdown/reset was broken at
4.19.194-3. Presence of Xen on the system may be unrelated.
Failing that, it could be Xen and non-UEFI systems are effected. (Xen
was tried on a UEFI system and
Package: src:linux
Version: 4.19.194-3
Control: affects -1 src:xen
SSIA. Previous versions of 4.19 had no issues (4.19.181-1 according to
notes), but this cropped up with 4.19.194-3 (-1 and -2 weren't tested).
When a Xen domain 0 tries to reboot or powerdown the computer, it hangs
with the
I rate #989560 as a grub-common bug, *not* a xen-hypervisor-common bug.
As you've noticed, the problem is with the file /etc/grub.d/20_linux_xen,
which is part of grub-common, not xen-hypervisor-common.
A working grub.cfg will be generated by the version of the file from
GRUB 2.04. If you can
On Thu, Jan 07, 2021 at 11:34:44PM -0800, Vagrant Cascadian wrote:
> On 2021-01-07, Elliott Mitchell wrote:
> > Might it be possible to get a u-boot-xen-arm64 package built? While
> > "PyGRUB" is great for Linux, it isn't so good for booting other OSes.
>
&g
On Thu, Jan 07, 2021 at 11:34:44PM -0800, Vagrant Cascadian wrote:
> This doesn't describe how to use it or, importantly, what files we would
> need to ship in the package. If you could help clarify that (possibly
> provide a patch), and ideally get it clarified in the upstream
> documentation,
On Thu, Jan 07, 2021 at 11:34:44PM -0800, Vagrant Cascadian wrote:
> On 2021-01-07, Elliott Mitchell wrote:
> > Might it be possible to get a u-boot-xen-arm64 package built? While
> > "PyGRUB" is great for Linux, it isn't so good for booting other OSes.
>
&g
Hmm, don't see a copy of the follow-up message anywhere. Sent to the bug
and not me?
6 devices are being monitored, they're behind a HP controller (cciss
driver).
I don't know for certain that triggering self-tests is the cause, this is
merely obvious speculation. My most recent observations
Package: u-boot-rpi
Version: 2020.10+dfsg-1+b1
Severity: important
Hopefully SSIA.
U-Boot's USB support is highly unreliable. Trying to interact with an
advanced bootloader (GRUB) via USB-keyboard is highly troublesome if the
Raspberry PI is also booting from a USB storage device.
There is
Package: u-boot-rpi
Version: 2020.10+dfsg-1+b1
Severity: important
Appears "standard" device trees for the Raspberry PI 4B connect the
serial pins to the mini-UART. This is troublesome due to the mini-UART's
baud rate changing when the processor clock changes.
Often Raspberry PI devices have an
found 935456 5.9.6-1~bpo10+1
quit
After having spent several hours on kernel compiles and experimenting
with the situation, I'm fairly sure this also applies to
linux-source-5.9.
Odd thing is, when I booted the device using the Tianocore implementation
it came right up with no problems. I'm
The patch to have GRUB load a device-tree is interesting. This is
certainly worthy of discussion.
Three issues come up when looking though:
First, your patch modifies /etc/grub.d/10_linux, but misses
/etc/grub.d/10_linux_xen. /etc/grub.d/10_linux_xen needs a fairly
similar treatment.
Second,
found 963962 2.02+dfsg1-20+deb10u2 2.04-10
quit
I was going to report I'd never observed this bug, but then I examined
the grub.cfg files and I discover they're present. I would tend to rate
this as minor, but the original submitter didn't adjust severity.
With 2.04-10 the xen-4.*.config file
For a Raspberry PI, I've got the initial workings of a script to
accomplish this goal.
First, install u-boot-rpi, raspi-firmware, and grub-efi-arm64.
Next, create a filesystem on a device the Raspberry PI will boot from.
For anything pre-RP4, this will have to VFAT and show up in a MBR. A
As of 2.04-8 it was possible to boot Xen on ARM. The funky mechanism by
which GRUB loads its modules does a good job of obscuring which modules
to confirm presence of.
Seeing 'xen_loader="xen_hypervisor"' makes one expect to find
"/usr/lib/grub/arm64-efi/xen_hypervisor.mod", not for it to be
found 939633 5.8.10-1~bpo10+1
severity 939633 important
merge 935456 939633
quit
I'm left suspecting bugs #935456 and #939633, are in reality a single
bug: Raspberry Pi device trees were garbled during Debian's 5.2 kernel
development.
They appear to remain very garbled, to the point of being
On Wed, Nov 25, 2020 at 01:32:10PM +0100, Hans van Kranenburg wrote:
> Can you still reproduce this with Xen 4.11 or 4.14?
> If not, can you mail 939186-cl...@bugs.debian.org to close it?
>
> I just tried a few things with maxmem and memory with a PVH guest on Xen
> 4.14, and it just seems to
My thinking mirrors one of Jonathan McDowell's: One should be able to
build an installation image for $device/$architecture on
$random_device/$random_architecture.
This is very useful for exactly the same situations where using
`debootstrap --foreign` is. Say if one has a desktop already
Package: grub2-common
Version: 2.04-10
`grub-install` fails to install properly when run on a system using
U-Boot's implementation of the EFI protocol (potentially also effects
package grub-efi-arm64, perhaps this should be against src:grub2).
Since a Tianocore-based implementation of the EFI
There may be several distinct bugs involved with #824954. For one, I
suspect `grub-install`'s behavior needs to change if EFI variables aren't
supported. I use this as a flag which could distinguish installation on
top of a full EFI implementation (perhaps Tianocore-derived), versus
U-Boot's
reopen 948712
quit
There should be a rather obvious use case where absent /boot/firmware is
quite appropriate. For someone needing a copy of the firmware, but using
other tools to build the boot area.
Notably one might use raspi-firmware to retrieve start*.elf/fixup*.dat.
Then add u-boot-rpi
Commenting since the report still exists in the bug DB...
I've found `os-prober` often produces many false positive OS installation
detections. As such I really find recommends too strong, simply
including during installation and then merely suggests would be better.
If someone removes it,
On Fri, Nov 20, 2020 at 08:02:26PM +0100, Hans van Kranenburg wrote:
> So,
>
> On 9/21/20 4:16 PM, Hans van Kranenburg wrote:
> > [...]
> >
> > gcc-Wl,-z,relro -Wl,-z,now -pthread -Wl,-soname
> > -Wl,libxentoolcore.so.1 -shared -Wl,--version-script=libxentoolcore.map
> > -o
I'm pretty sure bug #546392 was completed several /years/ ago, yet the
bug was never marked complete. I don't recall when, but perhaps near
version 2.01 or earlier?
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP
DF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
>From 1bb407482fa82ad5034a4e4bdfa34dfa3a828f9a Mon Sep 17 00:00:00 2001
From: Elliott Mitchell
Date: Thu, 1 Oct 2020 15:19:33 -0700
Subject: [PATCH] tools/python: Correct extension filenames for Python 3
Appears Python became *more* diff
Package: idle3-tools
Version: 0.9.1-2
`idle3ctl` needs an implementation of `smartctl`'s -d option in order to
talk to disks behind hardware RAID controllers.
This is nearly a bug in smartmontools of the code for the -d option
needing to turn into a library so other low-level tools can utilize
Package: smartmontools
Version: 6.6-1
`smartd` is doing some sort of activity which tends to trigger the kernel
oom-killer. I suspect this may relate to triggering self-tests.
System in question has plenty of swap available, and presently reports
more than 50MB of available memory.
Presently
(sending a second copy to the body of the message since
<774...@bugs.debian.orgg> didn't quite work)
retitle 774129 dpkg-buildpackage: Should set the cross build profile
automatically
severity 774129 normal
quit
Setting the "cross" build profile could be the difference between a
successful cross
Package: dpkg-dev
Version: 1.19.7
Severity: important
Between versions 1.19.6 and 1.19.7 the behavior of the -P option for
dpkg-buildpackage changed. At 1.19.6 if there was no string directly on
the -P option, the following argument would be interpreted as the
profiles to set. At 1.19.7 the
On Tue, Sep 22, 2020 at 02:39:09PM +0200, Hans van Kranenburg wrote:
> How did you test it and how did you get a working process without the --?
By reading the man page, noticing there was no mention of "--" and then
trying `choom -n +5 sleep 5` and found that worked. When you sent this
message
This is fun. Actually isn't too difficult to trigger, simply slowly
reduce the memory Xen allocates to Dom0 and eventually the oom-killer is
likely to trigger (having tried to shrink Dom0 as far as possible,
believe me, I know). I had been wondering which of the Xen daemons could
be safely
found 774129 1.19.7
quit
You might consider -a/--target-arch or -t/--target-type to merely be
conveniences, but /not/ enabling the cross profile when the build arch
differs from the host arch is stopping a decimeter shy of the goal line.
Is it even possible someone /wouldn't/ want the cross
On Sat, Jul 18, 2020 at 04:08:50PM +0200, Hans van Kranenburg wrote:
> On 7/18/20 5:53 AM, Elliott Mitchell wrote:
> > Package: src:xen
> > Version: 4.13
> > Tags: patch
> >
> > I've been playing try to get Xen 4.13 to cross-build for ARM. In the
> >
1 - 100 of 392 matches
Mail list logo
