Issues installing Firefox using Apt

MNT Reform
1

I’ve been trying to install Firefox from the command line and I’ve been running into some circular issues. running
sudo apt install firefox-esr
gives me this error:
The following packages have unmet dependencies: libc6-dev : Breaks: binutils (< 2.38) but 2.37.90.20220123-2 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

I tried removing one of the conflicting packages. running sudo apt-get remove binutils runs past the “Do you want to continue” prompt, but stops with an error to install UsrMerge and to run that.

But when I run sudo apt-get install usrmerge
I get the same package conflict error that trying to install firefox gets me.

Is there another way to install usrmerge, or to resolve this?

2

Why would you run that? In unstable, base-files provides usr-is-merged.

Your problem sounds like you are mixing packages from different distros? The package binutils 2.37.90.20220123-2 is very old. What is the state of your system? And why are you installing firefox-esr and not firefox if you are using unstable?

Are you otherwise fully upgraded or does apt list --upgradable return many packages? What do you see for:

apt-cache policy binutils libc6-dev firefox
3

I don’t have a specific reason. When I ran into a usrmerge problem with a different system, I just installed and ran usrmerge in this fashion.

It’s possible I’m mixing packages, but that would surprise me as I have barely done anything with my Reform yet.

I don’t know the exact state of my system, you’ll have to be more specific with that question. When I went onto Firefox’s website for instructions to install firefox on debian from the command line, it listed a command specifically for firefox-esr, so I assumed that was just the correct version.

This is my first time doing anything with Unstable, so I’m very green with all of this.

apt list --upgradeable listed a lot of packages. it looked like most/all of the packages possible.

Here is the output for apt-cache policy binutils libc6-dev firefox:

binutils:
  Installed: 2.37.90.20220123-2
  Candidate: 2.43.50.20241221-1
  Version table:
     2.43.50.20241221-1 500
        500 http://ftp.de.debian.org/debian sid/main arm64 Packages
 *** 2.37.90.20220123-2 100
        100 /var/lib/dpkg/status
libc6-dev:
  Installed: 2.33-4
  Candidate: 2.40-4
  Version table:
     2.40-4 500
        500 http://ftp.de.debian.org/debian sid/main arm64 Packages
 *** 2.33-4 100
        100 /var/lib/dpkg/status
firefox:
  Installed: (none)
  Candidate: 133.0.3-1
  Version table:
     133.0.3-1 500
        500 http://ftp.de.debian.org/debian sid/main arm64 Packages
4

It looks like you have not upgraded parts of your system for nearly 3 years (January 2022). Skipping stable versions in Debian is not supported so I wonder if you even should continue with “apt upgrade” in the first place or whether there is a strategy to continue in a somewhat safe fashion at all.

Is this imx8mq reform?

If your last upgrade was that long ago, then I suppose you do not have the reform-check utility installed?

The output of this would be interesting:

apt-cache policy reform-tools

If you are using unstable, you should upgrade regularly. At least you should not leave a system un-upgraded for 2 years and 11 months. I don’t even want to mention the number of security issues your system likely is affected by because of these old package versions. Even if you are using Debian stable instead, you should have unattended-upgrades enabled to always receive the current security fixes.

It will be tricky to get your system working again. Do you want to spend the time or rather start from scratch?

5

I don’t mind spending some time on this. Better for me to get to know the system anyways.

It hasn’t been quite 2 years 11 months; I probably assembled this around July-ish of 2023 and then left it dormant. I think I ordered it in the twilight of its cohort’s order window.

Is there an easy way to check whether it’s the imx8mq processor? I’m 90% certain it’s that one any, I didn’t spring for the next step up processor. It should be the base CPU.

apt-cache policy reform-tools spits out:

reform-tools:
  Installed: 1.0-8
  Candidate: 1.64
  Version table:
     1.64 500
        500 https://mntre.com/reform-debian-repo reform/main arm64 Packages
 *** 1.0-8 100
        100 /var/lib/dpkg/status

so it looks like I got an early version of it.

definitely want to get back to regular upgrades and using this more like daily/weekly if at all possible. That’s what I want to aim for. But if I just have to eat it and reinstall an OS it wouldn’t be the first time for me.

6

The output of apt-cache policy reform-tools shows, that your system is from before sysimage-v3: sysimage-v3-20220624 · Reform / reform-system-image · GitLab

The important new thing in sysimage-v3 are, that from that point on, you can update your system just with “apt upgrade” as usual as everything you need is managed by apt/dpkg. But getting into that state from a system before that can be tricky. Especially because the whole boot process was different. You might still have /sbin/reform-init to boot for example. Starting with sysimage-v3, your reform boots like any other Debian system (after u-boot that is).

There is not really an established migration guide. The best we have is this one: bit-by-bit reproducible and no need for superuser privileges (#15) · Issues · Reform / reform-system-image · GitLab

Maybe, but the packages you have are from January 2022, not from July 2023.

cat /proc/device-tree/model

Please do a backup before continueing. The path you are about to trod has not been taken often and most people did it in 2022. It has been a long time since we had this topic, so my memory is rusty.

To proceed you have to decide whether you want to keep using Debian unstable or whether you would like to use Debian stable instead.

7

i’ll do a backup. That’d be a useful thing to know how to do on debian anyways. I think I want to continue on the Unstable path, as hopefully Godot 4 will hit Unstable sometime this year. I otherwise have no preference, as I don’t know what the difference between Stable and Unstable is currently.

cat /proc/device-tree/model just returns
MNT Reform 2.

There is indeed a script at /sbin/reform-init.

getting to a point where I could just run “apt upgrade” sounds really pleasant right about now. Should I just run the preliminary “remove custom builds” script that minute posted in the bit-by-bit open issue you linked to?
Will I need to take steps to re-flash my SD with sysimage-v3 or higher at some point?

8

Or you use stable and then build godot 4 yourself instead of using the packaged version.

I’d say that the main difference is that with stable, your system will work without breaking for 4 (LTS) up to 9 (ELTS) years after its release. With unstable, on every upgrade you risk that one of the packages you installed contains a very bad bug which makes your system not bootable or makes you loose data.

Then you have the imx8mq indeed.

You probably should first upgrade your packages to their latest versions. This might be tricky, it might make your machine unbootable. Maybe have a second computer ready to rescue this system and definitely do a backup before. This is not only made tricky because there is no clear upgrade path from before sysimage-v3 to after but also because there are packages on your system which are 2 years and 11 months old and upgrading those to the latest version in unstable is something that barely anybody ever tests. And if they test it and run into bugs, it is unlikely that those bugs get fixed by overworked maintainers because doing this is something that you really should not be doing as it’s not supported.

So if you want to keep using unstable, take a backup and then do a large

sudo apt update
sudo apt full-upgrade

Then reboot and hope that nothing broke. If something broke, restore your backup and we’ll try again with a different approach depending on what broke.

Why would your SD-card be involved? You might need an SD-card to rescue your system in case something broke badly. Or is your system currently on your SD-card? Can you give me the output of this:

findmnt

And this:

cat /etc/fstab

Thanks!

9

You listed only a “pro” for using Stable and only a “con” for using Unstable. Would you prefer that I just choose Stable? You can say so, I won’t be offended XD

I actually already ran sudo apt update and sudo apt full upgrade prior to making this thread: update completes, but when I ran sudo apt full-upgrade I ran into a not-enough-free-space in /var/cache/apt/archives/ error. I have been trying to fix that in parallel to the other apt issues I was getting; it looks like other people on this forum also ran into a weird issue where apt said there wasn’t enough space when there definitely was. Will probably have to do some more reading of that part of the forum and try what they did.

The SD card stuff was only a guess from reading stuff in the sysimage section of the git repos for mnt.

findmnt returns

<pre>TARGET                       SOURCE     FSTYPE    OPTIONS
/                            /dev/mmcblk1p1
│                                       ext4      rw,relatime
├─/dev                       devtmpfs   devtmpfs  rw,relatime,size=1744156k,nr_inodes=436039,mode=755
│ ├─/dev/shm                 tmpfs      tmpfs     rw,nosuid,nodev
│ ├─/dev/pts                 devpts     devpts    rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/dev/mqueue              mqueue     mqueue    rw,nosuid,nodev,noexec,relatime
│ └─/dev/hugepages           hugetlbfs  hugetlbfs rw,relatime,pagesize=2M
├─/proc                      /proc      proc      rw,relatime
├─/sys                       sysfs      sysfs     rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/security     securityfs securityf rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup           cgroup2    cgroup2   rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recu
│ ├─/sys/fs/pstore           pstore     pstore    rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/bpf              bpf        bpf       rw,nosuid,nodev,noexec,relatime,mode=700
│ ├─/sys/kernel/debug        debugfs    debugfs   rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/tracing      tracefs    tracefs   rw,nosuid,nodev,noexec,relatime
│ └─/sys/fs/fuse/connections fusectl    fusectl   rw,nosuid,nodev,noexec,relatime
└─/run                       tmpfs      tmpfs     rw,nosuid,nodev,size=803688k,nr_inodes=819200,mode=755
  ├─/run/lock                tmpfs      tmpfs     rw,nosuid,nodev,noexec,relatime,size=5120k
  ├─/run/credentials/systemd-sysusers.service
  │                          ramfs      ramfs     ro,nosuid,nodev,noexec,relatime,mode=700
  └─/run/user/1000           tmpfs      tmpfs     rw,nosuid,nodev,relatime,size=401840k,nr_inodes=100460
</pre>

cat /etc/fstab returns # UNCONFIGURED FSTAB FOR BASE SYSTEM

I’m going to hold off on making a serious stab at this upgrade for a couple of days until I’m back with my second computer and have successfully backed up this system.

And no problem. I will happily run any cli command you want; I appreciate your guidance so far

10

I don’t think this should cause any offense. What somebody uses should be completely up to them. For some people, unstable (or testing) works better and others prefer a system with Debian stable. For example, until June 2023 I used Debian testing but since them I’m on stable. I changed because my needs changed. I don’t “prefer” others to use stable or unstable.

I would not be surprised if the upgrade was trying to download a few gigabytes of packages which would temporarily be kept in /var/cache/apt/archives/.

That was about /boot and installing a new kernel. You cannot have that problem because you have no /boot partiton. :slight_smile:

Okay, this means that your whole system is on an SD-card. Please be very careful with that. The operating system will not be gentle with your SD-card. It will not try to minimize the number of writes it performs to your SD-card. And if you mount your / without noatime (which you do) then it will in fact write something to your filesystem every time you access a file (even if you don’t change it).

That sounds like a good idea. Since your whole system is on the SD-card, you can easily take a full disk image of it. If something goes wrong, you can just write the whole image back to the card and start over.

I’m not quite sure what I should recommend you on how to proceed. You could solve the issue with your SD-card being too small for upgrading everything at once in many different ways:

  1. first ugprade to the next Debian stable, then from there upgrade to unstable
  2. use snapshot.d.o and upgrade from one snapshot to the next, leaving maybe 3-4 months between snapshots
  3. pick some random packages that you do want to have installed and “apt install” them (even though they are already installed) which will upgrade them and everything they need which will not be everything but a part of it and do that until you can “apt full-upgrade” the rest

Luckily, since you can take a full disk image of your SD-card you can try out multiple scenarios :slight_smile:

11

For the aspect of the SD card getting a lot of writes from the OS, you could mount /var/log and /tmp as tmpfs so they are just a RAM disk and never touching the SD card. I do this on any Raspberry Pi systems to help the microSD card last longer. I lose all my logs on shutdown but that has never been a problem for me. Some people prefer to save/restore the logs with stuff like GitHub - azlux/log2ram: ramlog like for systemd (Put log into a ram folder) , though I’ve never found the need thus far. On one Pi (which has been running since 2018 on the same microSD) my /etc/fstab entries are like this:

tmpfs   /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m
tmpfs   /tmp    tmpfs    defaults,noatime,nosuid,mode=1777,size=200m

Figured I’d share that in case you are interested in the idea, though you might want to investigate more about it before doing it – particularly around the fact that some daemons/services might require a log file to be present at startup (though this should be rare).

12

And another thing I just remembered: when doing such large upgrades, do not do them in a graphical terminal directly but inside screen or tmux because the upgrade might change things on your disk that makes applications on your desktop crash. See apt running on crashed gnome-terminal

1 Like
13

Thank you both for all of the responses.

I think I’m going to aim for stable. I successfully copied the system image onto a 128gb SD using rufus. Plus I have a copy sitting on my desktop, so I think the upgrade tomfoolery is a go.

I’m going to start again trying to use apt to upgrade packages. If I run into more trouble I’ll post more in this thread.

14

An Update:
most of the apt commands I tried, especially those of the install and upgrade variety, either ran into the libc6-dev // binutils conflict that I ran into originally, or the gave me “install usrmerge” message. I tried removing or upgrading either package with apt, but each time was met with the install usrmerge message. So I tried brute forcing the removals with dpkg --remove --force-all as described in the “UsrMerge is uninstallable, what should I do?” section of UsrMerge - Debian Wiki. This only broke things further, as now most things that I try to install, upgrade, or remove are reporting dependency issues, and apt --fix-broken install fails. I’m glad I made a backup, because I probably need to re-write the disc image onto this SD card to try again.

Is there a way to install UsrMerge without apt? I think any apt-based upgrade methods are dead in the water until I can get UsrMerge installed.

Also, what’s snapshot.d.o and how would I use it for upgrading? I couldn’t find that program with the usual googling.

15

You are trying to upgrade a Debian unstable system with packages that are three years old. And it’s even core packages that are that old. What you are attempting to do will be very tricky and I’d be surprised if somebody has walked your past before and has written down how to do it, because your situation with respect to which packages you have installed in which version is very unique. The usrmerge debian wiki will not help you. Merged-/usr is one of the reasons why this upgrade will be difficult. The other is the time64 transition. For both transitions, we already have invested thousands of compute hours to test all possible upgrade scenarios from Bookworm to Trixie and make sure that it goes smoothly. It is very likely that there are bugs for the upgrade path that you are on. This is why I suggested the snapshot.d.o method. It’s not a tool. https://snapshot.debian.org is a website which takes snapshots of the Debian mirror. So you can “travel in time” and install a Debian from 2005 for example. In your case, you might want to try doing full upgrades every 3 months. So you could for example upgrade from January 2022 (where you are on) to April 2022, then to July 2022 and so on. You do this by switching out your mirror in /etc/apt/sources.list. Right now you might have this in it:

deb http://deb.debian.org/debian unstable main

You can to replace that by:

deb [check-valid-until=no] http://snapshot.debian.org/archive/debian/20220401T000000Z unstable main

And then apt upgrade your system to that. Then change the 20220401 part to 20220701 and so on.