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.

  • cyberwolfie@lemmy.mlOP
    1·
    11 months ago

    As far as I can tell, these are the methods apt uses to get information from the repositories that is listed within sources.list and within the sources.list.d directory. The number of subprocesses almost matches the number of sources there - in reality there are 14 listed, not 13 as is seen in the ps output. I can find one entry that starts with mirror+file, but otherwise there are 13 https entries. So that last line I am not sure what is doing.

    Anyways, it seems to me that it gets stuck somewhere updating the repositories list. Right now, I’m stuck with three questions:

    1. I’m still unsure as to whether it would be safe to kill the process, as I could imagine that having a corrupted depencies files could be really bad?
    2. Also, would killing the process automatically release the lock, or would I need to remove that myself after?
    3. Is there any reason to believe that this would even work, seeing as this happens everytime on boot. I imagine that if I kill the process, delete the lock and try to run sudo apt update I just end up the same place again.
    • toasteecup@lemmy.worldEnglish
      3·
      11 months ago

      So my theory on what’s going on is this.

      I suspect that this is an automatically running update to try to help keep your packages up to date, and I think it’s getting stuck on a source configured in your /etc/apt/sources.list I’m willing to bet it’s likely a source configured to pull from a “CD” which is used during installation and they forgot to disable that one.

      You should be able to stop it, it’ll still be locked but you’ll need find the lock file (I forgot where it’s configured) and just remove it with a simple rm, you’ll probably need to sudo the rm though.

      So my order of operations would be, kill the process, try to rerun the apt update and see if that tells you which repo it’s getting stuck on.

      • cyberwolfie@lemmy.mlOP
        1·
        11 months ago

        I managed to kill the process, and the lock was released with the operation, allowing me to upgrade my system. After this, I moved all external sources out of sources.list.d and upgraded my system, and continued to add them back one by one to see if any of them triggered an error. None of them did.

        When I reboot the system, the problem is back. I’ve added some more details in the original post.

        • priapus@sh.itjust.worksEnglish
          2·
          11 months ago

          I’m guessing Tuxedo’s distro includes a service to automatically update the system or your repos on boot. It seems like the service is failing. I would take a look through your enabled services to see if you can find something related to updating, then you can check the status of the service for logs. You can also try asking Tuxedo support, who may have more insight into this problem.

          • cyberwolfie@lemmy.mlOP
            1·
            11 months ago

            Aha, that is exactly it! apt-get is called by their driver update tool, Tomte (https://www.tuxedocomputers.com/en/Infos/Help-Support/Frequently-asked-questions/What-is-TUXEDO-Tomte-.tuxedo). I actually would’ve seen this from the ps auxf | less command above if I had used my eyes a little better, as the top line in the output I pasted above is a sub-process running under Tomte.

            Checking systemctl status tuxedo-tomte.service yields the following output:

            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 guess contacting their support directly is the best way to solve this at this point.

            • priapus@sh.itjust.worksEnglish
              1·
              11 months ago

              Could you send the contents of the service file? It seems like the problem is that the service is running before the network is up and running. It might be resolved by setting the service to run after network-online.service

              • cyberwolfie@lemmy.mlOP
                1·
                11 months ago
                [Unit]
Description = Tomte-daemon, finishes tasks that could not be accomplished before
After = network.target auditd.target
Before = oem-config.service

[Service]
Type = oneshot
ExecStart = /usr/bin/tuxedo-tomte configure all
Restart = no
        • toasteecup@lemmy.worldEnglish
          1·
          11 months ago

          Oh fuck. That’s actually bad. Just to confirm, when you installed the system you did not manually set the size of any of your partitions, correct?

          • cyberwolfie@lemmy.mlOP
            1·
            11 months ago

            Oh boy, don’t like that sound of that…

            That is correct. I used WebFAI to install, the automatic installer provided by Tuxedo Computers (https://www.tuxedocomputers.com/en/TUXEDO-WebFAI.tuxedo).

            There are three partition on my primary SSD. One that is mounted to /boot (1G), one mounted to /boot/efi (512M) and my main partition that is encrypted. I’m guessing it is one of the two boot partitions that don’t have enough space to update initramfs-tools?

              • cyberwolfie@lemmy.mlOP
                2·
                11 months ago

                /boot is 98% filled, so I am guessing it is that one. I’ve submitted a ticket with Tuxedo, and hopefully they are able to point me in the right direction.