Uh-oh. Command not found
Because Firefox kept locking up and various other things were out of date, I decided to upgrade to the latest version of Linux Mint. The upgrade seemed to work but resulted in a blank desktop, so I decided a complete re-install was required. So I backed up the /home directory to an external USB hard drive, programmed a USB key with a Mint .iso and booted up into the latest Mint. That went fine. Then I tried to restore the backup of the home directory, the computer announced that it couldn't read the file, something about 'bad superblock', which is enough to bring one's heart to a complete and utter stop. *Fortunately*, bumping against the USB cable got it working, and I think the problem was a bad connector. OK, piece of cake from here on, right? Then in the process of moving files from the backup to my home directory, I forgot that I was in superuser mode and ~ was shorthand for /root. That made a mess, and in the process of sorting out that, I moved the /bin directory. So of course, no commands worked at all. (This reminds me of the scenario where someone executes rm -rf * in superuser mode and only discovers the mistake when the computer announces: rm command not found. I know someone who actually did that. (Not me ;) ). Arrrgh. So I decided that the simplest route was to re-install. Then, for some reason, the USB key wouldn't boot. Fortunately, an old Knoppix CD did boot, establishing that boot from CD was still working. So I prevailed on my friend Gabriel to burn me an .iso on DVD, and that worked. So, to my colleagues in TLUG, I ask: How would you deal with the re-location of /bin, assuming you didn't want to re-install? Peter -- Peter Hiscocks Syscomp Electronic Design Limited, Toronto http://www.syscompdesign.com USB Oscilloscope and Waveform Generator 647-839-0325
On Mon, 6 Jul 2015, phiscock@ee.ryerson.ca wrote:
Because Firefox kept locking up and various other things were out of date, I decided to upgrade to the latest version of Linux Mint. The upgrade seemed to work but resulted in a blank desktop, so I decided a complete re-install was required.
So I backed up the /home directory to an external USB hard drive, programmed a USB key with a Mint .iso and booted up into the latest Mint.
If you keep /home on a separate partition, you wouldn't have this problem. ...
So I decided that the simplest route was to re-install.
Then, for some reason, the USB key wouldn't boot. Fortunately, an old Knoppix CD did boot, establishing that boot from CD was still working. So I prevailed on my friend Gabriel to burn me an .iso on DVD, and that worked.
So, to my colleagues in TLUG, I ask: How would you deal with the re-location of /bin, assuming you didn't want to re-install?
PATH=$PATH:/path/to/bin Or: mv /path/to/bin / -- Chris F.A. Johnson, <http://cfajohnson.com>
On 6 July 2015 at 22:19, Chris F.A. Johnson <chris@cfajohnson.com> wrote:
If you keep /home on a separate partition, you wouldn't have this problem.
Something I've wondered about doing this: /home doesn't only contain data files created by the user. There are also many hidden files created by the system and programs, usually in the root of the user's home directory. For example: .config and .gconf. If one were to install a new distribution, or even just a newer release of the same distribution, and then simply re-mount the /home partition afterwards, might not there possibly be some problems with these hidden files containing incorrect information? Do most programs that create these files sort things out for themselves? -- Scott
On 15-07-07 11:07 AM, Scott Allen wrote:
On 6 July 2015 at 22:19, Chris F.A. Johnson <chris@cfajohnson.com> wrote:
If you keep /home on a separate partition, you wouldn't have this problem.
Something I've wondered about doing this: /home doesn't only contain data files created by the user. There are also many hidden files created by the system and programs, usually in the root of the user's home directory. For example: .config and .gconf.
If one were to install a new distribution, or even just a newer release of the same distribution, and then simply re-mount the /home partition afterwards, might not there possibly be some problems with these hidden files containing incorrect information? Do most programs that create these files sort things out for themselves?
I have kept /home on a separate partition for as long as I can remember. Makes an upgrade much easier. Programs find their .conf files and continue as before the upgrade. Never an issue with permissions. Of course if you change your user name, there will be issues :) -- Stephen
On 7 July 2015 at 11:07, Scott Allen <mlxxxp@gmail.com> wrote:
On 6 July 2015 at 22:19, Chris F.A. Johnson <chris@cfajohnson.com> wrote:
If you keep /home on a separate partition, you wouldn't have this problem.
Something I've wondered about doing this: /home doesn't only contain data files created by the user. There are also many hidden files created by the system and programs, usually in the root of the user's home directory. For example: .config and .gconf.
If one were to install a new distribution, or even just a newer release of the same distribution, and then simply re-mount the /home partition afterwards, might not there possibly be some problems with these hidden files containing incorrect information? Do most programs that create these files sort things out for themselves?
In theory it should be the program's problem: you're a loyal user who's been using their product for a while, the program should recognize and convert/update from previous formats. In practice it's hit-and-miss: one of my favourite window managers, wmii, breaks its old ~/.wmii/... file formats every couple years and I have to wipe them, learn the new format, and re-configure. It sucks. It depends on the program. I remember having to do it once long ago (like a decade) with KDE, but mostly the big names play nice these days. -- Giles http://www.gilesorr.com/ gilesorr@gmail.com
| From: Giles Orr <gilesorr@gmail.com> | In theory it should be the program's problem: you're a loyal user | who's been using their product for a while, the program should | recognize and convert/update from previous formats. I've worried about the same problem. And a variant: sometimes I have several distros on the same machine and I'd love to share /home. I don't do it because I don't trust it to work. I even worry about sharing /home between different releases of the same distro. Going forward seems to mostly work. I don't know about going backward. I wish that the . files were it some place other than ~. Or that there was some other solution. Some of my . files are universal, for all systems (eg. .joverc). Others are specific, often in ways I don't even understand. For example, what's .dbus? .cache? What's in .gnome2 and .gnome2_private? $PATH says how to search for executables. Perhaps we need something like that for searching for . files (ending with /etc/skel?).
So, to my colleagues in TLUG, I ask: How would you deal with the re-location of /bin, assuming you didn't want to re-install?
PATH=$PATH:/path/to/bin
Or:
mv /path/to/bin /
In the heat of the moment, I thought of PATH as something one changes by editing configuration files, but yeah, you can simply type in a new one. Good to remember. I also didn't realize that some commands are built into the shell, so some things remain possible even if bin isn't reachable. I know it's not the Unix Way, but an 'undo' button would be nice for these situations. Peter -- Peter Hiscocks Syscomp Electronic Design Limited, Toronto http://www.syscompdesign.com USB Oscilloscope and Waveform Generator 647-839-0325
On Mon, Jul 06, 2015 at 09:50:34PM -0400, phiscock@ee.ryerson.ca wrote:
Then, for some reason, the USB key wouldn't boot. Fortunately, an old
Strange that USB would boot once, but not twice.
Knoppix CD did boot, establishing that boot from CD was still working. So I prevailed on my friend Gabriel to burn me an .iso on DVD, and that worked.
So, to my colleagues in TLUG, I ask: How would you deal with the re-location of /bin, assuming you didn't want to re-install?
Just move /bin back to original location. :-) I'm sure there was reason for not able to that. Other than that, - keep /home in separate partition, as Chris suggested. - keep backup. I do 4 complete cron backups (hourly, daily, weekly, and monthly), and 1 manual backup (electrically disconnected). It used to be the other way around, 1 cron and 4 manual, but I got tired of swapping harddisks.
On 15-07-06 09:50 PM, phiscock@ee.ryerson.ca wrote:
So, to my colleagues in TLUG, I ask: How would you deal with the re-location of /bin, assuming you didn't want to re-install?
If you knew where /bin wound up I would just move it back. If it said it can't find 'mv' I could type /path/to/bin/mv to move the wandering /bin back to its normal home. If that failed I always keep bootable Linux discs on hand. I have a CD case that holds 6 discs and it has the last couple of versions of the Linux live/install DVD's I've used along with some other useful discs such as tomsrtbt. I just completed updating my system from Linux Mint 17 (32-bit) to Linux Mint 17.2 (64-bit). My /home is in a separate partition and I have four 20G partitions that I use as root partitions. One of the four is the current system root, another is a backup of root from the last time I was about to do an update/upgrade of the distro and the other 2 can be used to try out other Linux distros (if I have the time and/or interest to try something different). The separate /home meant that my user account wasn't affected. After the install was complete I just logged in to my user account as always and got back to work. Well, after the usual need to sort out a minor issue or three which one often has to do after a fresh install. -- Cheers! Kevin. http://www.ve3syb.ca/ |"Nerds make the shiny things that distract Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're | powerful!" #include <disclaimer/favourite> | --Chris Hardwick
participants (8)
-
Chris F.A. Johnson -
D. Hugh Redelmeier -
Giles Orr -
Kevin Cozens -
phiscock＠ee.ryerson.ca -
Scott Allen -
Stephen -
William Park