this post was submitted on 06 Aug 2023
35 points (97.3% liked)

Linux

56591 readers
345 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago
MODERATORS
 

I'm still a fairly new Linux-user (on Tuxedo OS), and I just ran into an issue that is new to me. If I try to update my system, either via command line or Discover, the apt update command fails. This is the output:

E: Could not get lock /var/lib/apt/lists/lock. It is held by process 1635 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to lock directory /var/lib/apt/lists/

Process 1635 is apt-get update run by root, and persists through restart. I am tempted to try to kill it (kill 1635), but I'm not sure if anything could break from that, so I thought I'd try to ask for help first before I do something stupid.

EDIT:

I have managed to update my system by killing the process, which releases the lock, and then going on to do normal sudo apt update and sudo apt upgrade. For the sake of troubleshooting, I tried to add back my third-party repos one by one, and none of them caused any problem. However, when rebooting the same issue as described above happens again. Software updates is set to "Manually" in the System settings.

In addition, everytime I ran sudo apt upgrade, at the end some update related to initramfs fails. My disk is encrypted using cryptsetup, and as I’ve come to understand, I should be very careful doing anything related to initramfs when that is the case. Here is the output:

Processing triggers for initramfs-tools (0.140ubuntu13.2) ...
update-initramfs: Generating /boot/initrd.img-6.2.0-10018-tuxedo
I: The initramfs will attempt to resume from /dev/dm-2
I: (/dev/mapper/system-swap)
I: Set the RESUME variable to override this.
zstd: error 25 : Write error : No space left on device (cannot write compressed block) 
E: mkinitramfs failure zstd -q -1 -T0 25
update-initramfs: failed for /boot/initrd.img-6.2.0-10018-tuxedo with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

EDIT 2:

The issue seems to have been narrowed down to a failure of Tuxedo's driver configuration service that runs at boot. It is this process that calls apt-get (and something I should've seen earlier...), and systemctl status reveals some errors:

aug. 08 15:33:56 laptop systemd[1]: Starting Tomte-daemon, finishes tasks that could not be accomplished before...
aug. 08 15:34:06 laptop tuxedo-tomte[1393]: no network found!! some fixes might not be applied correctly
aug. 08 15:34:06 laptop tuxedo-tomte[1393]: systemctlCmd: systemd-run --on-active="30sec" tuxedo-tomte configure all >/dev/null 2>&1

I really appreciate the help from everyone so far. It's a good experience asking for help here, and I've learned a lot from your answers. Makes being a Linux newbie a lot easier. So thank you :)

Since this seems to be a very specific issue related to Tuxedo's own services, I will contact their support to get their input on what to do next.

you are viewing a single comment's thread
view the rest of the comments
[–] toasteecup@lemmy.world 2 points 2 years ago (1 children)

I would recommend trying out the process tree

Use ps auxf | less

And then / to search for the process. See what child processes are running from that aptget. I wouldn't expect much but that should give you an idea about the safety of killing it

[–] cyberwolfie@lemmy.ml 3 points 2 years ago* (last edited 2 years ago)

Here is the output from running that command:

root        1635  0.0  0.0  22208  8928 ?        S    aug.06   0:00  \_ apt-get update
_apt        1654  0.0  0.0  27528  9600 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1655  0.0  0.0  27528  9600 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1656  0.0  0.0  27528  9600 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1657  0.0  0.0  27528  9760 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1658  0.0  0.0  27528  9760 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1659  0.0  0.0  27528  9760 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1660  0.0  0.0  27528  9760 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1661  0.0  0.0  27528  9600 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1662  0.0  0.0  20908  6880 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/mirror+file
_apt        1663  0.0  0.0  27528  9760 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1664  0.0  0.0  27528  9920 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1667  0.0  0.0  27532 10080 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/https
_apt        1669  0.0  0.0  20864  7680 ?        S    aug.06   0:00      \_ /usr/lib/apt/methods/file