Wrong sources in official-package-repositories.list

Bug #1197995 reported by Stephan on 2013-07-04
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Linux Mint
Low
Unassigned

Bug Description

On initial install of the most recent version of Mint (Olivia) my /etc/apt/sources.list.d/official-package-repositories.list contained the contents below. I had to manually change the archive.ubuntu.com 'olivia' settings to 'raring' to enable apt to work correctly.

# Do not edit this file manually, use Software Sources instead.

deb http://packages.linuxmint.com olivia main upstream import #id:linuxmint_main

deb http://archive.ubuntu.com/ubuntu olivia main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu olivia-updates main restricted universe multiverse

deb http://security.ubuntu.com/ubuntu/ olivia-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu/ olivia partner

Tags: apt Edit Tag help
Frédéric Gaudet (frgaudet) wrote :

Did you used a third party source manager ?

LM is shipped with a correct sources list file, and is supposed to be managed with mintsources. That way it stay consistant.

The issue you have could be due to an another software which have replaced 'raring' with 'olivia'.

Changed in linuxmint:
importance: Undecided → Low
status: New → Incomplete
Kevin Mian Kraiker (kevin-mian) wrote :

Having the very same problem with a fresh installation here. Didn't even get to boot it, yet. Went chroot to run a boot-repair from a Live USB session (I'm trying to install and boot from an external USB HDD, in EFI mode), but can't get it to install grub-efi-amd64-signed as it doesn't find it (it's not in any of those sources - the raring ones aren't listed at all).

Kevin Mian Kraiker (kevin-mian) wrote :

Ok, just confirmed this. Don't know what's messed up, but something definitely is.
I'm booting from an Olivia Cinnamon 64-bit Live USB Flash Drive in EFI mode, and the problem was easily repeated after reinstalling from scratch to the same USB HDD (which was repartitioned, just in case).
If I chroot to the new installation (before or after rebooting, still couldn't boot into it) and run apt-get update, most of the sources return 404 Not Found errors (of course, as they're Ubuntu sources, so there's no such release named 'Olivia'). My sources.list file only has "# deb http://archive.getdeb.net/ubuntu raring-getdeb apps games" and nothing else.

Kevin Mian Kraiker (kevin-mian) wrote :

Oh, my mistake. This time I booted from a Live CD instead, also in EFI mode. The DVD was burnt from a fresh downloaded Cinnamon image, which appeared to have the right MD5.

summary: - default apt sources wrong
+ Wrong sources in official-package-repositories.list
Frédéric Gaudet (frgaudet) wrote :

Definitely, the ISO is burnt with a correct file. Which means, something modify it before, or during the installation process.

What software did you used to 'burn' the ISO on the USB Flash drive ?

Did you used some kernel option during live boot ?

While in the live environment, do you launch the installer immediately after the desktop loads or did you add a PPA for instance ?

Thanks

Kevin Mian Kraiker (kevin-mian) wrote :

The first time (Live USB), I do believe I had added ppa:yannubuntu/boot-repair and installed it before installing, although I'm pretty positive that when running from the live CD, the first thing I did was run the installer.
They (installer/live media) were both created on a Windows 8 x64 PC, using LiLi for the live USB and Microsoft's default Image Burner for the DVD.
Both times, I booted with the standard grub config for EFI (also, I don't have Secure Boot on this PC) - although I'm not sure if I used compatibility mode or just the standard mode.
I'm going to run another test later today and post back with the complete details.

Richard Theil (richard-theil) wrote :

I have just seen the issue with a DVD ISO of Mint 15 32-bit MATE. Mint has been downloaded from official mirror and been burned onto a new DVD. The DVD was booted on a Windows-only Dell Latitude D630 laptop. After booting, I used gparted to shrink the Windows partition and setup an extended partition (sda3) to contain a a system partition (sda5 at /), linux swap (sda6), and a user partition (sda7 at /home). I ran the installer and manually specified mount points there, omitting any repeated formatting of the newly created ext3 systems at sda5 and sda7.

After reboot, the problems described above showed up. I was able to manually fix it by replacing "olivia" with "raring" in the /etc/apt/sources.list.d/official-package-repositories.list file as suggested.

Apart from setting up the partitions and manually specifying them during install, NOTHING has been done with the machine during install, and it has never had anything Linux-related near it before.

Richard Theil (richard-theil) wrote :

Addendum:

1.) To those coming across this bug and wanting to apply the fix: Only the sources containing "ubuntu" or "canonical" as host should be changed from "olivia" to "raring". The mint host repository itself still wants "olivia".

2.) If that is of any importance: I only connected the network (Ethernet, DHCP behind NAT) when the installer reminded me to in the preflight check window. After I plugged in the cable, the warning changed to "ok" automatically and I continued.

I don't know how to increase the importance of a ticket, but this makes the Mint KDE unmaintainable out-of-the-box. How does that rate a "Low"? And what in God's name qualifies as a "High"?

So, as far as I can see, this affects all variations of Olivia (in my case, Cinnamon, but also listed here are KDE and MATE). Didn't have the time to test it more thoroughly, and don't think I'll have it so soon, but I will get back to testing and posting the results as soon as possible.

Fedor Uvarov (acharvak) wrote :

I also experienced this problem when installing Mint 15. The file is indeed correct on the DVD but once the system was installed, "raring" was replaced with "olivia" everywhere. Furthermore, some spaces have unexpectedly appeared in repository names (it looked like "deb http://archive.ubuntu.com/ubuntu/ olivia ma inrestrict ed uni versemulti verse" - not exactly, this is from memory). Additionally, some repositories had nonsensical options (in square brackets). Every "option" was one seemingly random character, as though some encoding problems happened along the way.

I have not used any third-party software to edit this file, nor have I edited it by hand before the problem happened. Right after starting Mint I noticed the update manager icon in the system tray with the message that some software sources could not be downloaded. The file was corrupted already.

I installed Mint without formatting the partition and it already had /home on it from the previous Ubuntu installation. But it had no /etc, /bin and other system directories, they had been deleted beforehand.

wayne asher (p-wayne) wrote :

I have experienced this bug, this time on MINT 16 MATE, where the ubunto repositories read petra and not saucy.
I am a lInux newbie and this bug gave me a descent into hell when installing and get everything to work - many occasions I did wonder why I didn't just upgrade Windows instead.
Surely this must be bug of the highest priority...

Changed in linuxmint:
status: Incomplete → Confirmed

Back here to confirm it has just happened again on a fresh reinstall of Mint 16 Petra Cinnamon. Interesting thing is, I had Petra Cinnamon already installed on the same machine without this happening, but somehow this time it happened.

chemicalfan (mike-lumsden) wrote :

I think this must be a bug in Mint's version of Ubiquity, hopefully this can be resolved in Qiana!

It seems it's still unresolved in Qiana. Just installed it in a different machine, same problem.
I don't see what could be wrong in all those machines AND different media, except maybe for EFI boot in all of them.

Fedor Uvarov (acharvak) wrote :

I have to say, I've right now installed Qiana (Cinnamon edition) on a freshly formatted partition and this bug did NOT occur. My machine does have EFI boot.

Installed it yesterday to replace older installation, same thing again. Qiana Cinnamon, Intel processor, EFI/GPT. But, I've noticed the same thing happening some months ago, when I installed it in a friend's computer without EFI. I've noticed one clear thing: in every case, I opted to manage the partitions manually during install.

Some interesting news here: this does not only affect Linux Mint. It's probably a bug within Ubiquity, when you choose the Advanced/Manual partitioning scheme. Had this happen again, this time on another machine, installing ElementaryOS.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers