Bug#1077554:

[Joshua Hudson]

I've since learned this bug is upstream; and have most of a fix.
Basically I'm bogged down in autoconf; which makes it unsuitable for
upstream but I could provide a debian specific patch without autoconf.

I don't think the openssh team likes gmail much; the mailing list for
reporting anything upstream doesn't want to let me join or send
anything.

I've thought about it, and constructing a chroot directory per user is
a rather big ask on server support; it really does seem like allowing
ChrootDirectory %h to work with a writable home directory is better
than any alternative. It's actually less effort to patch locally but a
local rebuild in the middle of the night is a pill.

Bug#1077554: /usr/sbin/sshd: ssh server ChrootDirectory %h does not honor mount -o noexec

[Joshua Hudson]

Package: openssh-server
Version: 1:9.2p1-2+deb12u3
Severity: normal
File: /usr/sbin/sshd

On a previous deploy, ops had configured something like

Subsystem sftp internal-sftp

Match Group filedrop
ChrootDirectory %h
AllowTCPForwarding no
X11Forwarding no

That build of ssh seems to have a bunch of checks knocked out and
does not notice when you mess up the permissions on the .ssh folder.

On trying to test a replacement on a test server I found out this
configuration doesn't work. The test user is U, has a home directory
of /u/U, and /u is mounted noexec.

Documentation I found says this should work: 
https://unix.stackexchange.com/a/396684

Adding ForceCommand internal-sftp doesn't help. That's not the problem.

I'm pretty sure I could fix this by adding a statvfs() call to check
if the directory is noexec or not. Getting such a change approved is
harder than making it.

-- System Information:
Debian Release: 12.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-server depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  init-system-helpers1.65.2
ii  libaudit1  1:3.0.9-1
ii  libc6  2.36-9+deb12u7
ii  libcom-err21.47.0-2
ii  libcrypt1  1:4.4.33-2
ii  libgssapi-krb5-2   1.20.1-2+deb12u2
ii  libkrb5-3  1.20.1-2+deb12u2
ii  libpam-modules 1.5.2-6+deb12u1
ii  libpam-runtime 1.5.2-6+deb12u1
ii  libpam0g   1.5.2-6+deb12u1
ii  libselinux13.4-1+b6
ii  libssl33.0.13-1~deb12u1
ii  libsystemd0252.26-1~deb12u2
ii  libwrap0   7.6.q-32
ii  lsb-base   11.6
ii  openssh-client 1:9.2p1-2+deb12u3
ii  openssh-sftp-server1:9.2p1-2+deb12u3
ii  procps 2:4.0.2-3
ii  runit-helper   2.15.2
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  252.26-1~deb12u2
ii  ncurses-term 6.4-4
ii  xauth1:1.1.2-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded

Bug#1068239: jq: JSON filters can be fooled by \u0041 or other escapes in object names

[Joshua Hudson]

Package: jq
Version: 1.6-2.1
Severity: important

Consider this JSON file:

{
"\u0041PIModule": "/test2.dll",
"APIModule": "/test.dll"
}

On running jq .APIModule < test.json, the output is "/test.dll". The
expected output is "/test2.dll", "/test.dll", or alternately an error
message as this input file is in fact malformed. The order of the two
input lines does not matter: reversing the order in input does not
change the output.

This bug is security class, and was discovered by looking for a solution
to a security problem we uncovered in new development; however this is
not a security bug for everybody. Most people don't try to determine if
JSON input is trustworthy this way.

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jq depends on:
ii  libc6   2.36-9+deb12u4
ii  libjq1  1.6-2.1

jq recommends no packages.

jq suggests no packages.

-- no debconf information

Bug#1068024: Potential solution to your downgrade problem in dpkg

[Joshua Hudson]

The dpkg -> xz-utils downgrade problem has a suggestion that suggests
itself.

1) Downgrade dpkg's dependency to the last known good. It doesn't matter
how old so long as it can read the file formats. I understand this is
likely to be 5.4.1.

2) Statically link all the decompressor libraries into dpkg. Yes this means
gzip, bzip2, zstd, and xz's libraries. Today's compile and link time
optimizers are pretty good; it should be able to drop all references to the
compression side pretty much by itself. This would generally be a pretty
good change of its own as it makes the minimal system easier to understand
and the net-install CD smaller.

Then you're free to do what you need to do for all the other dependencies
of xz-utils.

Bug#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

[Joshua Hudson]

On Tue, Jan 23, 2024 at 5:40 PM Guillem Jover  wrote:
>
> Hi!
>
> On Tue, 2024-01-23 at 16:47:34 -0800, Joshua Hudson wrote:
> > On Tue, Jan 23, 2024 at 3:16 PM Guillem Jover  wrote:
> > > On Tue, 2024-01-23 at 13:46:53 -0800, Joshua Hudson wrote:
> > > > Package: dpkg
> > > > Version: 1.21.22
> > > > Severity: important
>
> > > > Source for long link record length does not include trailing null:
> > > >
> > > > https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294
> > > >
> > > > I've stashed the offending .deb package but I'm not sure if I can
> > > > get clearance to release it.
> > >
> > > Ack. I did not try to reproduce this yet because it was not obvious
> > > exactly how to do that from the report, instead just inspected the
> > > code for potential brokenness related to this, and I think I've fixed
> > > this now, but as I've not tested it, could you instead try applying
> > > the attached patch against dpkg and test with your package whether
> > > this fixes the problem you've found?
> >
> > That patch fixed the bug. Knowing where the bug is, I can see how
> > the bug works and explain why. I'm wondering if this was just a
> > pending disaster for everybody or if there's some actual reason it
> > doesn't trip on official packages.
>
> Thanks for testing! Much appreciated.
>
> It looks like the code in libdpkg has been like that since long GNU
> names and links were implemented (around Oct 1999, in dpkg commit
> <https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=3252594427f5285ab4091a6beca2adaa5082a883>).
>
> Checking now the libdpkg test suite and the GNU tar implementation
> which is what gets used to generate .debs by dpkg-deb, I see it always
> includes the NUL byte as part of the size, which explains why this has
> never been a problem when using the dpkg-deb tooling combined with GNU
> tar.
>
>   <https://git.savannah.gnu.org/cgit/tar.git/tree/src/create.c#n542>
>
> I assume, given the libtar link you provided initially, that your custom
> .deb package is being generated by something using that library? If so
> that would also explain things. I think libtar should probably get a
> bug report to mimic the GNU behavior.

I used a couple of different sample sources to find how Gnu LongLinks work,
and yes libar was one of them. It looks like gnutar itself is the
oddball; everybody
else I found set the size to not include the trailing null. What's
funny is I thought
I had found that gnutar did the same; I guess I just misread the
hexdump of its output.
I guess that's what we all get for lack of an actual specification on it.

Incidentally, gnutar will read either way. Robustness is a good thing.

Here's another generator. Search for WriteAsGnu. Sorry I can't link to line
because of new web accessibility issues on github.

https://raw.githubusercontent.com/dotnet/runtime/d250dcc2deae28fa9726ecad78dddf614b1420a8/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Write.cs

> But regardless of libtar getting fixed or not, I'm still going to be
> committing the change, to make the parser robust against such input.

Much appreciated.

> Thanks,
> Guillem

Bug#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

[Joshua Hudson]

On Tue, Jan 23, 2024 at 3:16 PM Guillem Jover  wrote:
>
> Hi!
>
> On Tue, 2024-01-23 at 13:46:53 -0800, Joshua Hudson wrote:
> > Package: dpkg
> > Version: 1.21.22
> > Severity: important
>
> > On unpacking a custom .dpkg file with long symbolic links, I found a
> > bunch of symbolic links ending in right, and one with copyright. The
> > overrun made all the links exactly the same length; suggesting reuse
> > of some kind of static buffer, but it's not clear if that's really
> > the case.
> >
> > Making long link records an extra byte longer for the trailing null
> > fixed the overrun and allowed the package to unpack correctly.
>
> Where those long name lengths exactly multiples of 512?

They were not. Must have been a 0 byte in the buffer after copyright.

>
> > Source for long link record length does not include trailing null:
> >
> > https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294
> >
> > I've stashed the offending .deb package but I'm not sure if I can
> > get clearance to release it.
>
> Ack. I did not try to reproduce this yet because it was not obvious
> exactly how to do that from the report, instead just inspected the
> code for potential brokenness related to this, and I think I've fixed
> this now, but as I've not tested it, could you instead try applying
> the attached patch against dpkg and test with your package whether
> this fixes the problem you've found?

That patch fixed the bug. Knowing where the bug is, I can see how
the bug works and explain why. I'm wondering if this was just a
pending disaster for everybody or if there's some actual reason it
doesn't trip on official packages.

Bug#1061404: dpkg read buffer overrun unpacking K (long symbolic) records in data.tar

[Joshua Hudson]

Package: dpkg
Version: 1.21.22
Severity: important

Dear Maintainer,

On unpacking a custom .dpkg file with long symbolic links, I found a
bunch of symbolic links ending in right, and one with copyright. The
overrun made all the links exactly the same length; suggesting reuse
of some kind of static buffer, but it's not clear if that's really
the case.

Making long link records an extra byte longer for the trailing null
fixed the overrun and allowed the package to unpack correctly.

Source for long link record length does not include trailing null:

https://repo.or.cz/libtar.git/blob/HEAD:/lib/block.c#l294

I've stashed the offending .deb package but I'm not sure if I can
get clearance to release it.

This is a potential security vulnerability due to the bug class,
but I can'd find a plausible exploit pathway.

-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-16-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9+deb12u3
ii  liblzma5 5.4.1-0.2
ii  libmd0   1.0.4-2
ii  libselinux1  3.4-1+b6
ii  libzstd1 1.5.4+dfsg2-5
ii  tar  1.34+dfsg-1.2
ii  zlib1g   1:1.2.13.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.6.1
pn  debsig-verify  

-- no debconf information

Bug#1050578:

[Joshua Hudson]

Bug verified *upstream* on stock kernel version 6.4.12

Bug#1050483:

[Joshua Hudson]

Trying on sid (2023-08-25) objdump fails with: "./mv: file format not
recognized" and readelf still works.

objdump version from sid: GNU objdump (GNU Binutils for Debian) 2.41

Bug#1037516: ircd-hybrid hates winbindd users

[Joshua Hudson]

Package: ircd-hybrid
Version: 1:8.2.43+dfsg.1-1
Severity: important
Tags: newcomer upstream

Dear Maintainer,

When connecting to ircd-hybrid on localhost, users from a Windows domain get 
kicked out with invalid user.

I tracked this down to the source code; ircd-hybrid believes that \ is an 
invalid character in username
while ident reports the full username including the \ character in the middle.

Problem exists upstream.

-- System Information:
Debian Release: 12.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ircd-hybrid depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9
ii  libcrypt1  1:4.4.33-2
ii  libgnutls303.7.9-2
ii  libltdl7   2.4.7-5
ii  lsb-base   11.6
ii  openssl3.0.9-1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages ircd-hybrid recommends:
ii  whois  5.5.17

Versions of packages ircd-hybrid suggests:
pn  anope  

-- Configuration Files:
/etc/ircd-hybrid/cert.cnf [Errno 13] Permission denied: 
'/etc/ircd-hybrid/cert.cnf'
/etc/ircd-hybrid/ircd.conf [Errno 13] Permission denied: 
'/etc/ircd-hybrid/ircd.conf'
/etc/ircd-hybrid/ircd.motd [Errno 13] Permission denied: 
'/etc/ircd-hybrid/ircd.motd'

-- debconf information:
  ircd-hybrid/upgrade_secure_links_warn: true
  ircd-hybrid/automatically_fix_config: false
  ircd-hybrid/restart_on_upgrade: true

Bug#1008507:

[Joshua Hudson]

diff -ur glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c
glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c
--- glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29
17:50:12.558027042 -0700
+++ glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29
17:52:33.262157543 -0700
@@ -183,6 +183,11 @@
 case XFS_SUPER_MAGIC:
   return XFS_LINK_MAX;

+case MSDOS_SUPER_MAGIC:
+#ifdef EXFAT_SUPER_MAGIC // For when it gets added in about 30 years
+case EXFAT_SUPER_MAGIC:
+#endif
+  return 1;
 case LUSTRE_SUPER_MAGIC:
   return LUSTRE_LINK_MAX;

Bug#1008507:

[Joshua Hudson]

/* reproduce glibc bug */

/*
 * I don't typically care what the return of pathconf(..., _PC_LINK_MAX)
 * is; I just care whether or not it's greater than 1 because I'm checking
 * whether the filesystem supports hard links or not.
 */

#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
char file[40];
char dir[40];
char commandbuf[120];
sprintf(file, "/tmp/%u.img", getpid());
sprintf(dir, "/tmp/%u.mnt", getpid());
FILE *fimage = fopen(file, "wb");
fseek(fimage, 1440 * 1024 - 1, SEEK_SET);
fputc(0, fimage);
fclose(fimage);
mkdir(dir, 0);
sprintf(commandbuf, "mkfs.fat /tmp/%u.img", getpid());
if (system(commandbuf) != 0) {
rmdir(dir);
unlink(file);
return 1;
}

sprintf(commandbuf, "mount -o loop -t msdos %s %s", file, dir);
if (system(commandbuf) != 0) {
rmdir(dir);
unlink(file);
return 1;
}

int r;
printf("Testing pathconf(%s, _PC_LINK_MAX)...");
r = pathconf(dir, _PC_LINK_MAX) != 1;
printf(r ? "Failed\n" : "OK\n");
sprintf(commandbuf, "umount %s", dir);
system(commandbuf);
rmdir(dir);
unlink(file);
return r;
}

Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted

[Joshua Hudson]

I'd really rather not run systems at all but pulseaudio is just too broken
now.

On Friday, September 4, 2020, Joshua Hudson  wrote:

> I'm not convinced it's dmraid because udev reports the nodes up. It looks
> like systems only thinks the first device name on the list is alive.
> Unfortunately that name isn't stable across boots.
>
> On Fri, Sep 4, 2020, 12:58 PM Michael Biebl  wrote:
>
>> On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson 
>> wrote:
>> > Yeah dmraid's still in use. Is there a way to just get rid of all
>> > those device units because they don't do anything right now except
>> > cause problems? I've modified the boot order so systemd sees
>> > everything already mounted.
>>
>> My recommendation would be to get rid of dmraid.
>> It's dead upstream and unmaintained in Debian as well.
>> You are bound to run into problems and it's only getting worse in the
>> future.
>>
>> Michael
>>
>>

Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted

[Joshua Hudson]

I'm not convinced it's dmraid because udev reports the nodes up. It looks
like systems only thinks the first device name on the list is alive.
Unfortunately that name isn't stable across boots.

On Fri, Sep 4, 2020, 12:58 PM Michael Biebl  wrote:

> On Thu, 3 Sep 2020 16:06:28 -0700 Joshua Hudson 
> wrote:
> > Yeah dmraid's still in use. Is there a way to just get rid of all
> > those device units because they don't do anything right now except
> > cause problems? I've modified the boot order so systemd sees
> > everything already mounted.
>
> My recommendation would be to get rid of dmraid.
> It's dead upstream and unmaintained in Debian as well.
> You are bound to run into problems and it's only getting worse in the
> future.
>
> Michael
>
>

Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted

[Joshua Hudson]

Yeah dmraid's still in use. Is there a way to just get rid of all
those device units because they don't do anything right now except
cause problems? I've modified the boot order so systemd sees
everything already mounted.

On 9/3/20, Michael Biebl  wrote:
> Am 04.09.2020 um 00:58 schrieb Joshua Hudson:
>> I don't think it's a duplicate. #947806 is getting stuck waiting for
>> dmraid nodes to come up so filesystems can be mounted.
>
> Are you using dmraid?
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted

[Joshua Hudson]

I don't think it's a duplicate. #947806 is getting stuck waiting for
dmraid nodes to come up so filesystems can be mounted.

This #969489 is something took a dependency on an implicit unit that
probably shouldn't have a dependency on that unit.

On 9/3/20, Michael Biebl  wrote:
> Am 04.09.2020 um 00:10 schrieb Joshua Hudson:
>> brw-rw 1 root disk 254, 2 Sep  3 14:51
>> /dev/mapper/isw_cfbejbfeib_Volume12
>>
>> udevadm command output attached.
>>
>> The device isn't dead. It works when accessed directly by name.
>>
>> $ /sbin/swapon
>> NAMETYPE  SIZE USED PRIO
>> /dev/mapper/isw_cfbejbfeib_Volume12 partition  32G   0B   -2
>>
>
> Duplicate of #947806 ?
> Are you still using dmraid?
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>

Bug#969489: systemd: systemctl can hang up waiting for device nodes that are already mounted

[Joshua Hudson]

brw-rw 1 root disk 254, 2 Sep  3 14:51 /dev/mapper/isw_cfbejbfeib_Volume12

udevadm command output attached.

The device isn't dead. It works when accessed directly by name.

$ /sbin/swapon
NAMETYPE  SIZE USED PRIO
/dev/mapper/isw_cfbejbfeib_Volume12 partition  32G   0B   -2


udevadm
Description: Binary data

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Joshua Hudson]

I never had both at the same time. I toggled of auto eth0 when I put
the line into /etc/rc.local.

> If so, what happens if you just disable rc.local?

No network connection, and "auto eth0" causes 5 mins delay at boot.

On 4/26/20, Guus Sliepen  wrote:
> On Sun, Apr 26, 2020 at 01:09:06PM -0700, Joshua Hudson wrote:
>
>> I suspect it might be confusing since I filed two different eth0-related
>> bugs.
>>
>> In this particular instance, the DHCP server was live, and I could
>> have omitted the & from the line in rc.local and it would have come up
>> only a couple of seconds slower.
>
> Just to be sure, did you have both the /etc/rc.local file trying to run
> dhclient AND /etc/network/interfaces set to automatically bring up eth0?
> If so, what happens if you just disable rc.local?
>
> --
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 
>

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Joshua Hudson]

I suspect it might be confusing since I filed two different eth0-related bugs.

In this particular instance, the DHCP server was live, and I could
have omitted the & from the line in rc.local and it would have come up
only a couple of seconds slower.

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Joshua Hudson]

Hey I got lucky with a google search and found what would be a dupe if
it were ever finished.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805821

Somebody else managed to track the problem down.

For some reason systemd is only watching for /dev/dm-* rather than the
long dmraid device names. This is the equivalent of watching for
/dev/sda1 instead of the UUID.  Nikita Youshchenko:

> This way boot is ok (i.e. no delays and swap is enabled). But this is ugly 
> and unreliable.

This does work when there's only one raid array in the OS, which is
most of the time. These are two real devices (no symlinks) with the
same major and minor numbers.

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Joshua Hudson]

I double-checked with init=/bin/sh. All the devices already exist in
/dev/mapper before /linuxrc shuts down the initrd copy of udev.
systemd will never see the activation of a udev device because that's
already done. They're all active.

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Joshua Hudson]

That turned out to be really easy to track down. The reason you aren't
getting any notification of the raid array being activated is it was
already activated in initrd. It will not be activated a second time.

dmraid has some interesting principles in play here.

1) dmraid has its own idea of persistent, path-independent names of devices.
2) dmraid is incompatible with UUID= or LABEL=; all users of dmraid
must have the raid device names in /etc/fstab and on the kernel
command line. GRUB_LINUX_DISABLE_UUID *must* be used.
3) Under normal operation, dmraid is included in initrd as soon as it
is installed on the system.
4) If dmraid is installed in initrd, udev will discover the dmraid
devices before / is mounted. If udev discovers the dmraid devices, it
will start the system.
5) Redundant activations are not possible.

So the effect of all this is really simple. systemd can just assume
that a dmraid device under /dev/mapper is active if the device node
exists at all, and on any reasonable system it doesn't even need to
poll the device path; it can check *once* and know the success or
failure immediately.

Bug#947811: systemd: don't check *mounted* filesystems by default

[Joshua Hudson]

> If you want to fsck/mount your partitions manually via a custom script
that is run before init, then I would set passno to 0.

I've since masked the job that systemd uses to run fsck. It's still a
bug because if somebody forgets and leaves a filesystem mounted
read-write in the emergency shell (fixing anything other than fsck
problems in the emergency shell usually requires mounting things
read-write), the same problem happens and no custom script is
involved.

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Joshua Hudson]

>> Dec 31 08:27:23 nova dmraid-activate[554]: ERROR: Cannot retrieve RAID
set information for isw_cfbejbfeib_Volume1
> Have you further investigated those error messages?

I have now investigated and it's clearly spurious.

udev tries to run the following commands:

/sbin/dmraid-activate /dev/sda
/sbin/dmraid-activate /dev/sdb
/sbin/dmraid-activate sda
/sbin/dmraid-activate sdb

The first two are correct and succeed. The second two are not correct
and fail. The failure results in log spam.

> Have you tried with mdadm instead?

mdadm doesn't recognize the raid descriptor.

> udevadm info /dev/mapper/isw_cfbejbfeib_Volume14

output of this command for this device and all similar devices attached.
P: /devices/virtual/block/dm-0
N: dm-0
L: 0
S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume1
S: disk/by-id/dm-name-isw_cfbejbfeib_Volume1
S: android0
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: MAJOR=254
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=1701034
E: DM_UDEV_DISABLE_DM_RULES_FLAG=1
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=isw_cfbejbfeib_Volume1
E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume1
E: DM_SUSPENDED=0
E: ID_PART_TABLE_UUID=373c9bd5
E: ID_PART_TABLE_TYPE=dos
E: DEVLINKS=/dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume1 /dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume1 /dev/android0
E: TAGS=:systemd:

P: /devices/virtual/block/dm-1
N: dm-1
L: 0
S: android1
S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume11
S: disk/by-id/dm-name-isw_cfbejbfeib_Volume11
S: disk/by-uuid/d847c628-aa10-4bef-92b6-72ebacc07d7b
E: DEVPATH=/devices/virtual/block/dm-1
E: DEVNAME=/dev/dm-1
E: DEVTYPE=disk
E: MAJOR=254
E: MINOR=1
E: SUBSYSTEM=block
E: USEC_INITIALIZED=1707100
E: DM_UDEV_DISABLE_DM_RULES_FLAG=1
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=isw_cfbejbfeib_Volume11
E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume11
E: DM_SUSPENDED=0
E: ID_FS_UUID=d847c628-aa10-4bef-92b6-72ebacc07d7b
E: ID_FS_UUID_ENC=d847c628-aa10-4bef-92b6-72ebacc07d7b
E: ID_FS_VERSION=1.0
E: ID_FS_TYPE=ext3
E: ID_FS_USAGE=filesystem
E: DEVLINKS=/dev/android1 /dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume11 /dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume11 /dev/disk/by-uuid/d847c628-aa10-4bef-92b6-72ebacc07d7b
E: TAGS=:systemd:

P: /devices/virtual/block/dm-2
N: dm-2
L: 0
S: disk/by-id/dm-name-isw_cfbejbfeib_Volume12
S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume12
S: disk/by-uuid/baad791f-0ba2-4c87-92a1-0cd0ef4f7301
S: android2
E: DEVPATH=/devices/virtual/block/dm-2
E: DEVNAME=/dev/dm-2
E: DEVTYPE=disk
E: MAJOR=254
E: MINOR=2
E: SUBSYSTEM=block
E: USEC_INITIALIZED=1707179
E: DM_UDEV_DISABLE_DM_RULES_FLAG=1
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=isw_cfbejbfeib_Volume12
E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume12
E: DM_SUSPENDED=0
E: ID_FS_UUID=baad791f-0ba2-4c87-92a1-0cd0ef4f7301
E: ID_FS_UUID_ENC=baad791f-0ba2-4c87-92a1-0cd0ef4f7301
E: ID_FS_VERSION=1
E: ID_FS_TYPE=swap
E: ID_FS_USAGE=other
E: DEVLINKS=/dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume12 /dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume12 /dev/disk/by-uuid/baad791f-0ba2-4c87-92a1-0cd0ef4f7301 /dev/android2
E: TAGS=:systemd:

P: /devices/virtual/block/dm-3
N: dm-3
L: 0
S: android3
S: disk/by-id/dm-name-isw_cfbejbfeib_Volume13
S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume13
S: disk/by-uuid/5744b8b7-dcbf-48c4-868e-fb71fa65d456
E: DEVPATH=/devices/virtual/block/dm-3
E: DEVNAME=/dev/dm-3
E: DEVTYPE=disk
E: MAJOR=254
E: MINOR=3
E: SUBSYSTEM=block
E: USEC_INITIALIZED=1707545
E: DM_UDEV_DISABLE_DM_RULES_FLAG=1
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=isw_cfbejbfeib_Volume13
E: DM_UUID=DMRAID-isw_cfbejbfeib_Volume13
E: DM_SUSPENDED=0
E: ID_FS_UUID=5744b8b7-dcbf-48c4-868e-fb71fa65d456
E: ID_FS_UUID_ENC=5744b8b7-dcbf-48c4-868e-fb71fa65d456
E: ID_FS_VERSION=1.0
E: ID_FS_TYPE=ext3
E: ID_FS_USAGE=filesystem
E: DEVLINKS=/dev/android3 /dev/disk/by-id/dm-name-isw_cfbejbfeib_Volume13 /dev/disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume13 /dev/disk/by-uuid/5744b8b7-dcbf-48c4-868e-fb71fa65d456
E: TAGS=:systemd:

P: /devices/virtual/block/dm-4
N: dm-4
L: 0
S: disk/by-id/dm-uuid-DMRAID-isw_cfbejbfeib_Volume14
S: disk/by-uuid/c03a09e6-ff90-4803-bd7c-78e34e99457e
S: disk/by-id/dm-name-isw_cfbejbfeib_Volume14
S: android4
E: DEVPATH=/devices/virtual/block/dm-4
E: DEVNAME=/dev/dm-4
E: DEVTYPE=disk
E: MAJOR=254
E: MINOR=4
E: SUBSYSTEM=block
E: USEC_INITIALIZED=1708143
E: DM_UDEV_DISABLE_DM_RULES_FLAG=1
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=isw_cfbej

Bug#947811: systemd: don't check *mounted* filesystems by default

[Joshua Hudson]

#need_real_mtab
/dev/mapper/isw_cfbejbfeib_Volume11 / ext3 defaults 0 1
/dev/mapper/isw_cfbejbfeib_Volume12 none swap sw 0 0
none /tmp tmpfs defaults 0 0
/dev/mapper/isw_cfbejbfeib_Volume13 /home ext3 defaults 0 2
/dev/mapper/isw_cfbejbfeib_Volume14 /home/joshua/imagefiles ext3 defaults 0 3
/dev/sr0 /media/cdrom iso9660 noauto,ro,user 0 0
/dev/sr1 /media/cdrom1 iso9660 noauto,ro,user 0 0

Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot

[Joshua Hudson]

> Is there actually a pulseaudio daemon running?

yup.

> Where?

Not sure what this is supposed to mean.

> Is it managed by systemd?

I dunno how starting it at login is supposed to work.

client.conf:

autospawn = no

Ok this makes absolutely no sense at all. The problem went away when I
took ethernet device configuration away from systemd by masking off
all the networking stuff and sticking ifup -a & into /sbin/init. This
does make system boot a _lot_ faster.

Bug#947908: pulseaudio: sound doesn't play on first launch of pulseaudio at login; restarting it always results in working sound but will reoccur on next boot

[Joshua Hudson]

> Does `journalctl --user-unit pulseaudio.service` have anything to say?

Says "daemon already running" quite a few times.

> You can set the debug flags on daemon.conf to force it to verbose mode.

Spectacular:

E: [pulseaudio] pid.c: Daemon already running.
E: [pulseaudio] main.c: pa_pid_file_create() failed.

Must clear the log file every time.

$ grep -v '^$' /etc/pulse/daemon.conf | grep -v '^;' | grep -v '^#'
$ cat ~/.pulse/daemon.conf

exit-idle-time=-1
log-target=file:/home/joshua/.pulse/daemon.log
log-level=info
kill=yes

and aplay reports:

ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave
aplay: main:828: audio open error: No such file or directory

but writing directly to /dev/audio1 makes some noise

Bug#947807: systemd: can't install systemd when /etc/machine-id is a symbolic link to /dev/null

[Joshua Hudson]

# apt-get install systemd-sysv
[lots of junk]
Initializing machine ID from random generator.
Failed to truncate /etc/machine-id: Invalid argument

This is trivially verified by

# dpkg-reconfigure systemd
Initializing machine ID from random generator.
Failed to truncate /etc/machine-id: Invalid argument
#

Bug#947806: systemd doesn't like my raid, times out waiting for online partitions to come online, and can't continue boot

[Joshua Hudson]

To let the gravity of the but sink in, this is the pair of scripts
that I jammed in front of systemd that got it to somehow behave
itself:

/sbin/init:
#!/bin/sh

echo "INIT: rc init is in startup"

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

/etc/rc.earlyboot || PS1='init# ' PS2='init >' PS4='init +' exec /bin/sh -i

exec /lib/systemd/systemd

/etc/rc.earlyboot:
#!/bin/bash

exec 0<>/dev/tty1 1>&0 2>&1
chvt /dev/tty1

emergency()
{
echo "The previos command failed. Starting shell to investigate."
PS1='emergency# ' PS2='emergency> ' PS4='emergency+ ' /bin/bash
}

fsck -Asp
ERR=$?

if [ $((ERR & 2)) -ne 0 ]
thenecho "*** changed mounted filesystem, reboot requried ***"
sleep 3
reboot -f
fi

if [ $ERR -ne 0 ]
thenemergency
fi

mount / -o remount,rw || emergency
mount -a || emergency
swapon -a || emergency
exit 0

Bug#861053:

[Joshua Hudson]

The problem is /boot/grub/grub.cfg contains lines that look like:

  search --no-floppy --fs-uuid --set=root  
d847c628-aa10-4bef-92b6-72ebacc07d7b

search doesn't work because it starts the protected mode driver, which
finds multiple copies of the disk (because it's a full-disk RAID
array), selects one of them to try to use, and access it. Besides the
fact that this won't work very well if one of the disks were to
develop bad sectors, this is wrong because grub will later write to
the environment block, which resets the NVRAM flip-flop, causing the
automatic RAID resync to not work anymore.

The solution is to specify the device (hd0,1) explicitly everywhere
and never use any search directive anywhere in the config file. Device
hd0 uses bios 0x13 calls to access the disk, allowing the boot-time
RAID driver to do its job until the kernel is loaded.

Bug#861053:

[Joshua Hudson]

So the real problem is grub.cfg contains lines that look like this:

  search --no-floppy --fs-uuid --set=root  
d847c628-aa10-4bef-92b6-72ebacc07d7b

The probe tries to activate builtin protected-mode drivers, and the
drivers "work", so the probe finds two paths to the disk. Both of them
are wrong. In fact this error would be harmless, except for grub will
later write to the disk (the grub environment block). This desyncs the
RAID array.

The correct solution is to explicitly specify the driver is to be used.

Bug#946974: systemd: hang waiting for VM ethernet card to come online

[Joshua Hudson]

Forgive me if I'm not quite so sure, because this is the second time
I've had an undiagnosable problem where systemd appeared to be waiting
for something to start that was already started.

On my home system I had to roll back systemd altogether because it
would hang for many minutes on /home and never get it mounted, but
once logging in as root, fsck /home; mount /home worked the first
time. This was undiagnosable and the system was effectively
nonfunctional, so I had to roll it back immediately. Thankfully
jesse's sysvinit package was still in apt's cache.

Bug#943441: kolourpaint: Trying to draw transparent on a zoomed-in view does not work

[Joshua Hudson]

Package: kolourpaint
Version: 4:18.04.0-1
Severity: normal

Dear Maintainer,

1) Open PNG image
2) Zoom -> 800%
3) Select foreground color -> transparent
4) Select drawing tool (pen, line, and eraser (background color -> transparent) 
tried)
5) Try to draw on top of image

Drawing fails

Note that changing zoom back to 100% allows drawing, but changing to 800% again 
causes it to fail again.

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kolourpaint depends on:
ii  libc6   2.28-10
ii  libkf5configcore5   5.54.0-1+deb10u1
ii  libkf5configgui55.54.0-1+deb10u1
ii  libkf5configwidgets55.54.0-1
ii  libkf5coreaddons5   5.54.0-1
ii  libkf5guiaddons55.54.0-1
ii  libkf5i18n5 5.54.0-1
ii  libkf5iconthemes5   5.54.0-1
ii  libkf5kdelibs4support5  5.54.0-1
ii  libkf5sane5 18.12.1-1
ii  libkf5service-bin   5.54.0-1
ii  libkf5service5  5.54.0-1
ii  libkf5textwidgets5  5.54.0-1
ii  libkf5widgetsaddons55.54.0-1
ii  libkf5xmlgui5   5.54.0-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5printsupport5 5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-6

kolourpaint recommends no packages.

kolourpaint suggests no packages.

-- no debconf information

Bug#923200: libpolkit-qt5-1-1 depends on libpam-systemd

[Joshua Hudson]

Should I really have to provide an empty virtual package? I'm using
pam_group so sound keeps playing in bkg while current virtual console has
another user.

Bug#935853: nouveau.ko: kernel selects nouveau for GE108 GeForce1030 which does not support it

[Joshua Hudson]

Package: src:linux
Version: 4.19.37-5+deb10u2
Severity: important
File: nouveau.ko

Dear Maintainer,

I swapped out a failed graphics card for a NVidia GeForce 1030 GE108;
the kernel autodetected the nouveau driver and tried to use it, which
it cannot actually do, thus no video at bootup.

If I didn't already have SSH installed it would be a major problem
getting this machine running again.

Of course apt-get install nvidia-drivers fixes the problem, but try
running it blind (it displays UI).

-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=UUID=a85edf5f-b579-4184-82d3-dd430832dee2 ro quiet

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
[   11.110299] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[   11.114014] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[   11.114140] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address
[   11.114190] sp5100-tco sp5100-tco: Watchdog hardware is disabled
[   11.129435] snd_hda_intel :10:00.1: Disabling MSI
[   11.129443] snd_hda_intel :10:00.1: Handle vga_switcheroo audio client
[   11.137469] input: PC Speaker as /devices/platform/pcspkr/input/input7
[   11.171484] Intel(R) Wireless WiFi driver for Linux
[   11.171488] Copyright(c) 2003- 2015 Intel Corporation
[   11.176986] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-29.ucode (-2)
[   11.177133] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[   11.177305] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-29.ucode failed with error -2
[   11.177329] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-28.ucode (-2)
[   11.177499] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-28.ucode failed with error -2
[   11.177510] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-27.ucode (-2)
[   11.177711] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-27.ucode failed with error -2
[   11.178617] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-26.ucode (-2)
[   11.178787] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-26.ucode failed with error -2
[   11.178799] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-25.ucode (-2)
[   11.178962] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-25.ucode failed with error -2
[   11.178972] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-24.ucode (-2)
[   11.179218] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-24.ucode failed with error -2
[   11.179227] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-23.ucode (-2)
[   11.179375] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-23.ucode failed with error -2
[   11.179383] iwlwifi :1c:00.0: firmware: failed to load 
iwlwifi-3168-22.ucode (-2)
[   11.179523] iwlwifi :1c:00.0: Direct firmware load for 
iwlwifi-3168-22.ucode failed with error -2
[   11.179525] iwlwifi :1c:00.0: minimum version required: iwlwifi-3168-22
[   11.179655] iwlwifi :1c:00.0: maximum version supported: iwlwifi-3168-29
[   11.179858] iwlwifi :1c:00.0: check 
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
[   11.183023] Bluetooth: Core ver 2.22
[   11.183044] NET: Registered protocol family 31
[   11.183045] Bluetooth: HCI device and connection manager initialized
[   11.183051] Bluetooth: HCI socket layer initialized
[   11.183055] Bluetooth: L2CAP socket layer initialized
[   11.183065] Bluetooth: SCO socket layer initialized
[   11.202907] [drm] [nvidia-drm] [GPU ID 0x1000] Loading driver
[   11.202912] [drm] Initialized nvidia-drm 0.0.0 20160202 for :10:00.0 on 
minor 0
[   11.235391] usbcore: registered new interface driver btusb
[   11.236062] kvm: disabled by bios
[   11.241424] MCE: In-kernel MCE decoding enabled.
[   11.245226] EDAC amd64: Node 0: DRAM ECC disabled.
[   11.245229] EDAC amd64: ECC disabled in the BIOS or no ECC capability, 
module will not load.
Either enable ECC checking or force module loading by setting 
'ecc_enable_override'.
(Note that use of the override may cause unknown side effects.)
[   11.252034] Bluetooth: hci0: read Intel version: 370810225019140f00
[   11.252071] bluetooth hci0: firmware: failed to load 
intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq (-2)
[   11.252284] bluetooth hci0: Direct firmware load for 
intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq failed with error -2
[   11.252287] Bluetooth: hci0: failed to open Intel firmware file: 
intel/ibt-hw-37.8.10-fw-22.50.19.14.f.bseq (-2)
[   11.252465] bluetooth hci0: firmware: failed to load intel/ibt-hw-37.8.bseq 
(-2)
[   11.252767] bluetooth hc

Bug#931901:

[Joshua Hudson]

Adding RV635 to the list of affected cards

In this case, the card needs firmware, the firmware is on the disk,
but KMS remains disabled.

Bug#931901:

[Joshua Hudson]

Adding RV635 to the list of affected cards

Bug#923207: Turns out this bug is not fixed

[Joshua Hudson]

Turns out this bug is not fixed. I now have the following sneak dependency

lxsession -> lxsession-logout -> lxpolkit -> polkit-1 ->
libpam-systemd -> systemd-sysv

It looks like it was supposed to be

lxsession -> lxsession-logout -> polkit-1-auth-agent (lxpolkit ->
polkit-1 -> libpam-systemd -> systemd-sysv)

where polkit-1-auth-agent is a package swap point.

Bug#924445: I finally figured this one out

[Joshua Hudson]

pulseaudio exits by default when there's nothing connected to it.
However I have this line in ~/.pulse/default.pa

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1 auth-anonymous=1

So if the next program trying to use it is one of the programs  trying
to use it over TCP, it doesn't work.

Bug#930652: systemd removes static ipv4 address from ethernet sporadically

[Joshua Hudson]

I have attached a copy of /etc/network/interfaces. We're now waiting
for another recurrence.


interfaces
Description: Binary data

Bug#924445: pulseaudio crashes randomly, no diagnostic on terminal, possibly associated with Wesnoth

[Joshua Hudson]

Sorry for the long delay; looks like my spam filter ate the last reply.

Now looks like this on startup:
W: [pulseaudio] authkey.c: Failed to open cookie file
'/home/joshua/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key
'/home/joshua/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to open cookie file
'/home/joshua/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key
'/home/joshua/.config/pulse/cookie': No such file or directory
E: [pulseaudio] module-console-kit.c: GetSessionsForUnixUser() call
failed: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.ConsoleKit was not provided by any .service files
E: [pulseaudio] module.c: Failed to load module "module-console-kit"
(argument: ""): initialization failed.

pactl info now reports:

Server String: /tmp/pulse-ddOQt3aAAhE4/native
Library Protocol Version: 32
Server Protocol Version: 32
Is Local: yes
Client Index: 0
Tile Size: 65472
User Name: joshua
Host Name: nova
Server Name: pulseaudio
Server Version: 12.2
Default Sample Specification: s16le 2ch 44100Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-_00_1b.0.analog-stereo
Default Source: alsa_output.pci-_00_1b.0.analog-stereo.monitor
Cookie: [snip]

Bug#924445: pulseaudio crashes randomly, no diagnostic on terminal, possibly associated with Wesnoth

[Joshua Hudson]

Unfortunately there will never be a coredump because it's not crashing
in any usual sense. It just stops.

joshua@nova:~ϟ gdb pulseaudio
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from pulseaudio...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/pulseaudio
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
W: [pulseaudio] authkey.c: Failed to open cookie file
'/home/joshua/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key
'/home/joshua/.config/pulse/cookie': No such file or directory
[New Thread 0x7fffeb8c1700 (LWP 3287)]
[New Thread 0x7fffeb069700 (LWP 3288)]
W: [pulseaudio] authkey.c: Failed to open cookie file
'/home/joshua/.config/pulse/cookie': No such file or directory
W: [pulseaudio] authkey.c: Failed to load authentication key
'/home/joshua/.config/pulse/cookie': No such file or directory
E: [pulseaudio] module-console-kit.c: GetSessionsForUnixUser() call
failed: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.ConsoleKit was not provided by any .service files
E: [pulseaudio] module.c: Failed to load module "module-console-kit"
(argument: ""): initialization failed.
[Thread 0x7fffeb8c1700 (LWP 3287) exited]
[Thread 0x7fffeb069700 (LWP 3288) exited]
[Inferior 1 (process 3282) exited normally]
(gdb)

Long time between the E: lines mostly referencing a module that's in
the config file but not actually installed anymore and the failure.

Bug#780768:

[Joshua Hudson]

On a desktop wired LAN that's just ridiculous. Since then and another
really dumb bug I tore out NetworkManager.

Bug#861783: dpkg: trying to local divert a file diverted by a package does not work

[Joshua Hudson]

(If the suggestions below end up not being accepted, then you could
simply use your local firefox, and create a dummy package to fulfill
dependencies with something like equivs.)

Ah yes I suppose I was not clear. The firefox-esr package causes all
its depends to be installed, which is what allows the local firefox to
run; otherwise the local firefox would have a host of missing depends.

Bug#861004: closed by Guido Günther (Re: Bug#861004: git-buildpackage: gbp buildpackage fails with nonsense errors when binary files have changed since last release)

[Joshua Hudson]

I expect the tool to treat the provided git repository as the master
source. This should result in not needing to fetch a source tarball at
all.

This tool was recommended to me for how to update a debian package to
take a new upstream source. Apparently it can't actually do that.

Bug#653959: citadel-server was auto-selected and installed by dist-upgrade for what appears to be no good reason, and apt-get purge citadel-server failed to back out all system changes

[Joshua Hudson]

Apt-get dist-upgrade should not be installing new auto-start publicly
listening services.

On Tuesday, January 24, 2017, Michael Meskes  wrote:

> severity normal
> thanks
>
> On Sun, Jan 01, 2012 at 02:42:07PM -0800, Joshua wrote:
> > Source: citadel-server
> > Version: wheezy
> > Severity: serious
> > Tags: security
> > Justification: Policy 3.5
> >
> > apt-get dist-upgrade decided to install citadel-server (no I didn't know
> what it was) for who-knows-what reason.
> > Install created a new publicly listening service (never a good thing
> security-wise)
> > Install created a new user & group
> > an immediate apt-get purge citadel-server failed to back out the
> user,group,extra directories in /var
>
> Sorry for the very late reply, but I did not see this report in my list
> before earlier this week.
> Chances are you don't even remember the details anymore, but in case you
> do,
> which directory was not deleted? This seems to be the only real bug in
> here.
>
> Michael
> --
> Michael Meskes
> Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> Meskes at (Debian|Postgresql) dot Org
> Jabber: michael at xmpp dot meskes dot org
> VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
>

Bug#839551:

[Joshua Hudson]

Patch included; I sent the same patch upstream but they seem checked out.

diff -ru stock/rdesktop-1.8.3/doc/rdesktop.1 work/rdesktop-1.8.3/doc/rdesktop.1
--- stock/rdesktop-1.8.3/doc/rdesktop.1 2016-10-01 12:21:55.0 -0700
+++ work/rdesktop-1.8.3/doc/rdesktop.1  2016-10-01 13:47:33.913176792 -0700
@@ -63,15 +63,18 @@
 so its use is discouraged.
 .TP
 .BR "-g "
-Desktop geometry (WxH). If geometry is the special word "workarea",
the geometry
-will be fetched from the extended window manager hints property
_NET_WORKAREA, from
-the root window. The geometry can also be specified as a percentage
of the whole
-screen, e.g. "-g 80%".
-
+Desktop geometry (WxH[@DPI][+X[+Y]]). If geometry is the special word
+"workarea", the geometry will be fetched from the extended window
+manager hints property _NET_WORKAREA, from the root window. The geometry
+can also be specified as a percentage of the whole screen, e.g. "-g 80%".
 If the specified geometry depends on the screen size, and the screen
 size is changed, rdesktop will automatically reconnect using the new
 screen size. This requires that rdesktop has been compiled with RandR
 support.
+
+The optional DPI parameter should be specified if the screen rdesktop
+is being displayed on is too far from 96 DPI for unscaled Windows to
+be readable. Windows currently accepts values from 96 to 480.
 .TP
 .BR "-i"
 Use password as smartcard pin. If a valid user certificate is matched
in smart card
@@ -123,6 +126,11 @@
 Do not send mouse motion events.  This saves bandwidth, although some Windows
 applications may rely on receiving mouse motion.
 .TP
+.BR "-M"
+Use the local X cursor rather than the one from the remote machine.
This is most
+useful with "-m" but has other uses. If running with no window manager, use
+xsetroot(1) to set a useful cursor first.
+.TP
 .BR "-C"
 Use private colourmap.  This will improve colour accuracy on an 8-bit display,
 but rdesktop will appear in false colour when not focused.
diff -ru stock/rdesktop-1.8.3/rdesktop.c work/rdesktop-1.8.3/rdesktop.c
--- stock/rdesktop-1.8.3/rdesktop.c 2016-10-01 12:21:55.0 -0700
+++ work/rdesktop-1.8.3/rdesktop.c  2016-10-01 13:41:59.146946782 -0700
@@ -72,6 +72,7 @@
   requested. If 1, the geometry will be fetched
   from _NET_WORKAREA. If negative, absolute 
value
   specifies the percent of the whole screen. */
+int g_dpi = 0; /* device DPI: default not set */
 int g_width = 800;
 int g_height = 600;
 int g_xpos = 0;
@@ -97,6 +98,7 @@
 RD_BOOL g_polygon_ellipse_orders = True;   /* polygon / ellipse orders */
 RD_BOOL g_fullscreen = False;
 RD_BOOL g_grab_keyboard = True;
+RD_BOOL g_local_cursor = False;
 RD_BOOL g_hide_decorations = False;
 RDP_VERSION g_rdp_version = RDP_V5;/* Default to version 5 */
 RD_BOOL g_rdpclip = True;
@@ -190,7 +192,7 @@
fprintf(stderr, "   -p: password (- to prompt)\n");
fprintf(stderr, "   -n: client hostname\n");
fprintf(stderr, "   -k: keyboard layout on server (en-us, de, sv, 
etc.)\n");
-   fprintf(stderr, "   -g: desktop geometry (WxH)\n");
+   fprintf(stderr, "   -g: desktop geometry (WxH[@dpi])\n");
 #ifdef WITH_SCARD
fprintf(stderr, "   -i: enables smartcard authentication, password
is used as pin\n");
 #endif
@@ -204,6 +206,7 @@
fprintf(stderr, "   -e: disable encryption (French TS)\n");
fprintf(stderr, "   -E: disable encryption from client to server\n");
fprintf(stderr, "   -m: do not send motion events\n");
+   fprintf(stderr, "   -M: use local mouse cursor\n");
fprintf(stderr, "   -C: use private colour map\n");
fprintf(stderr, "   -D: hide window manager decorations\n");
fprintf(stderr, "   -K: keep window manager key bindings\n");
@@ -579,7 +582,7 @@
 #define VNCOPT
 #endif
while ((c = getopt(argc, argv,
-  VNCOPT 
"A:u:L:d:s:c:p:n:k:g:o:fbBeEitmzCDKS:T:NX:a:x:Pr:045h?")) != -1)
+  VNCOPT 
"A:u:L:d:s:c:p:n:k:g:o:fbBeEitmMzCDKS:T:NX:a:x:Pr:045h?")) != -1)
{
switch (c)
{
@@ -694,6 +697,16 @@
p++;
}

+   if (*p == '@')
+   {
+   g_dpi = strtol(p + 1, &p, 10);
+   if (g_dpi <= 0)
+   {
+   error("invalid geometry\n");
+   return EX_USAGE;
+   }
+   }
+
if (*p == '+' || *p == '-')
{
g_pos |= (*p == '-') ? 2 : 1;
@@ -731,6 +744,8 @@
case 'm

Bug#827388: systemd: systemctl restart winbind starts a broken winbind

[Joshua Hudson]

In this case, the init script has restart != stop + start. Had systemd
called restart it probably would have worked.

On 6/15/16, Felipe Sateler  wrote:
> Control: reassign -1 winbind 2:4.1.17+dfsg-2+deb8u2
>
> On 15 June 2016 at 11:52, Joshua Hudson  wrote:
>> Package: systemd
>> Version: 215-17+deb8u4
>> Severity: important
>>
>> # systemctl restart winbind (to get it to reread its config file) starts
>> a
>> broken winbind, apparently because ti doesn't ensure the previous copy
>> shut down cleanly first. winbind is a multi-process daemon and it looks
>> like systemd only kills the root process; this would cause the new copy
>> to have trouble starting up. The old processes are visible in ps for a
>> long time.
>>
>> Repeatedly running systemctl restart winbind eventually works; however
>> this is a real pain to figure out when winbind is not functioning for
>> some other reason. (In this case the clock had wandered out of range.)
>
> Systemd cannot assume it can kill all processes, unless the service
> declares that. Currently winbind does not have a native systemd
> service, but an init script. Thus, the init script should ensure
> winbind is really exited before returning.
>
> This is a bug in the winbind init script. Thus reassigning to winbind.
>
> --
>
> Saludos,
> Felipe Sateler
>

Bug#743215: write: you are uid ???, but your login is as uid 0

[Joshua Hudson]

I am astounded at your inability to understand this.

# su -c 'write root' | cat

will fail because write is running as bin and checks who owns standard
output for a match or not. Now this is a pretty perverse example.

There's a breaking change in systemd's cron where the standard output
spooler is now owned by root rather than the runas user. write is
checking for this and falling down.

Yes, pipes have owners. If you know what fstat() does you know this.

Bug#788631: /sbin/mkfs.minix: mkfs.minix hang/infinite loop

[Joshua Hudson]

Bug is FIXED in util-linux 2.27

Bug#791430: udev tries to make /dev/sr? nodes only when cdrom in drive, causing problems

[Joshua Hudson]

I booted directly to a shell and started the system by hand. After
mounting devtmpfs, /dev/sr? were not created. Started udevd and they
were.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#791430: udev tries to make /dev/sr? nodes only when cdrom in drive, causing problems

[Joshua Hudson]

Update: problem disappeared after cold boot. Additional information
gained from experiment:

devtmpfs does not create /dev/sr? nodes on this system. udevd does once started.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#791430: udev tries to make /dev/sr? nodes only when cdrom in drive, causing problems

[Joshua Hudson]

Devices not created by kernel. Verified by stopping udev.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#791430: udev tries to make /dev/sr? nodes only when cdrom in drive, causing problems

[Joshua Hudson]

It is important to note that without the device node, attempting to
eject /dev/sr0 or /dev/sr1 is going to fail. Some (notably apple)
cdroms don't have eject buttons.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#788631: Info received (Bug#788631: /sbin/mkfs.minix: mkfs.minix hang/infinite loop)

[Joshua Hudson]

Ok I was able to replace the patch with an error message. I changed
the inodes per block to be more reasonable w/ large filesystems while
I was at it. I'll be sending the patch upstream as well.
--- disk-utils/mkfs.minix.c.orig	2015-06-20 13:50:45.509325736 -0700
+++ disk-utils/mkfs.minix.c	2015-06-20 20:27:11.732436640 -0700
@@ -49,6 +49,9 @@
  * 06.29.11  -  Overall cleanups for util-linux and v3 support
  *  Davidlohr Bueso 
  *
+ * 06.20.15  -  Do not infinite loop or crash on large devices
+ *  Joshua Hudson 
+ *
  * Usage:  mkfs [-c | -l filename ] [-12v3] [-nXX] [-iXX] device [size-in-blocks]
  *
  *	-c for readablility checking (SLOW!)
@@ -504,9 +507,16 @@
 	super_set_nzones();
 	zones = get_nzones();
 
-	/* some magic nrs: 1 inode / 3 blocks */
-	if ( req_nr_inodes == 0 ) 
-		inodes = BLOCKS/3;
+	/* some magic nrs: 1 inode / 3 blocks for smaller filesystems,
+	 * for one inode / 16 blocks for large ones. mkfs will eventually
+	 * crab about too far when getting close to the maximum size. */
+	if ( req_nr_inodes == 0 )
+		if (BLOCKS > 2048 * 1024) /* 2GB */
+			inodes = BLOCKS/16;
+		else if (BLOCKS > 512 * 1024) /* 0.5GB */
+			inodes = BLOCKS/8;
+		else
+			inodes = BLOCKS/3;
 	else
 		inodes = req_nr_inodes;
 	/* Round up inode count to fill block size */
@@ -526,6 +536,12 @@
 	}
 
 	super_set_map_blocks(inodes);
+	if (first_zone_data() >= 65536)
+		errx(MKFS_EX_ERROR, _("First data block at %jd, which is too far"
+			" (max 65535).\n"
+			"Try specifying fewer inodes by passing -i##.\n"),
+			first_zone_data());
+			
 	imaps = get_nimaps();
 	zmaps = get_nzmaps();
 
@@ -793,6 +809,8 @@
 	} else /* fs_version == 1 */
 		if (BLOCKS > MINIX_MAX_INODES)
 			BLOCKS = MINIX_MAX_INODES;
+	if (BLOCKS > 4 + 65531 * BITS_PER_BLOCK)
+		BLOCKS = 4 + 65531 * BITS_PER_BLOCK; /* Utter maximum: Clip. */
 	setup_tables();
 	if (check)
 		check_blocks();

Bug#788631: /sbin/mkfs.minix: mkfs.minix hang/infinite loop

[Joshua Hudson]

I found the exact cause after reading the source code long enough. It
tried to allocate too many inodes, pushing the first zone > 65536
blocks. This fails hard due to integer roundoff.

Therefore, workaround: mkfs.minix -3 -i specifying a more
reasonable number of inodes will allow the filesystem to be created.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#788631: /sbin/mkfs.minix: mkfs.minix hang/infinite loop

[Joshua Hudson]

Update: bug is in the V3 code. Command goes through w/o using -3.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#680929: Got bug, can reproduce 100% of the time

[Joshua Hudson]

Affected: Debian Jessie i386

Qt: 4.8.6
KDE Development Platform: 4.14.2
Okular: 0.20.2

Reproduces 100% of the time. I am logged in over remote desktop.
Desktop snapshot provided in case you need to verify remote desktop.

Bug#743215: I managed to figure out what's going on

[Joshua Hudson]

I managed to figure out what's going on.

write tries to use standard output to determine who the currently
logged on user is. Traditional cron would have stdout captured by a
spool running as a user process; however systemd cron would have it
captured by a systemd process running as root.

While you cannot write as another user in any case, you could
traditionally use write in a cron job as it spools to you. Now it
doesn't work. It's really easy to knock this check out of write.c in
bsdmainutils; however it's a bit harder to get it to do the right
thing.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781869: pulseaudio: sound total hangup when program using audio suddenly dies

[Joshua Hudson]

> Does pulseaudio get unstuck by doing another roundtrip to tty2?

Nope. I haven't found an unstick short of X logoff-logon. Killing
pulseaudio does not unstick.

Will try pull from experimental soon.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781869: pulseaudio: sound total hangup when program using audio suddenly dies

[Joshua Hudson]

> The second is that when you return to X your sound does not return.
This is the bug that needs debugging.

Output of getfacl suggests permissions are being restored correctly
but pulseaudio is getting stuck by the transient. Given the
statistical nature of the inital repro with same user on TTY2, I
suggest the transient is there even when switching between two
same-users sessions but is often too fast for pulseaudio to get stuck.

joshua@nova:~ϟ getfacl /dev/snd/*
# file: dev/snd/by-path
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/controlC1
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/hwC0D0
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/hwC1D0
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D3p
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D0c
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D0p
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D1p
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D2c
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:joshua:rw-
group::rw-
mask::rw-
other::---


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781869: pulseaudio: sound total hangup when program using audio suddenly dies

[Joshua Hudson]

On further diagnostic (now that we know for sure what we are looking
for), the user logged in to TTY2 is relevant. This eliminates the
statistical match for a hard match to the problem. If the TTY is
logged in as root or not logged in, happens every time.

I'm in the habit of doing all root work directly from text consoles
(no X as root for the obvious reason). This is actually more secure
than sudo as an X key sniffer can never grab the root password. A
program that requires X doesn't get root. I make no exceptions except
xterm (testing X config files).

I think this is still a direct bug. Users able to play sound ought to
be the sum of all logged-in users on all TTY sessions (X or text), not
just the current one.

I'm adding my user to audio group for now.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781869: pulseaudio: sound total hangup when program using audio suddenly dies

[Joshua Hudson]

Indeed. chmod 666 /dev/snd/* makes the problem go away.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781869: pulseaudio: sound total hangup when program using audio suddenly dies

[Joshua Hudson]

Hmmm. systemd-logind is running. Maybe we got a genuine systemd bug
that I tried to avoid by not upgrading init. If I just pin the ACLs at
666 (this is safe on a single-user box) and the problem goes away
would that confirm where to look?

I miss the old "console" group. A much simpler solution.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781869: pulseaudio: sound total hangup when program using audio suddenly dies

[Joshua Hudson]

s/Killing pulseaudio/Killing and restarting pulseaudio/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#779002: closed by Michael Gilbert (Re: [pkg-wine-party] Bug#779002: wine32 sound does not work on amd64 arch)

[Joshua Hudson]

I'd advise setting a package recommends as having to file a bug to
find it is pretty silly.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770139: Fwd: Bug#770139: lilo chokes on dmraid mirroring

[Joshua Hudson]

patch provided. You probably don't want to apply it as-is as it breaks
other scenarios. I had to completely remove devicemapper support to
make it work.

It would be completely feasible to make it a compile option and
provide two binary packages, but that would be more of a headache.
diff -ur lilo-23.2/src/config.h lilo-23.2.mine/src/config.h
--- lilo-23.2/src/config.h	2006-12-16 17:55:12.0 -0800
+++ lilo-23.2.mine/src/config.h	2014-11-17 19:51:24.0 -0800
@@ -13,6 +13,8 @@
 #ifndef CONFIG_H
 #define CONFIG_H
 
+#undef HAS_LIBDEVMAPPER_H
+
 /* undefine LCF_DEVMAPPER if the library is not present */
 #ifdef LCF_DEVMAPPER
 # ifndef HAS_LIBDEVMAPPER_H
diff -ur lilo-23.2/src/device.c lilo-23.2.mine/src/device.c
--- lilo-23.2/src/device.c	2014-11-17 20:20:38.0 -0800
+++ lilo-23.2.mine/src/device.c	2014-11-17 20:28:23.0 -0800
@@ -924,8 +924,8 @@
 if (is_dm_major(major)) {
 #ifndef LCF_DEVMAPPER
 warn("device-mapper (%d) referenced in " PARTITIONS ",\n"
- "   but LILO is configured without DEVMAPPER option.  Skipping device.", major);
-continue;
+ "   but LILO is configured without DEVMAPPER option.", major);
+		/* This might be safe. */
 #endif
 }
 else if ((major>=60 && major<=63) || (major>=120 && major<=127) ) {
@@ -1307,10 +1307,13 @@
 #if BETA_TEST
 		if (verbose>=3) printf("J=%d  K=%d\n", j, k);
 #endif
+#if 0
+/* This check is simply wrong */
 		if (j<0 && k>=0) {
 		die("Devices %04X and %04X are assigned to BIOS 0x%02X",
 			vm[k].device, walk->device, bios+0x80);
 		}
+#endif
 	}
 	codes |= 1L << bios;	
 	}
diff -ur lilo-23.2/src/geometry.c lilo-23.2.mine/src/geometry.c
--- lilo-23.2/src/geometry.c	2011-04-09 08:03:29.0 -0700
+++ lilo-23.2.mine/src/geometry.c	2014-11-17 20:31:58.0 -0800
@@ -721,7 +721,7 @@
 	if (ioctl(fd,HDIO_GETGEO,&hdprm) < 0)
 		die("geo_query_dev HDIO_GETGEO (dev 0x%04x): %s",device,
 		  strerror(errno));
-	if (all && !hdprm.sectors)
+	if (all && !hdprm.sectors && (!geo->sectors || !geo->cylinders || !geo->heads))
 		die("HDIO_REQ not supported for your DAC960/IBM controller. "
 		  "Please use a DISK section");
 	geo->heads = hdprm.heads;

Bug#226171: patch

[Joshua Hudson]

Patch for this bug is in bug 770139.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#680649: linux-image-3.0.0-1-amd64: Restoring from hibernate requires rerunning /etc/init.d/kbd start manually to fix broken consoles

[Joshua Hudson]

Package version changed from 3.0.0-2 to 3.0.0.3.

Incidentally I have upgraded to 3.2 and the problem does not occur there either.

On 7/7/12, Jonathan Nieder  wrote:
> Hi,
>
> Joshua Hudson wrote:
>
>> For some reason a new apt-get dist-upgrade fixed bug. A new kernel
>> package was pulled but the version did not change.
>
> You can get the version of the kernel package with
>
>   dpkg-query -W linux-image-$(uname -r)
>
> or
>
>   cat /proc/version
>
> Perhaps the package name (which includes an ABI name like
> "3.0.0-1-amd64") did not change but the version number (e.g. 3.0.0-3)
> did change.
>
> Glad to hear your system is working again.  Please don't forget that
> the packaged 3.0.y kernels are way out of date, though.
>
> Ciao,
> Jonathan
>
> [*]
> http://kernel-handbook.alioth.debian.org/ch-versions.html#s-version-types
>



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#680649: linux-image-3.0.0-1-amd64: Restoring from hibernate requires rerunning /etc/init.d/kbd start manually to fix broken consoles

[Joshua Hudson]

For some reason a new apt-get dist-upgrade fixed bug. A new kernel
package was pulled but the version did not change.

On 7/7/12, Jonathan Nieder  wrote:
> Hi,
>
> Joshua wrote:
>
>> Version: 3.0.0-3
> [...]
>> I have some nonstandard console settings that require running
>> /etc/init.d/kbd to configure console.  Using the newer console-setup
>> is a non-starter for reasons that are not relevant at this time.
>>
>> Somewhere in the last two months (it's hard to tell exactly), there
>> was a regression such that after restoring from hibernate, some
>> console settings are not restored correctly. Running /etc/init.d/kbd
>> start successfully restores them.
>
> Thanks for reporting.  Before investigating further, a few questions:
>
> The Debian kernel team does not maintain 3.0.y any more.  Does a 3.2.y
> or 3.4.y kernel reproduce the problem?
>
> You mentioned that this is a regression.  What is the oldest broken
> kernel and newest non-broken one you know of?  (/var/log/dpkg.log
> might help to jog memory, and there are precompiled historical kernels
> at http://snapshot.debian.org/ if you need to test some.)
>
> Can you more precisely describe the symptoms?  If I had the same
> hardware as you, what steps should I perform to reproduce the bug,
> what is the expected result, what happens instead, and how does the
> difference indicate a bug?
>
> Hope that helps,
> Jonathan
>



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#647153:

[Joshua Hudson]

Fix as provided in upstream does not work.

I had to re-apply my original patch to work.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#53829:

[Joshua Hudson]

Herein lies the problem. I managed to move the location to
/run/mount/mtab by changing the value of the #define, but that leaves
no upgrade path from /proc/mounts due to the bizarre code in
/lib/init/mount-functions.sh. The migration should have happened at
package install time, not boot time.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#53829:

[Joshua Hudson]

With the change to implement /run in squeezy, we can now move mtab off of /etc.

Right now, the system is using /etc/mtab -> /proc/mounts.

I have found a number of tools (not all debian based) that do
fopen("/etc/mtab", "r+") and disregard /etc/mtab if it cannot be
opened as a way of verifying the contents are valid. Consequence is
this is now risking data corruption.

I thought I had a working patch, but it wasn't working yet.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#653959: citadel-server was auto-selected and installed by dist-upgrade for what appears to be no good reason, and apt-get purge citadel-server failed to back out all system changes

[Joshua Hudson]

fiddling around with aptitude why revealed the haul-in is quilt
recommending mail-transport-agent

another case of the build tools requesting something absolute
nonsense. Last time around it was postgres, this time it was citadel

On 1/1/12, Joshua  wrote:
> Source: citadel-server
> Version: wheezy
> Severity: serious
> Tags: security
> Justification: Policy 3.5
>
> apt-get dist-upgrade decided to install citadel-server (no I didn't know
> what it was) for who-knows-what reason.
> Install created a new publicly listening service (never a good thing
> security-wise)
> Install created a new user & group
> an immediate apt-get purge citadel-server failed to back out the
> user,group,extra directories in /var
>
> Dear Maintainer,
> *** Please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these lines ***
>
>
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
>
>
>



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#603885:

[Joshua Hudson]

Appears to be fixed in iceweasel-6.0



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#625801: Fwd: Bug#625801: apt should allow remove package depended on by metapackage and keep metapackage

[Joshua Hudson]

-- Forwarded message --
From: Joshua Hudson 
Date: Sat, May 7, 2011 at 9:49 AM
Subject: Re: Bug#625801: apt should allow remove package depended on
by metapackage and keep metapackage
To: Julian Andres Klode 


Well this is rather brutal but definitely gets the job done.


apt-holepunch
Description: Binary data

Bug#603885: Fwd: Bug#603885: iceweasel: right click on link sometimes doesn't work

[Joshua Hudson]

Bug is easily triggered by right-clicking on one of the initial links
of the homepage before doing anything else (click the titlebar first
if the window doesn't have focus).

Bug does not occur in firefox 3.6 compiled fresh from Mozilla.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org