Re: procps with sysvinit: libsystemd0 vs libelogind0
In article , David Wright wrote: > On Mon 16 Oct 2023 at 16:05:48 (-0700), Bill Brelsford wrote: >> The latest version of procps (2:4.0.4-2) depends on libsystemd0, so >> upgrading 2:4.0.3-1 to it causes libsystemd0 to be installed. But >> on my sysvinit system it conflicts with libelogind0: >> >> libelogind0 : Conflicts: libsystemd0 but 254.5-1 is to be installed > > At least in 246.10, libelogind0 should also replace and provide > libsystemd0, which means APT shouldn't try to install libsystemd0. > > Is it possible that you've unluckily updated your lists while > the repository was being updated, in which case, a brief wait > and then re-updating might fix the problem. That wasn't the problem, David, but it pointed me to it. procps requires libsystemd0 >= 254~rc1, but libelogind0 is still 246.10-1debian1 and provides libsystemd0 246.10. I need to be patient and wait for libelogind0 to be updated. Thanks.. Bill
procps with sysvinit: libsystemd0 vs libelogind0
The latest version of procps (2:4.0.4-2) depends on libsystemd0, so upgrading 2:4.0.3-1 to it causes libsystemd0 to be installed. But on my sysvinit system it conflicts with libelogind0: libelogind0 : Conflicts: libsystemd0 but 254.5-1 is to be installed Should I let libsystemd0 replace libelogind0? I don't remember if that would cause other problems. Thanks.. Bill
Re: Shutdown delay with LVM and disk encryption (SysV, buster)
On Sat Aug 31 2019 at 03:40 PM +0200, Stefan Krusche wrote: > Am Freitag, 30. August 2019 schrieb Bill Brelsford: > > My 64-bit buster installation was created using its installer, with > > / and /home partitions in an encrypted logical volume (sda3_crypt). > > On shutdown, it pauses near the end with > > > > Stopping remaining crypto disks... sda3_crypt (busy) sda3_crypt > > busy... > > > > The busy messages continue for about 30 seconds, after which it > > indicates "Failed" in red (I think, it happens fast) and shuts down > > in a second or two. > > > > If I change to systemd, shutdown is fast (no delay). > > > > This appears to be similar to earlier bugs, e.g. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792552, > > except that they hung indefinitely. > > > > Anyone else seeing this? Any suggestions or workarounds (other > > than systemd)? Thanks.. > > Hello Bill, > > this behaviour had been discussed here, I think: > > https://dev1galaxy.org/viewtopic.php?pid=11522#p11522 > > In that thread and others on that forum there are a couple of links to > other threads etc. about this issue. > > The proposed solution is a patch which originated here: > > https://bugs.devuan.org//cgi/bugreport.cgi?bug=237 > > …which I have applied on my system (devuan/ascii) and never seen this > problem again. Thanks, Stefan -- that fixed it! The cryptdisks-functions file no longer contains the "local dst .." line, on buster anyway -- I inserted a "local vgs vg" line. Total shutdown time now about 7 seconds.. Regards.. Bill
Shutdown delay with LVM and disk encryption (SysV, buster)
My 64-bit buster installation was created using its installer, with / and /home partitions in an encrypted logical volume (sda3_crypt). On shutdown, it pauses near the end with Stopping remaining crypto disks... sda3_crypt (busy) sda3_crypt busy... The busy messages continue for about 30 seconds, after which it indicates "Failed" in red (I think, it happens fast) and shuts down in a second or two. If I change to systemd, shutdown is fast (no delay). This appears to be similar to earlier bugs, e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792552, except that they hung indefinitely. Anyone else seeing this? Any suggestions or workarounds (other than systemd)? Thanks.. -- Bill Brelsford wbr...@k2di.net
Re: udev (without systemd) fails to find devices
On Wed Sep 12 2018 at 10:10 PM +0200, Sven Joachim wrote: > On 2018-09-11 19:05 -0700, Bill Brelsford wrote: > > > I recently upgraded the sid installation on an i386 machine. With > > udev upgraded to 239-8, many devices are no longer detected during > > boot, e.g. usb, network card, video, audio. I also have a > > not-upgraded buster partition on the same machine -- a large > > portion of its dmesg output is simply missing from sid's dmesg. > > Maybe udevd has not even been started then. What does > "/usr/sbin/service udev status" say? It's running. > > The kernel was also upgraded (to 4.18.0-1), but booting the old > > kernel (4.17.0-3) also fails. So it appears to me to be a bug in > > udev, possibly connected to my not running systemd. I haven't > > seen that anyone else is affected, so wanted to check here before > > submitting a bug report. Anyone else? Any other ideas? > > The udev init script has seen some changes in 239-8. Offhand the only > one which could explain the problem is that systemd-udevd is now started > via start-stop-deamon[1]. I don't have any systemd-less system to test > myself, though. That's where the problem is (thanks, Sven!). Appears to be a race condition due to --background; it lets "udevadm trigger" start too soon. Adding a short sleep makes it work: if start-stop-daemon --start --name $NAME --user root --quiet \ --pidfile $PIDFILE --exec $DAEMON --background --make-pidfile; then sleep 2 I'll plan to submit a bug report tomorrow.. Regards.. Bill
udev (without systemd) fails to find devices
I recently upgraded the sid installation on an i386 machine. With udev upgraded to 239-8, many devices are no longer detected during boot, e.g. usb, network card, video, audio. I also have a not-upgraded buster partition on the same machine -- a large portion of its dmesg output is simply missing from sid's dmesg. The kernel was also upgraded (to 4.18.0-1), but booting the old kernel (4.17.0-3) also fails. So it appears to me to be a bug in udev, possibly connected to my not running systemd. I haven't seen that anyone else is affected, so wanted to check here before submitting a bug report. Anyone else? Any other ideas? Thanks.. -- Bill Brelsford wbr...@k2di.net
Re: New stretch kernel: lilo boot fails with "EBDA is big" message
On Fri Oct 13 2017 at 01:20 AM +0200, deloptes wrote: > Bill Brelsford wrote: > > > This doesn't explain why I got the EBDA message in the first place, > > but all is working now.. > > once again the question: why not use grub? Lilo has always met my needs well, so, although I've considered grub, I've never felt the need to switch. But it was one of the next steps I was considering in this case -- especially if the problem turned out to be lilo.
Re: New stretch kernel: lilo boot fails with "EBDA is big" message
On Mon Oct 09 2017 at 12:50 AM +0200, Bill Brelsford wrote: > After the stretch 9.2 kernel upgrade to 4.9.0-4, lilo gives, at > boot, "EBDA is big; kernel setup stack overlaps LILO second stage" > and freezes. Problem solved. This is a dual-boot system, with the Win 10 bootloader passing control to lilo in the partion boot sector. The bootloader was configured by EasyBCD (in windows), which apparently saves its own copy of the partition boot sector, so ignored changes to lilo.conf. Guess I'll have to boot windows and refresh whenever the kernel is updated. (I originally tried to use lilo to dual-boot, but ran into problems with windows.) This doesn't explain why I got the EBDA message in the first place, but all is working now.. -- Bill Brelsford wbr...@k2di.net
New stretch kernel: lilo boot fails with "EBDA is big" message
After the stretch 9.2 kernel upgrade to 4.9.0-4, lilo gives, at boot, "EBDA is big; kernel setup stack overlaps LILO second stage" and freezes. Steps: - After upgrading, I installed irqbalance before re-booting. - Lilo then gave "Loading linux" followed by a line and a half of "." and hung, both for the new and old (4.9.0-3) kernels. - Using the stretch install disk for rescue, I purged irqbalance and re-ran lilo. - Now I get the "EBDA" message for the new kernel, but the old one boots normally. - I've re-installed the kernel package and re-generated initramfs (and re-run lilo), but it still fails. The most common cause of the EBDA message seems to be neglecting to run lilo, but I've done that. Output from lilo -v appears to be correct. I upgraded 4 other machines with no problem. All are i686 with similar configuration, except that the failing one installs the boot loader in a partition rather than in the MBR. Suggestions? -- Bill Brelsford wbr...@k2di.net
Re: aptitude/dpkg fails at Preparing to unpack
On Wed Aug 19 2015 at 11:40 AM +0200, Darac Marjal wrote: On Tue, Aug 18, 2015 at 09:32:24AM -0700, Bill Brelsford wrote: Recent security updates on jessie (i486) have failed: # aptitude update ... # aptitude -DPR safe-upgrade The following packages will be upgraded: libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common ... Reading changelogs... Done (Reading database ... 72512 files and directories currently installed.) Preparing to unpack .../libgdk-pixbuf2.0-0_2.31.1-2+deb8u2_i386.deb ... E: Sub-process /usr/bin/dpkg exited unexpectedly Failed to perform requested operation on package. Trying to recover: Installing or removing specific packages also fails. apt-get works fine, but subsequent aptitude runs fail the same way. First of all, eliminate the obvious: Do you have enough free space (and free inodes) in order to unpack the archive? Yes. Secondly, is the unpack process segfaulting? You might not see a message at the console, but check if the kernel has logged an error. No sign of segfaulting. My other jessie system doesn't have this problem, so I assume something is corrupt. But I can't find a way to repair it. Suggestions? (Aptitude version is 0.6.11-1+b1, dpkg 1.17.25.) Thanks for the response. Digging further (belatedly), the problem appears to be that my calling script exported SHELL=/bin/false into the environment, apparently causing dpkg to fail. Works fine with it removed. Strange that it appeared suddenly and that it didn't affect my other jessie system..
aptitude/dpkg fails at Preparing to unpack
Recent security updates on jessie (i486) have failed: # aptitude update ... # aptitude -DPR safe-upgrade The following packages will be upgraded: libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common ... Reading changelogs... Done (Reading database ... 72512 files and directories currently installed.) Preparing to unpack .../libgdk-pixbuf2.0-0_2.31.1-2+deb8u2_i386.deb ... E: Sub-process /usr/bin/dpkg exited unexpectedly Failed to perform requested operation on package. Trying to recover: Installing or removing specific packages also fails. apt-get works fine, but subsequent aptitude runs fail the same way. My other jessie system doesn't have this problem, so I assume something is corrupt. But I can't find a way to repair it. Suggestions? (Aptitude version is 0.6.11-1+b1, dpkg 1.17.25.)
Xorg / vt blank-screen problem
Since updating to kernel 3.16-1-686-pae (and with newer ones), when I start X I usually get a back-lit blank screen. Switching back to vt1 usually works (shows the X dialog); switching to vt7 a second time usually works (shows my X session), but sometimes not. Once X works, going back to vt1 almost always gives a blank screen. I'm running an Asus S62E laptop with no xorg.conf (except one for the synaptics touchpad). Same results in sid and jessie. All works normally if I boot the 3.14-2 kernel. The problem seems to be intermittent, perhaps a race condition. Ideas? Workarounds? Thanks.. Bill -- Bill Brelsford wbr...@k2di.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xt4mg-0006pd-hw...@k2di.net
davfs2: umount no longer waits for cache synchronization
Beginning with 1.4.7-1.1 (wheezy), unmounting a davfs filesystem returns immediately: $ umount /foo/dav $ The waiting while mount.davfs (pid ) synchronizes the cache message is not printed; cache synchronization continues in the background. It appears that umount.davfs is not being called. Bug? Or do I have something configured wrong? -- Bill Brelsford w...@k2di.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ungbr-0003sp-md@k2di.net
xorg freezes/sticks under kernel 2.6.38
Since upgrading to kernel 2.6.38, I've been experiencing freezes in X. After startup, things are normal for a matter of minutes; then most keypresses and mouseclicks have no effect until focus is moved to another window, at which time the screen catches up. Once it starts it continues until X is re-started. Starting X with fvwm's ClickToFocus (rather than SloppyFocus or FocusFollowsMouse) seems to work longer but eventually fails. The problem does not occur when running a 2.6.37 kernel. I'm running sid on an Asus S62E laptop with the following packages: xorg 1:7.6+6 xserver-xorg 1:7.6+6 xserver-xorg-core 2:1.10.1-2 xserver-xorg-input-evdev 1:2.6.0-2+b1 xserver-xorg-input-kbd1:1.6.0-1+b1 xserver-xorg-input-mouse 1:1.7.0-2+b1 xserver-xorg-input-synaptics 1.4.0-1+b1 xserver-xorg-video-intel 2:2.15.0-2 Same results with wheezy and: xorg 1:7.5+8 xserver-xorg 1:7.5+8 xserver-xorg-core 2:1.7.7-13 xserver-xorg-input-evdev 1:2.3.2-6 xserver-xorg-input-kbd1:1.4.0-2 xserver-xorg-input-mouse 1:1.5.0-2 xserver-xorg-input-synaptics 1.2.2-2 xserver-xorg-video-intel 2:2.13.0-6 Starting X and then running fvwm and applications on a remote (squeeze) machine has the same problem, so it appears to be an issue with the X server and the 2.6.38 kernel. Anyone else experiencing this? Suggestions? Thanks.. Bill -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qjtjb-0002pg-fk...@k2di.net
Virtual-terminal switch dumps X cut/paste buffer onto window
Another problem after recent X updates in sid: switching back to the X virtual terminal (e.g. via alt-F7) results in the contents of the cut/paste buffer being pasted into the active X window. Anyone else see this behavior? A bug in xserver-xorg (1:7.3+2)? -- Bill Brelsford [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: hosts.equiv ignored after pam updates? (rsh/rlogin)
On Tue Sep 11 2007 at 10:37 PM -0700, Bill Brelsford wrote: After a recent update to sid, incoming rlogin and rsh connections ignore /etc/hosts.equiv (and ~/.rhosts) and ask for a password or fail with permission denied. The rsh-server (and -client) packages were not updated, but libpam-modules, libpam-runtime and libpam0g were upgraded to 0.99.7.1-4. I'm not sure one of them is the culprit (and see no new bugs filed for them), but pam is involved in the authentication process. Is this a known problem? Anyone else experiencing it? On Thu Sep 13 2007 at 05:20 PM +0200, Lewis, James M. wrote: I have the same problem and have not been able to pick through it yet. Like you, I suspect a change in a pam module. There are only a few to check but I have not had time to do it yet. Look in /etc/pam.d/rsh... I did, but didn't go quite far enough. The problem seems to be /lib/security/pam_rhosts_auth.so -- replacing it with the old version fixes it. I'll file a bug against libpam-modules. Thanks! -- Bill Brelsford [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
hosts.equiv ignored after pam updates? (rsh/rlogin)
After a recent update to sid, incoming rlogin and rsh connections ignore /etc/hosts.equiv (and ~/.rhosts) and ask for a password or fail with permission denied. The rsh-server (and -client) packages were not updated, but libpam-modules, libpam-runtime and libpam0g were upgraded to 0.99.7.1-4. I'm not sure one of them is the culprit (and see no new bugs filed for them), but pam is involved in the authentication process. Is this a known problem? Anyone else experiencing it? -- Bill Brelsford [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
can't fsck ext2 floppy (etch/sid)
I'm unable to fsck an ext2 floppy on my laptop under etch or sid: # e2fsck /dev/fd0 e2fsck 1.39 (29-May-2006) Error determining size of the physical device: Device or resource busy The laptop is a Winbook Si. From dmesg: Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 I can, however, mount and use the floppy. There is no problem under sarge (e2fsck 1.37). And, with no floppy in the drive, e2fsck correctly complains No such device... Suggestions? -- Bill Brelsford [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
