Bug#1072187: systemd: root fs read only if /tmp is in fstab

[David Burrows]

Package: systemd
Version: 256~rc3-5
Severity: important
X-Debbugs-Cc: burrows...@gmail.com

Dear Maintainer,

Installing this update led to my system booting with root (btrfs)
mounted as read only.

In my fstab I have the following:
tmpfs /tmp   tmpfs   
defaults,noatime,mode=1777 0 0

Commenting this out allowed the system to boot again with read/write.

In order to restore tmpfs I had to do the following (as root):
cp /usr/lib/systemd/system/tmp.mount /usr/share/systemd/tmp.mount

The is optional if you wish to have /tmp on root.

Prior to doing this it appears there is a broken symlink:
$ ls -l /etc/systemd/system/tmp.mount
lrwxrwxrwx 1 root root 28 Dec 30  2022 /etc/systemd/system/tmp.mount -> 
/usr/share/systemd/tmp.mount

I'm guessing that tmp in fstab is no longer default, but I didn't put it
there and it must be left over from an older install. This is consistent with
another 3 systems of mine.


-- Package-specific info:

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.10-1-siduction-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 systemd depends on:
ii  libacl12.3.2-2
ii  libapparmor1   3.0.13-2
ii  libaudit1  1:3.1.2-2.1
ii  libblkid1  2.40.1-2
ii  libc6  2.38-11
ii  libcap21:2.66-5
ii  libcryptsetup122:2.7.2-2
ii  libfdisk1  2.40.1-2
ii  libmount1  2.40.1-2
ii  libpam0t64 [libpam0g]  1.5.3-4
ii  libseccomp22.5.5-1
ii  libselinux13.5-2+b2
ii  libssl3t64 3.2.1-3
ii  libsystemd-shared  256~rc3-5
ii  libsystemd0256~rc3-5
ii  mount  2.40.1-2

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-4+b1
ii  libzstd1 1.5.5+dfsg2-2
ii  systemd-timesyncd [time-daemon]  256~rc3-5

Versions of packages systemd suggests:
ii  libgcrypt20 1.10.3-3
ii  libidn2-0   2.3.7-2
ii  liblz4-11.9.4-2
ii  liblzma55.6.1+really5.4.5-1
ii  libtss2-rc0t64  4.1.0-1
ii  libtss2-tcti-device0t64 [libtss2-tcti-device0]  4.1.0-1
ii  polkitd 124-2
pn  systemd-boot
ii  systemd-container   256~rc3-5
pn  systemd-homed   
ii  systemd-resolved256~rc3-5
pn  systemd-userdbd 

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4+b1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 256~rc3-5
ii  libpam-systemd 256~rc3-5
ii  udev   256~rc3-5

-- no debconf information

Bug#306820: ppp in on demand mode hangs with tcsetattr: Invalid argument error

[David Burrows]

Hi,

I am also getting this error with kernel 2.6.11.7 and dialup modem (USB
ISDN).  The problem is with persist or demand, first connection goes
through fine, reconnection fails with tcsetattr error.  I am using latest
Debian sid tree.  Downgrading ppp to version 2.4.2+20040428-6 seems to
resolve the problem.  All versions after that one have this problem.  I
did some further debugging and discovered that the first time the
connection goes around the fd is 7, the next time it goes to reconnect the
fd increases to 8.  This might be normal, I'm not sure whats going on.

Thanks for your time,

David Burrows.

Bug#306820: ppp in on demand mode hangs with tcsetattr: Invalid argument error

[David Burrows]

 On May 02, David Burrows [EMAIL PROTECTED] wrote:

 did some further debugging and discovered that the first time the
 connection goes around the fd is 7, the next time it goes to reconnect
 the
 fd increases to 8.  This might be normal, I'm not sure whats going on.
 This bug should be fixed by the patch from #306261, but I'm not sure if
 it's the same issue of #306820.

Unfortunately this patch did not resolve the problem.  I think you're
right, it may be a different issue to #306820.  On further investigation
my syslog actually says:

May  2 09:31:14 shed pppd[8131]: Starting link
May  2 09:31:14 shed pppd[8131]: tcgetattr: No such device or address
(line 909)
May  2 09:31:15 shed pppd[8131]: tcsetattr: No such device or address
(line 1003)
May  2 09:31:15 shed pppd[8131]: Exit.

Only thing which might be different is I'm using the cdc_adm driver, and
/dev/ttyACM0.

If I downgrade to 2.4.2+20040428-6 it works fine.  Also if I type pon
again it reconnects fine.  I've tried to do a bit of debugging myself, but
all I can tell is the reconnect case is a different codepath to the
original connect.  And its getting confused somewhere with fds, or perhaps
opening the same device node twice.

David.