>From: Theodore Ts'o <[EMAIL PROTECTED]>
> Um, e2fsck does search for the external journal device by UUID. It
> only falls back to the superblock field specifying the device if the
> journal can't be found.
I was in a hurry so I might of misread the symptoms I was seeing, but it
sure looked like
>From: Theodore Ts'o <[EMAIL PROTECTED]>
> On Mon, Mar 06, 2006 at 09:44:47PM -0800, Elliott Mitchell wrote:
> > I was in a hurry so I might of misread the symptoms I was seeing, but it
> > sure looked like e2fsck 1.37-2sarge1 wasn't finding the journal. I didn
>From: Theodore Ts'o <[EMAIL PROTECTED]>
> The attitude is indeed to leave this for userspace for doing such
> searches; that's why what is specified is the device number. The
> correct tool for doing the searches is the blkid library, which is
> what e2fsck and tune2fs uses, and arguably mount sh
Package: chkrootkit
Version: 0.44-2
There are two serious failures in getCMD() inside `chkrootkit`.
First, the RUNNING=... will only give a string if the program is running
at the time. A test might be run for a daemon that isn't installed. Even
if the daemon is present, it might not be running.
Package: libnss-db
Version: 2.2-6
Severity: important
Other than the extremely sparse notes in /etc/default/libnss-db (which
you only find by looking at the package files), there is absolutely no
documentation for libnss-db. No man page, no files in /usr/share/doc.
--
(\___(\___(\__
Package: ssmtp
Version: 2.61-5
Many of the MTAs support IPv6, it would be nice if stub mailers did too.
The man page's mention of a "-6" option also implies the presence of IPv6
support, yet it is absent.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (|
>From: Theodore Ts'o <[EMAIL PROTECTED]>
> On Tue, Mar 07, 2006 at 06:12:25PM -0800, Elliott Mitchell wrote:
> > That isn't what I have a problem with in this case. Problem is `mount`
> > would have to understand the target filesystem in order to find out the
&g
>From: Theodore Ts'o <[EMAIL PROTECTED]>
> On Fri, Mar 10, 2006 at 11:36:17PM -0800, Elliott Mitchell wrote:
> > How much are block devices expected to change on every boot? For
> > automatically mounted filesystems, this could be done as part of
> > `fsck -a`.
Package: jailtool
Version: 1.1-4
We have the symbolic link: /usr/share/man/man1/update-jail.1.gz
which points to: jailtool.1.gz
Alas, the mysterious man page jailtool.1.gz does not appear to exist
anywhere in Debian.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
Package: quilt
Version: 0.46-6
Appears that quilt needs to depend on mail-transport-agent, otherwise
/usr/share/quilt/compat/sendmail won't be too useful.
The link /usr/share/quilt/compat/awk has a similar issue. Does quilt
need to depend on gawk? Could it perhaps use /usr/bin/awk, or
/etc/altern
Package: libpango1.0-doc
Version: 1.20.5-5+lenny1
libpango1.0-doc needs to depend on libglib2.0-doc, otherwise the symbolic
links: /usr/share/doc/libpango1.0-doc/glib and
/usr/share/doc/libpango1.0-doc/gobject will point to invalid locations.
(or those two links could be removed)
--
(\___(\___
Package: libmilter1.0.1
Version: 8.14.3-5+lenny1
/usr/share/bug/libmilter1.0.1 points to "sendmail", which only exists
if sendmail-base is installed (other tools can use milter and drag in
libmilter).
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (|
Package: kaffe-pthreads
Version: 2:1.1.8-5.2
/usr/lib/kaffe/pthreads/include points to ../include, which is absent
unless kaffe-dev is installed.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| e...@gremlin.m5p.com PGP F6B23DE0 |) /
I don't believe this is attributable to NIS, but a more generalized
problem (and I would expect the general problem to effect current
versions of the passwd package too).
I'm running into a similar sort of difficulty here, except the package
I've got interacting in a bad way is libnss-db. Mainly,
I'll confess I'm only trying with the 2.6.26-21lenny3 kernel source, but
I'm seeing the same thing Xel Media reportted. Given how large the
differences are though, I've got a very strong suspicion it won't apply
to the kernel source originally shipped with lenny either.
I suppose this is an improv
>From: Luk Claes
> > The "users" option got broken with the latest release, despite working
> > correctly in 1:1.0.10-6+etch.1 (old stable). Non-root users can mount
> > filesystems listed in /etc/fstab that have "users" specified, but they
> > will be unable to unmount the filesystem
> > ("umount
I should also add that I'm now dealing with nfs-common 1:1.2.2-4, and
mount 2.17.2-9 (current stable).
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| e...@gremlin.m5p.com PGP F6B23DE0 |) /
\_CS\ | _ -O #include O- _
Package: lilo
Version: 1:22.8-10
First noticed this with the 1:22.8-7 (lenny) version. The lilo package
installs hooks to get rerun when the initramfs-tools are invoked, or a
kernel package is installed. These hooks though completely ignore
/etc/kernel-img.conf (configuration file created by kerne
Package: elilo
Version: 3.12-4
The elilo package installs hooks to get rerun when the initramfs-tools
are invoked, or a kernel package is installed. These hooks though
completely ignore /etc/kernel-img.conf (configuration file created by
kernel-package); in particular the "do_bootloader" option, w
Package: dump
Version: 0.4b43-1
I'm trying to believe this is all the fault of #588675 and dump is
blameless, but I'm uncertain. The problem is pretty straightforward, when
the root filesystem is listed in /etc/mtab|/proc/mounts as "/dev/root",
the output for the -w option for the root filesystem
Might I suggest pondering returning bug #359717 to wishlist severity and
taging it "wontfix"?
The problem is binding mounts *will* break things if used improperly (or
properly depending on POV and how sadistic you are). The steps used by
`mountpoint` are absolutely correct from Unix traditions, th
I spotted bugs #326647 and #526398 while doing a bit of research for
another problem. #326647 is worth mentioning because it requires almost
exactly the same key ingredient as #575343. Mainly some method to inhibit
precautionary checks while allowing regular unclean-FS checks to go
through (anythin
>From: Ted Ts'o
> Not really. E2fsck checks to see if it is on battery, and if so, it
> will let the system go a few extra mounts before really forcing a
> check. It works fine for laptops that are sometimes started while on
> battery.
#326647 needs an argument for `fsck` that is passed to the
>From: ty...@mit.edu
> On Mon, May 24, 2010 at 03:11:23PM -0700, Elliott Mitchell wrote:
>
> If you hate precautionary checks so much, then turn them off. The
> tools for doing this are within your hands. Or do them using a LVM
> snapshot.
I don't hate precautionary ch
Any update?
Should /I/ create a second bug report and attach it to util-linux? (or
are you going to do the honors?) Thought I saw the current BTS can have a
report shared amoung multiple packages...
The algorithm that comes to mind for this problem:
Pass 0: (/etc/init.d/checkroot.sh)
C
Package: aptitude
Version: 0.4.11.11-1~lenny1
Updating the display of packages behind the search box while typing
characters is nice, it is also rather sluggish. Worse, it appears that
aptitude updates its display after each character pressed, not accounting
for someone having typed faster and bei
Package: sun-java5-doc
Version: 1.5.0-17-0.1
The subject line pretty well covers it. The message specifies downloading
the Java documentation zip file to /tmp, when it really wants it
downloaded to ${TMP_DIR}.
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (
>From: Matija Nalis
> On Tue, Apr 27, 2010 at 01:57:20PM -0700, Elliott Mitchell wrote:
> > >From: Gerrit Pape
> > > Hi, you don't say in which way it breaks the older unofficial package
> > > for you.
> >
> > Seeing how ucspi-tcp is/was mos
>From: Matija Nalis
> So, original question was "what broke"? You still didn't answer that.
> Package being upgraded is not breaking. If you lost some functionality, that
> might have been breakage (from your POV), and that is what I (and Gerrit, I
> believe) are interested in details of.
Well, o
Package: initramfs-tools
Version: 0.92o
If the running kernel has had module support removed, you'll get a bunch
of errors of:
grep: /proc/modules: No such file or directory
The one place I found was in /usr/share/initramfs-tools/hook-functions,
the function manual_add_modules(). Looks like you n
reopen 326415
stop
>From: ow...@bugs.debian.org (Debian Bug Tracking System)
> There are no TCP listeners in the qmail package. The TCP layer is handled by
> another package. I would be more than happy to add IPV6, but since it
> doesn't have any TCP listeners, it is not possible.
>
Please p
>From: Jon Marler
> Have you tested that this patch works? I don't have an IPV6 network to play
> with.
>
Seems to, there isn't too much SMTP traffic over IPv6 right now. At the
very least, it doesn't break SMTP over IPv4. Note though that there is
the one small conflict with the 0.0.0.0 patch
Package: e2fsprogs
Version: 1.41.3-1
Subject tells the story. Why are mere /precautionary/ filesystem checks
allowed to slow a system booting so much? ie the ones triggered by either
the mount count or check time exceeding their limits.
I would suggest limiting it to doing a precautionary check o
>From: ty...@mit.edu
> If you are mounting the file system read-only, feel free to change the
> fsck pass number in /etc/fstab to be 0. That will cause e2fsck to be
> skipped completely.
Wrong behavior. The desire here is not to disable checks due to being on
read-only media, but the filesystem i
>From: ty...@mit.edu
> On Thu, Mar 25, 2010 at 12:55:50AM -0700, Elliott Mitchell wrote:
> >
> > Which is why I wasn't writing about the mount count. I was writing about
> > the check interval/check time. With systems that reboot less than once a
> > month, th
>From: Gerrit Pape
> Hi, you don't say in which way it breaks the older unofficial package
> for you.
Seeing how ucspi-tcp is/was most often generated from ucspi-tcp-src for
more than the past 10 years, I'd hardly call it "unofficial".
> This should have been displayed to you when upgrading to t
Package: initscripts
Version: 2.86.ds1-61
I'm guessing some step is being done by the initial ramdisk scripts,
with Etch that step was also done by the regular init script; whereas
in Lenny it got removed from the initscripts.
$ head -2 /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 ro,erro
From: Petter Reinholdtsen
> [Elliott Mitchell] wrote:
> > I'm guessing some step is being done by the initial ramdisk scripts,
> > with Etch that step was also done by the regular init script;
> > whereas in Lenny it got removed from the initscripts.
>
>
>From: Petter Reinholdtsen
> [Elliott Mitchell]
> > Hrmm, one more setting that may be required to reproduce, this
> > system mounts / read-only.
>
> What does your /etc/fstab file look like? What about the
> /proc/cmdline content? I have no clue what is going on, so
>From: Petter Reinholdtsen
> [Elliott Mitchell]
> > fstab: Several FSes listed. / is defaults,ro. /proc and /tmp are
> > explicitly listed, the other tmpfs mounts are not listed (/dev/shm,
> > etc).
>
> Can you attach a copy of your /etc/fstab too?
The l
Package: initramfs-tools
Version: 0.92o
Subject tells the story. Appears the images generated by initramfs-tools
completely ignore the `rdev` setting that the kernel was given to the
kernel. While 99% of users may be explicitly passing the root device via
passing "root=/dev/foo" through the bootlo
reopen 589118
quit
>From: Ben Hutchings
> On Wed, 2010-07-14 at 18:11 -0700, Elliott Mitchell wrote:
> > Package: initramfs-tools
> > Version: 0.92o
> >
> > Subject tells the story. Appears the images generated by initramfs-tools
> > completely ignore th
Just realized I may have made an error when listing the conditions
necessary to reproduce. I am uncertain whether or not a non-initrd kernel
is required to reproduce.
What may instead be the required ingredient is the using the `rdev`
setting to specify the root filesystem. I'll check tommorrow, b
Bit more testing and I've merely gotten rid of more causes. Tried booting
with an older 2.6.18 kernel from etch that I had handy. Problem still
occurred. Tried booting the current kernel while passing the the root
device via the kernel command-line ("root=/dev/sda1"), problem still
occurred.
Curre
reopen 589118
quit
>From: Ben Hutchings
> On Thu, 2010-07-15 at 13:48 -0700, Elliott Mitchell wrote:
> > Bzzzt! While the "initrd=" kernel command-line option and `rdev` kernel
> > settings are not completely orthogonal, they are mostly unrelated.
>
> You o
Just found what looks suspiciously like a proverbial smoking gun on the
GTK/GDK side of things. Rather contrary to my previous suspicions,
disabling handling FocusOut, FocusIn, LeaveNotify and EnterNotify events
failed to improve the situation. So, finally went in and tried adding
"return_val=FALSE
Package: atftpd
Version: 0.7.dfsg-9.1
Looks like when concentrating on the development to work with multicast
TFTP, you forgot about the far more common case of singlecast. I'm unsure
of the limitations of the device I'm working with, but it appears to want
a response from the same IP/port that it
Did a bit more looking and it looks like I attributed this wrong. The
device isn't getting confused by moving to a new port, instead it looks
like atftpd may be losing track. Got some better packet traces now:
:69<- remote RREQ , timeout 5
local -> remote OACK timeout 5
local <- remote
Debugging GUI programs within X can be entertaining. Particularly when it
is a library used by many tools. Also interesting to build a debuging
version og GTK/GDK. Grabbing a handy program to try tracking this bug
down...
(not yet complete)
>From the unclutter side:
The obvious starting point is
Package: libgtk2.0-0
Version: 2.20.1-2
Severity: important
Seems a rather serious processor consumption bug appeared in the
libgtk2.0-0 package somewhere between versions 2.12.12-1~lenny2 and
2.20.1-2.
I'm unsure whether any special configuration is required to tweak this.
The only thing that com
>From: Josselin Mouette
> Le lundi 16 mai 2011 ? 17:35 -0700, Elliott Mitchell a ?crit :
> > I'm unsure whether any special configuration is required to tweak this.
> > The only thing that comes to mind is I've got the traditional
> > FocusFollowsMouse, and fo
>From: Josselin Mouette
> Le mardi 17 mai 2011 ? 16:04 -0700, Elliott Mitchell a ?crit :
> > Not much needed to reproduce. Start one of the many afflicted programs,
> > whenever you move the pointer into its window and see the processor usage
> > hit 100% whenever you mov
>From: Josselin Mouette
> Le mercredi 18 mai 2011 ? 14:56 -0700, Elliott Mitchell a ?crit :
> > > What is your graphics hardware and which driver are you using?
> >
> > I'm rather doubtful the graphics driver would effect this as no visual
> > glitches of
When looking at bug #577146, the thought comes to mind; is halt the
correct action to do in case of power failure?
Thing is, "halt" generally means going down for operator intervention of
some kind. Possibly hardware maintainance, perhaps to retire the system,
those sorts of longish downtime actio
>From: Josselin Mouette
> Le mercredi 18 mai 2011 ? 16:23 -0700, Elliott Mitchell a ?crit :
> > I'm glad I reconsidered window manager (metacity) involvement. While
> > looking at the processes that were running away, it looks like I found
> > the key much further do
From: Henrique de Moraes Holschuh
> On Wed, 18 May 2011, Elliott Mitchell wrote:
> > When looking at bug #577146, the thought comes to mind; is halt the
> > correct action to do in case of power failure?
>
> You will be without power soon, but you have no idea how soon. And
Package: atftpd
Version: 0.7.dfsg-9.1
Subject hopefully describes the situation. If atftpd is invoked with
*both* the --port and --bind-address options, it will lose track of the
port.
I believe something along the lines of:
-8<---8<
Played with this some more. Got atftpd rebuilt with debugging symbols
left in, then re-ran under gdb and watching packet captures. Suddenly
it succeeds. I've got a nasty suspicion this is actually a timing issue,
not a ports getting confused issue.
A couple small refinements I ran into when tryin
I'm seeing bug #810964 occur in Xen 4.8 as well. Perhaps #810964
should be reassigned to xen-hypervisor-common or src:xen ?
I don't know whether it effects Xen 4.11 yet...
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP
On Tue, Feb 12, 2019 at 12:11:11AM +0100, Hans van Kranenburg wrote:
> This means you will have to do things like hop on the upstream
> development mailing list, build a reproducable failure case, search for
> a developer that has similar hardware and wants to spend time on it,
> donate hardware to
Package: apcupsd
Version: 3.14.14-0.3
If the value PWRFAILDIR is modified in /etc/apcupsd/apcupsd.conf, the
/etc/apcupsd/ups-monitor script WILL fail. The attached patch should
solve this.
PWRFAILDIR should likely default to "/run" or "/run/apcupsd" as those
are STRONGLY prefered for runtime sta
tags 901358 patch
quit
Need to attach the patch...
--
(\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/)
\BS (| ehem+sig...@m5p.com PGP 87145445 |) /
\_CS\ | _ -O #include O- _ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-
Package: e2fsproc
Version: 1.43.4-2
Subject tells the story:
# tune2fs -O dir_index,extent,metadata_csum,mmp,quota -Q
usrquota,grpquota,prjquota /dev/foo
tune2fs 1.43.4 (31-Jan-2017)
[ERROR] ../../../../lib/support/quotaio.c:275:quota_file_open::
qh_ops->check_file failed
tune2fs: Unknown code
Package: monkeysphere
Version: 0.41-1
Unless there is a very *good* reason, the monkeysphere user should almost
certainly have /bin/false or /usr/sbin/nologin as its shell. This may
not be a huge security hole, but it is very poor practice.
--
(\___(\___(\__ --=> 8-) EHM <=--
Bug #601006 is quite the blast from the past. I'm pretty sure `set -e`
is strongly endorsed at this point due to security concerns.
While an interesting historic relic, is it worth keeping #601006 around
to point out how attitudes have changed?
--
(\___(\___(\__ --=> 8-) EHM <=--
On Fri, Jun 15, 2018 at 08:39:05PM -0400, Theodore Y. Ts'o wrote:
> On Tue, Jun 12, 2018 at 11:38:15PM -0700, Elliott Mitchell wrote:
> > # tune2fs -O dir_index,extent,metadata_csum,mmp,quota -Q
> > usrquota,grpquota,prjquota /dev/foo
> > tune2fs 1.43.4 (31-Jan-2017)
&
Package: file
Version: 1:5.30-1+deb9u1
SSIA. When examining files produced by `dump` it gives a date for the
current file and the date of the previous dump. Unfortunately the date
it is giving for the "Previous dump" is the date on the file being
examined, whereas the date for "This dump" is the
On Sun, Jun 17, 2018 at 02:31:29PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jun 15, 2018 at 07:37:19PM -0700, Elliott Mitchell wrote:
> >
> > During the process I ended up running `e2fsck -f` multiple times. I
> > ended up running `e2fsck -f` after enabling each fea
On Mon, Feb 18, 2019 at 02:37:48AM -0700, Jan Beulich wrote:
> >>> On 18.02.19 at 09:42, wrote:
> > On Mon, Feb 18, 2019 at 01:12:16AM -0700, Jan Beulich wrote:
> >> >>> On 15.02.19 at 19:20, wrote:
> >> > On Fri, Feb 15, 2019 at 03:58:49AM -0700, Jan Beulich wrote:
> >> >> Well, Fam10 is mention
found 452721 4.8.5+shim4.10.2+xsa282-1+deb9u11
quit
I'm inclined to suggest #452721 is actually a bit more than merely
wishlist. The ordering of domain start/restore/stop/save can be
extremely important. The current behavior of the xendomains init script
is rather simplistic.
I would argue for
Package: mlocate
Version: 0.26-2
The authors of mlocate need to figure out what their security model is
since the documentation and behavior seem to be confused about what the
actual model is.
Of crucial note, is the "mlocate" group supposed to be the controlling
factor for access to these DB fil
Package: e2fsprogs
Version: 1.43.4-2
Could `mke2fs` and `tune2fs` get some method to initialize the maximum
mount count to a non-zero value?
Having to search for random values to initialize the maximum mount count
is a bit annoying. Perhaps a -O init_max_mount_count setting?
I understand the au
Package: src:xen
Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11
Severity: important
I'm observing an odd memory-leak like behavior for Xen's Dom0.
I've been attempting to reduce the memory usage of Dom0 so, I'd been
slowly decreasing the amount allocated to Dom0. Presently using
"dom0_mem=360M,max:3
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 t
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
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 dea
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 displ
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 profi
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 restar
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 I
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 stri
What I'm seeing seems kind of related to the topic of XSA-300. Mainly
something ballooning out pages.
The Debian Wiki advises reducing the amount of memory used by Domain-0.
Perhaps the Debian Wiki should be advising to try to keep the Domain-0
maximum substantially higher than the actual allocat
On Mon, May 18, 2020 at 10:56:06AM +0200, Christoph Biedl wrote:
> Elliott Mitchell wrote...
> > (for the level 0 is is reporting the epoch,
> > "never", "none", or "No previous dump" would be better). Also noticing
> > for the level
Package: src:linux
Version: 4.19.118+2
Severity: important
Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and
linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in particular v4 got broken.
Mounting an appropriate filesystem became unreliable, and once mounted
behavior is unpredictable.
I
On Fri, Jun 05, 2020 at 08:44:26AM +0200, Salvatore Bonaccorso wrote:
>
> On Thu, Jun 04, 2020 at 10:16:07PM -0700, Elliott Mitchell wrote:
> > Somewhere between linux-image-4.19.0-8-amd64/4.19.98+1+deb10u1 and
> > linux-image-4.19.0-9-amd64/4.19.118+2 NFS, in partic
On Fri, Jun 05, 2020 at 08:36:31PM +0200, Salvatore Bonaccorso wrote:
> This now let some rings bell, the described scenario is very similar
> to what was reported in https://bugs.debian.org/934160
>
> Respectively
> https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736 and
> https://bu
I've run into a problem which produces the same behavior as bug #934160,
but attributed it elsewhere due to other observations.
What are the version(s) of the Linux kernel being used on your server and
clients?
I've confirmed using a 4.9 kernel on a client instead of a 4.19 kernel
also works arou
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.
>
(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
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, the
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.
>
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 se
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 pret
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 take
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
system
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 en
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, r
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 gett
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
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 some
201 - 300 of 395 matches
Mail list logo
