I recently found out that one of our servers has lost (probably someone deleted it) the /etc/fstab file, it's a Fedora Core 6.
Is there anything we can do to rebuild the fstab without a copy?
If system is still running you can get a copy of fstab from file /proc/mounts.
Related
I run a Linux VM on VirtualBox and just made a mistake by moving the contents in /usr to a different partition mounted as /u01. My intention was to free up space for the / file system but realized I should have used cp instead of mv. It's not possible to run any command now. Is there any way I can recover the system?
Fixed by booting with iso image and mounting the root and restored the contents back to original partition.
I installed homebrew with brew install wget and when I opened my .bash_profile it was some file I had never seen before full of homebrew's things. My aliases are still working, but I was wondering where I could find them since they're not in the txt file anymore.
I am not familiar with OSX, but I guess your old bash settings could have been backed up somewhere, because your aliases are still working. Try searching for files/directories named "bash*".
you should try using a file recovery program. it is possible the alias is referring to the location on the HDD and that the file still exists, even if the file with that name isn't accessible anymore.
a file recovery program may be a good option.
I'm working on Linux CentOS 6.5.
Can someone explain to me the following:
[root#zwoop html]# locate l4_test
/var/www/html/l4_test
[root#zwoop html]# file /var/www/html/l4_test
/var/www/html/l4_test: cannot open `/var/www/html/l4_test' (No such file or directory)
I want to delete this folder, but I'm not allowed to delete it with
rm -R /var/www/html/l4_test
Because apparently it does not exist, even though it exists...
Thanks.
As the manual describes, locate reads one or more databases prepared by "updatedb".
It may not have the latest information if it's been a while since the last updatedb.
Run it manually (updatedb) and then try locate.
In my fedora x64 system I accidently did removed the "filesystem" package while I was root , by executing this command :
rpm -e filesystem --nodeps
instead of doing this :
yum update filesystem
and unfortunatly the command executed normally and the "filesystem" package was deleted totally .
now the system is refusing to boot up showing this message :
systemd[1] : Failed to execute /bin/sh , giving up : No such file or directory
Now I can't do anything to fix it so any solutions are welcome, because I don't want to reinstall the system .
I am running an x64 Fedora 18 linux on an intel i3 processor.
I ran into the same beast on Fedora 19, after 3 hours I found a quite straight forward solution, what I did was:
Boot from Fedora-Live USB-stick of the same version installed
Mounted root into a local directory (btrfs): mount -o subvol=/root /dev/sda3 /mnt
Downloaded the filesystem package, telling yum it's working and base-directory are at my mountpoint: yum -c /mnt/etc/yum.conf --installroot=/mnt --downloadonly --downloaddir=/~ install filesystem
Since the package filesystem.x.x.x.rpm was gloriously removed by the rpm -e filesystem --nodeps command already, I installed the downloaded filesystem.rpm - at least I thought so. Turned out I had to force rpm because some other package from Google-Earth was blocking my command:
rpm -Uvh --root=/mnt ~/filesytem.x.x.x.rpm --force
Finally I edited /etc/selinux/config, I turned it off:
SELINUX=disabled
I'd take the drive out, install it in another system mount it as a secondary drive, and fool around with RPM to install the package in the specified path.
Bear in mind you'll need to manually check all your dependencies are installed too, and that you're building the correct version for Fedora 18.
I guess there might be other ways to do this too, but as long as you have another system you can connect the drive to, this might be the least effort.
I'd boot your broken system off a rescue disk on DVD, CD, USB or what have you. My experience was with Knoppix (a few years back), it was regarded as the best. However, if you don't have that, google "fedora rescue" and download that. See if that can read your hard drive, perhaps allowing you to avoid losing files of value that you had on old system, copy out to some removable media. Or, it may actually diagnose your situation and suggest fixing it for you.
Otherwise, I suspect the least-effort path back to a working system will be to install linux from scratch. The "filesystem" is not a separate package, it pretty much is the linux installation. The kernel is still present and booting, but everything else is gone.
I looked for the ISO mounted it extracted the rpm package filesystem-3.2-10.fc19.x86_64.rpm. I then looked for a live cd, boot into and mounted my former working partition and then run
rpm2cpio /root/filesystem-3.2-10.fc19.x86_64.rpm | cpio -idmv
I created a git repo in Windows 7 on a NTFS partition and when opening it in Linux (Ubuntu 12 x64, dual-boot setup) I get the index file open failed error. How can I figure out what's wrong? The partition is mounted read-write and I've never had any other problems. Does git store data in a different format Windows vs. Linux and I need to do either a clone or some conversion? I'd really like to be able to work on the same repo in both OSs without cloning around...
Clarification: I also get cat: index: Input/output error
when running the command cat index in the .git dir, so it is a NTFS related problem... but I've never had it before untill using git in a cross-systems way and I've run other apps from NTFS parts and copied files around...
The .git/index file is a binary file, which describes the current workdir. Perhaps a git fsck is able to fix it up (move the one you have out of the way to make sure it isn't lost while you fool around, or make any expertiments on a copy of the repository). You might try to clone the repository locally, the clone might get a good copy of the file, which you could then copy over the broken one.
Possibly permission problems? Backup what is relevant, defragment the drive, run hardware checks (it might be a broken/breaking disk!).
Either your Linux NTFS driver is broken, or you have filesystem corruption, or both. Reboot to Windows and run the disk checking utility, then see how things stand when it finishes.