Score:1

Accidentally deleted /bin on Ubuntu 16.04

de flag

I deleted /bin folder on Ubuntu 16.04 by mistake. There was a folder named bin in home folder and I deleted /bin folder instead ~/bin folder in home folder. Unfortunately, when I restarted my PC, it didn't boot.

I have important files in home folder and the home folder it is not in separate partition from OS. Is upgrading the system to a newer version via bootable USB flash useful to solve this problem?

guiverc avatar
cn flag
[Ubuntu 16.04 LTS has reached the end of it's *standard* support life](https://fridge.ubuntu.com/2021/03/13/extended-security-maintenance-for-ubuntu-16-04-xenial-xerus-begins-april-30-2021/) thus is now off-topic here unless your question is specific to helping you move to a supported release of Ubuntu. Ubuntu 16.04 ESM support is available, but not on-topic here, see https://askubuntu.com/help/on-topic See also https://ubuntu.com/blog/ubuntu-16-04-lts-transitions-to-extended-security-maintenance-esm
guiverc avatar
cn flag
As to your upgrade solution question; you specify Ubuntu 16 at one point but tagged 16.04 (different products), and didn't say if Desktop or Server; but assuming 16.04 Desktop; yes an *upgrade via re-install* would fix the issue. If you use *Something else*, select existing partition(s) but do **not** format, no user file is touched. System directories are wiped (thus it'll fix your issue) before re-install, even additional packages get re-installed (if available in Ubuntu repos) assuming you don't format!
Jano avatar
de flag
Sorry os is ubuntu 16 desktop so If upgrading the system didn't solve the problem, would the second solution u assumed help me?
guiverc avatar
cn flag
Ubuntu products that use the *year* format are designed for *headless* operation, servers usually on devices/appliances or in the cloud; eg. Ubuntu Core 16. Ubuntu desktop releases are all *deb* based and use the *year.month* format unlike *year* products which are *snap* only.
guiverc avatar
cn flag
Yep. it's what I'd do , *upgrade via re-install* using *Something else*, re-use the partitions but do **NOT** format as that is the trigger for the install method I'm suggesting. It doesn't matter than /home shares the same partition - key is you do **NOT** use any install that uses format (that will erase your data!) You should backup first from a *live* system.
Jano avatar
de flag
Ok thank u very much
Score:4
cn flag

On Ubuntu Desktop releases (inc. flavors), you can Upgrade via re-install.

Boot the live system

Start the ubiquity installer for Ubuntu Desktop and using Something else (Manual Partitioning with calamares)

  • Select your existing partition(s)
  • ensure you don't have FORMAT tagged

It will cause the following to occur

  • your installed packages are noted
  • your system directories are erased (desktop apps don't store data in system directories; some server apps do though)
  • new system is installed
  • any additional packages you had installed (noted earlier) get re-installed IF available in your new release from Ubuntu repositories
  • no user file is touched (unless you selected format)
  • you are asked to reboot

It's far faster than a release-upgrade, and my usual fall back for an install that went wrong (and I'm too lazy to fix it), or I don't have time to release-upgrade.

Complications can occur if you have an encrypted system, as Ubuntu 17.10 & earlier used different encryption to 18.04 & later, so the package some encrypted installs need is no longer included by default; but that can be worked around via a manual install during the live session prior to starting the installed (ubiquity).

Of course, and as always you should always have backups as things can happen (power goes out etc) so backup your data first using the live session prior to install.

guiverc avatar
cn flag
To me the question (*as currently written*) is still off-topic; as it's about an EOL/ESM release. If however the question was written (it currently mentions it in minor detail) to be about re-install fix; then this answer is on-topic...
guiverc avatar
cn flag
Also FYI for anyone using this type of *upgrade via re-install*. It's common for you to get an error message at the end of the install that packages could not be re-installed; this is not unexpected; eg. if going from 18.04 to 20.04 both Qt4 & python2 were removed from repositories due EOL so packages that required those weren't available in *focal*... 16.04 -> 18.04 was too long ago for me to now recall what occurred between *xenial* & *bionic* cycles; but packages are likely to have been removed; let alone 3rd party packages are more problematic.
Score:1
zw flag

I see the following way to recover your current Ubuntu 16.04 LTS version without reinstall:

  1. You boot the original installation Ubuntu 16.04 LTS LiveCD/LiveUSD in Try Ubuntu mode, then mount your current operating system partition and copy /bin folder from LiveCD/LiveUSB to the OS partition by using command like sudo cp -ar /bin /media/ubuntu/OS/ or with GUI, then reboot;

  2. After first successful login to your OS, you can reinstall the packages which have files in /bin by using command below:

    sudo apt-get update
    sudo apt-get install --reinstall $(dpkg -S /bin | sed "s/,//g" | sed "s|: /bin||")
    
  3. To keep system consistent locate extra executable files which were copied from LiveCD/LiveUSB, but should not exist in your OS, and remove them manually by using command below

    find /bin -type f -exec dpkg -S {} \; 2> ~/not-from-apt.out
    

    then carefully inspect the contents of ~/not-from-apt.out and remove binary files which are listed here. Or use one-liner below if you are sure:

    sudo rm -v -i $(cat ~/not-from-apt.out | awk '{print $7}') 
    
  4. Then upgrade this system to newer 18.04 LTS release by sudo do-release-upgrade or by using update-manager -c.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.