In my /etc/apt/sources.list.d there are a couple of files that are not listed in apt policy. In particular, I'm on 20.04 and the names include disco and eoan.
Does that mean that they are not used? If so can I just delete those files, as their names do indicate that they are not up-to-date with my system?
I need the INTL module for PHP on Ubuntu 20.04. When I do
$ sudo apt install php7.4-intl
I get
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
php7.4-intl : Depends: php7.4-common (= 7.4.3-4ubuntu2.2) but 7.4.8-1+ubuntu19.10.1+deb.sury.org+3 is to be installed
E: Unable to correct problems, you have held broken packages.
We all know that the broken packages message is a red herring. (Yes, I checked...)
As I'm on 20.04 I'm supicious against the ubuntu19.10.1 part of the package that apt suggests.
PHP says:
PHP 7.4.8 (cli) (built: Jul 13 2020 16:46:06) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.8, Copyright (c), by Zend Technologies
which makes me even more confused. I have tried what I can find googling to remedy any inconsistencies in the apt configuration and cache. (dpkg --configure -a, apt clean/autoclean, ...)
I'm packaging cgreen for Ubuntu working currently on 15.10 and in my debian directory I've created cgreen.lintian-overrides as per the lintian manual and the New Maintainers Guide. It has this content:
cgreen binary : non-dev-pkg-with-shlib-symlink *
cgreen binary : package-name-doesnt-match-sonames *
(I've tried many variations of this...)
When I run debuild, or just lintian I still get those warnings. lintian -d does not indicate that it has found any overrides, but the debug message says "if there where any", so to me it is unclear if it found and read my file or if there is some format error.
There was some indication that profiles could set some tags to non-overrideable, but I've inspected the profiles in /usr/share/lintian/profiles/ubuntu and the tags in my override does not seem to be disabled there.
Why does not lintian respect my overrides?
I know there are a few questions in this already (error: file '/grub/i386-pc/normal.mod' not found, error: file '/boot/grub/i386-pc/normal.mod' not found, https://askubuntu.com/questions/519463/boot-grub-i386-pc-normal-mod-not-found-in-grub-rescue) but non of those solves my problem.
I upgraded a DELL PowerEdge 830 from 12.04 LTS to 14.04LTS and found myself staring at the "grub rescue" prompt. (Funny thing is that non of the commands that should work, like 'boot', are recognized by the grub trying to talk to me...)
I used the BootRepair, which was a nice utility. Unfortunately it didn't help. Still "grub rescue".
Here's the link to its log if someone would be kind enough to have a look at it.
I also tried this and this, which are mostly the same. So obviously there is something differently wrong with my setup.
At the grub rescue prompt I did "ls" to ensure I had the partitions I wanted. I can see the 3 expected partions on the first drive, /dev/sda1 being marked as boot and ext3. Here's a session with grub rescue:
grub rescue> ls
(hd0) (hd0,msdos5) (hd0,msdos1) (hd1) (hd1, msdos)
grub rescue> ls (hd0)
(hd0): Filesystem is unknown.
grub rescue> ls (hd0,1)
(hd0,1): Filesystem is fat
grub rescue> ls (hd0,5)
(hd0,5): Filesystem is fat.
grub rescue> set
cmdpath=(hd0)
prefix=(hd0,msdos1)/boot/grub
root=hd0,msdos1
grub rescue> normal
unknown command ‘normal’
grub rescue> insmod normal
error: file ‘/boot/grub/i386-pc/normal.mod’ not found
grub rescue> ls (hd0,1)/boot
error: file '/boot' not found.
Seems like grub thinks hd0,msdos1 is a FAT partition, right? fdisk (from a LiveCD) says its an ext3. That's causing "normal.mod not found", I suppose, since the kernel on a Linux system does not have FAT-support, which it shouldn't need...
This is our "production" server so I'd appreciate any quick replies so I can get it back running before Monday, thanks.
UPDATE: I did find a number of file system markings using wipefs (no, it doesn't wipe the filesystem...), but removing all but one (ext3) still did not fix my issue.
Biting the bullet, and many nightly hours later I had a fresh install and most of the data restored piece by piece from backup.
So, no solution.
As a newbie I seem to have messed up my upgrade leaving my system in a very unstable state.
I attempted an upgrade from 8.04LTS which ended in an error about libc and kernel upgrades. I tried to upgrade the kernel but am now unsure if that worked, because when I retried my dist-upgrade there was a lot of errors about pre-dependencies and leaving packages un-configured.
Now I have a system that answers almost every command with:
/lib/libc.so.6: version `GLIBC_2.8' not found (required by /lib/libselinux.so.1)
I probably should try a complete re-installation, but I'm investigating whether there is any possibility of getting a working glibc so that I at least can have some commands working to ensure that my backups are recent etc. before doing the clean install.
Not even ls works without saying glibc_2.8 not found.