I am using linux kernel 3.8, ubuntu 13.04, I am curious if there is a way to do this. Also, I would like to know if there is some generic reason for why this doesn't work for me. Thanks.
Device files are created with mknod. Permissions and owner can be changed with chmod and chown respectively. If the device file already exists, you may want to create a symbolic link to it instead using ln -s.
Related
I have very simple problem with approaching C drive in Ubuntu 20.04.3 on my personal computer.
I'm using command following:
cd \home\C:
But I get error: bash: cd: homeC:: No such file or directory
Do you know which command should be used to do so?
First check your mointing points, using the mount function. In case of a Windows subsystem for Linux you might have something like this:
C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,case=off)
D:\ on /mnt/d type drvfs (rw,noatime,uid=1000,gid=1000,case=off)
The part on /mnt/c (can be different in your case, obviously), shows the actual Linux folder. Please keep in mind that Linux is case sensitive.
I've gotten a USB drive in which the installation files of MATLAB are found. I've tried executing the following command but none worked. Something is wrong. The file doesn't seem executable.
This is the file I need to execute:
-rw-r--r-- 1 user user 8360 Jul 19 03:29 install
I do:
sudo sh ./install
and get:
./install: 1: exec: /media/user/DPI/R2019b/bin/glnxa64/install_unix: Permission denied
I tried chmod +x install but it also doesn't work. The file cannot be turned into an executable one.
Is the file corrupt, or do I miss something?
Probably the USB drive is formatted by the manufacturer as FAT32 or similar. This file system doesn't support UNIX permissions.
That means you lose the permission information when you copy the files to a USB drive.
You have several options to fix this:
On a Linux/UNIX system create a .tar archive of the files, copy the archive onto the USB drive and unpack the archive to a UNIX compatible file system on the destination system. (This is a bit more work but allows to use the USB drive also on a Windows system.)
Format the USB drive as a UNIX compatible file system. (This might be the best solution if you plan to use the USB drive with Linux systems only. You can no longer use it on a Windows system except if you install special drivers.)
Copy all the files from the USB drive to a local drive on the destination system, which schould have a UNIX compatible file system, and try to fix the permissions manually. (I don't recommend this solution except if you cannot use the others, e.g. if you no longer have access to the original files.)
I have a dynamic linker which is /lib64/libc.so.6
I stupidly renamed it to /lib64/libc.so.6.old and now NO commands work.
I cannot do ls or mv to rename it back.
I can run ldconfig but it says permission denied and I cannot run sudo or su - What on earth can I do to fix this? I am running Oracle Linux redhat 6.7
LD_PRELOAD=/lib64/libc.so.6.old mv /lib64/libc.so.6.old /lib64/libc.so.6
Start from a recovery/install iso and rename the file back.
If you can't reboot or don't have physical access to the machine you could try to install a compiled version of BusyBox https://busybox.net/FAQ.html#getting_started and use its su and mv commands. Since BusyBox is statically linked it should work without libc.so.
Go to single user mode, mount the file system with rw, since you know the location of the renamed file move /lib64/libc.so.6.old /lib64/libc.so.6
I would also propose a workaround with a mount point as already mentioned by #wildplasser.
You can make majority of command line tools working again if you have a mounted directory on your broken host. If you are lucky to have one then all you need is to upload the libc-x.yz.so (which you can take from another host of from Internet) on the share, rename it there to libc.so.6 and add the mounted directory to LD_LIBRARY_PATH.
If the version x.yz is the same as for the one which you thoughtlessly moved then the commands like ls, cp etc. will work again in the console where you set LD_LIBRARY_PATH. You should not logout from this console, because you won't be able to login again.
! Be aware that setuid command line tools won't work (see https://askubuntu.com/a/1029363/832810). Unfortunately "sudo" is one of them, this is why you won't be able to put back easily your long-suffering .so (unless you have a root# console). However it gives you a possibility to save all data and finish all actions before you do some hard restore.
If you managed to do the above-mentioned trick and you have enough time you can try to build a statically linked version of "sudo" as suggested on https://askubuntu.com/a/1030475/832810 (probably even build on another host and copy through NFS) and move the .so back using it.
I'm sure this has been asked before but I have no clue what to search for
I am trying to create a custom Linux image (for the Raspberry Pi) - I am currently manipulating the filesystem of the .img but I've discovered it's not as simple as dropping in the binary :( if only...
What is the accepted way to "pre-install" a package on a disk image where you can only manipulate the filesystem and ideally not run it first? Am I best to boot up, install, and then create the image from that, or is there a way of doing it beforehand in the same way you can change configuration settings etc?
Usually, when I have to change something in a disk image, I do the following:
sudo mount --bind /proc /mnt/disk_image/proc
sudo mount --bind /sys /mnt/disk_image/sys
sudo mount --bind /dev /mnt/disk_image/dev
These action are needed as this folder are create during boot process, mounting them in your system image will emulate a full boot. Then, you can chroot on it safely:
sudo chroot /mnt/disk_image
You're now able to issue commands in the chroot environment:
sudo apt-get install chromium
Of course, change /mnt/disk_image to the path where you have mounted your filesystem. apt-get will only works on Debian based system, change it according to your distribution.
You could find problem connecting to the internet and it can be cause by DNS configuration. The best thing you can do, is to copy your /etc/resolv.conf file in the remote filesystem as this file is usually changed by dhcp and it's empty on chroot environment.
This is the only solution that gives you full access to the command line of the system you're trying to modify.
This is an untested idea:
The dpkg tool, which can install .deb packages, has a --root option which can set a different filesystem than the local / path.
From the man page:
--instdir=dir
Change default installation directory which refers to the
directory where packages are to be installed. instdir is
also the directory passed to chroot(2) before running
package’s installation scripts, which means that the
scripts see instdir as a root directory. (Defaults to /)
--root=dir
Changing root changes instdir to dir and admindir to
dir/var/lib/dpkg.
If you mount your image and pass its mountpoint as --root, it should work.
There are things like the Ubuntu Customization Kit which allow you to create your own version of the distro with your own packages.
Crunchbang even has a utility like this, which is the distro I have personally selected for experimenting with my Pi.
We're trying to use oprofile to track down performance problems on a server cluster. However, the servers in question have a read-only file system, where /var/tmp is the only writeable directory.
OProfile wants to create two directories whenever it runs: /root/.oprofile and /var/lib/oprofile, but it can't, because the filesystem is read-only. I can use the --session-dir command line option to make it write its logs to elsewhere than /var/lib, but I can't find any such option to make it use some other directory than /root/.oprofile.
The filesystem is read-only because it is on nonwriteable media, not because of permissions -- ie, not even superuser can write to those directories. We can cook a new ROM image of the filesystem (which is how we installed oprofile, obviously), but there is no way for a runtime program to write to /root, whether it is superuser or not.
I tried creating a symlink in the ROM that points /root/.oprofile -> /var/tmp/oprofile, but apparently oprofile doesn't see this symlink as a directory, and fails when run:
redacted#redacted:~$ sudo opcontrol --no-vmlinux --start --session-dir=/var/tmp/oprofile/foo
mkdir: cannot create directory `/root/.oprofile': File exists
Couldn't mkdir -p /root/.oprofile
We must run our profilers on this particular system, because the performance issues we're trying to investigate don't manifest if we build and run the app on a development server. We can't just run our tests on a programmer's workstation and profile the app there, because the problem doesn't happen there.
Is there some way to configure oprofile so that it doesn't use /root ?
I guess it should be as simple as overriding the HOME environment variable:
HOME=/tmp/fakehome sudo -E opcontrol --no-vmlinux --start --session-dir=/var/tmp/oprofile/foo
If that doesn't work out, you could have a look at
unionfs
aufs
to create a writable overlay. You might even just mount tmpfs on /root,or something simple like that.
It turns out that this directory is hardcoded into the opcontrol bash script:
# location for daemon setup information
SETUP_DIR="/root/.oprofile"
SETUP_FILE="$SETUP_DIR/daemonrc"
Editing those lines seemed to get it working, more or less.