[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 10/07/14 19:08, bad apple wrote:
I did use memtest with no problems, but I aren't using that memory in this computer. I did go in and put the disk uuid's into fstab and that's how I got it working and Mint 17 installed but then it repeatedly crashed. Definitely a hardware failure and I'll go back to that another day.On 10/07/14 18:45, George Parker wrote:Sorry for the long story. Section 1 is background, section 2 is the current problem. 1. Having been away for 6 weeks consorting with the French and Spanish, on my return I thought my aging desktop could do with a face-lift. (Nice to get back to reasonably fast broadband and computer after 6 weeks on a tablet and smartphone on very unreliable wifi.) I put in a 1 TB drive and another 4 Gb RAM, partitioned the new drive and copied the /root and /home partitions from the old drive to the new with DD. (Running Mint 16) Disconnected the old HD and no joy. I found that this was due to the old drive root being sda3 and the new one sda1 thus confusing Grub. Sorted that and decided to apply Mr Meowski's infallible method of upgrading as I find Mint 17 has appeared. This worked but with one or two funnies which I haven't the details of now. But I got it working and it ran for a couple of hours OK but coming back to it I found a blank screen and the HD running constantly. After waiting an hour I reset and the system was screwed, no boot, can't find an operating system, a day of trying this and that using a laptop to get info off the net. I disconnected the new HD and reconnected the old HD and lo and behold, that was borked too. I eventually found that there was a hardware fault, processor problem I think, which had screwed the root somehow. Give up time. 2. I have another computer, no working HD, so I fitted the new drive to that. I didn't have a copy of the Mint 17 iso so I installed Mint 16 from a cd to sda1, sda2 being the original home directory. Everything worked so I then went to upgrade to Mint 17 using the Mr Meowski method. But the sources list would not work, There were in fact no entries in /etc/apt/sources.list, only a line saying # deb cdrom:[Linux Mint 16 _qiana_ - Release i386 20131128]/ trusty contrib main non-free which I assume is from the cd install. So, I went into synaptic and updated the repositories from petra to qiana and saucy to trusty, came out of synaptic and ran apt-get dist-upgrade, which it did. So, I now had a fully working installation of Mint 17 which I proceeded to embellish with all the useful cruft which I can't live without. Worked OK except that I can't seem to install a working copy of Vbox. I think it is down to my sources.list (which now has a line I put in deb http://download.virtualbox.org/virtualbox/debian qiana contrib) but doesn't work from that either. I believe that the problem is the sources this damned installation is working from. Where are they? I've had a hunt but can't find them. Any suggestions please. GeorgeYour first problem could have been completely avoided by using /dev/disk/by-uuid style paths in fstab rather than the old fashioned /dev/sdX notation - this is highly recommended in modern distros and I thought it was actually the default for most of them by now, especially Ubuntu. I'd be surprised if it couldn't have been fixed by booting any, but preferably a Mint/Debian/Ubuntu, live Linux CD or USB on the borked system, chrooting into the on-disk install and fixing it from there. "sudo grub-install /dev/sda" is usually enough to do it once you've got all your filesystems mounted correctly (including bind mounts). No idea what happened the second time around to bork your system - from sources.list only having that one entry beginning "# deb cdrom..." I'd be tempted to guess you were still actually running in the live environment, although that doesn't seem too likely. Here is a full sources.list from my current Mint 17 VM if you want to compare: ghost@mint:~$ cat /etc/apt/sources.list deb http://packages.linuxmint.com/ qiana main upstream import backport romeo deb-src http://packages.linuxmint.com/ qiana main upstream import backport romeo #Added by software-properties deb http://archive.ubuntu.com/ubuntu/ trusty main restricted universe multiverse deb http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted universe multiverse deb http://security.ubuntu.com/ubuntu/ trusty-security main restricted universe multiverse deb http://archive.canonical.com/ubuntu/ trusty partner For VirtualBox, "qiana" isn't recognised as a valid distro version as Oracle use the Ubuntu family ones instead - try this: deb http://download.virtualbox.org/virtualbox/debian trusty contrib Don't forget to import their key, etc. Did you remember to do a memtest on your new RAM? I never used to bother, but after getting bitten repeatedly by shoddy quality memory I know memtest all my new RAM as a matter of principle. I'd SMART check your 'new' drive as well, always worth checking to make sure they haven't cheekily shipped you a refurb (never seen this in person, but there are many, many horror stories on the internet). Cheers
Thanks for the sources list. Before I put those in and start fiddling I would be more comfortable if I knew where the list is that it is currently using. I've just done an apt-get update as root and got
E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
E: Unable to lock directory /var/lib/apt/lists/I'm not running any other update software. Is this implying that my source lists are in /Var?
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq