It appears you can put all you need in /bin so why do we bother with the /usr/bin directory?
/bin is supposed to reside on the root filesystem, whereas /usr may be an alternate filesystem - even network mounted (multiple boxes sharing the same /usr).
This means that any essential basic utilities you need to bring up the system and mount filesystems, including troubleshooting, should live in /bin. Everything non-essential can go in /usr.
Related
I have had some .cpp programs in root directory of my BeagleBoneBlack (Debian). Due to a studpid accident a /usr directory was deleted on my BeagleBone. It make sense for me now, that I can not access the BeagleBone anymore. What I can do is to boot the BeagleBone from SSD-card, but of course I come in this case to another root directory. Do I still have chance to access my .cpp programs from old root directory? The most funniest thing in the story of my stupidness is that I didn't store .cpp programs somewhere else.
Thank you all in advance!
Yes, boot a regular SD-card image (make sure there is no "flasher" in the image name).
Once booted you can mount the eMMC and access your files. Something like this should do the job:
mount /dev/mmcblk1p2 /media
ls /media/root
Depending on what you have installed on the eMMC it may be a different partition (last digit) like mmcblk1p0 or mmcblk1p1.
You can then get the files from /media/root e.g. via SCP (winSCP if you are on Windows).
I need to add files to an initramfs file(I own the file as this is for some other device), however I do not have root permissions on my development machine. The usual way would be to unpack the initramfs, add files, change owner to root and pack again. I can not do this, as changing owner on this machine would require root permissions. If I do not change owner the system might behave weird(and it is just not a clean setup).
I can not do this on the target system as it is an embedded system, which only has read only access to the initramfs file.
Is there any way to change the permissions during or after packing the cpio archive?
Use fakeroot to deal with permissions during extraction and compression. it is developed to provide root environment without actually being root.
girishp#~/incoming$ /usr/bin/fakeroot /bin/bash
root#~/incoming$
I'm running into an issue where I do not have write access to the /var directory on a UNIX environment, and InstallAnywhere doesn't provide me the option of writing the .com.zerog.registry.xml to any other location for a product installation. Is there a parameter out there that allows for this file to be written to a different directory?
According to the IA docs:
If logged in as root, the global registry is located in \var.
If logged in as a user, it is located in the user’s home directory.
So, if you're running as root and can't write to /var, it sounds like a permissions problem with the /var directory, independent of IA. Check the permissions on /var.
If you're running as a non-root user, then the registry shouldn't be going to /var, but to $HOME/.com.zerog.registry.xml (FWIW, I just checked one of our test Linux boxes and found .com.zerog.registry.xml under both /var and under test-user $HOME directories. The docs appear to be correct).
I've also seen some very strange behavior if IA is low on space in $TMP. Make sure you have plenty of space there.
Also, have you considered running the installer with sudo, or the graphical equivalents kdesudo (KDE) and gksu (Gnome)? Those might get you where you want to go.
If I start a new distro (e.g. LFS):
How can I change the directory structure?
What should I expect after it's ready? (probably can't install most of the packages without modification, right?
But, before you down vote: I've been asked to make a new distro for a specific project which they need (actually, want) a new directory structure with a few changes, for example remove the var and bin directories, but without halting the system. The application of this distro is so limited, so i think it shouldn't be a big deal as they need just a few packages to be installed.
These are few pointers that come to my mind and definitely it is not complete:
Your PATH should be updated in the startup scripts like ~/.bashrc, /etc/profile.d, and so on to reflect the updated directories.
Configuration files tend to use /var quite often. (/var/log, /var/tmp) You'd need to modify all these location references.
Basically your kernel is going to start /sbin/init which is going to start the initialization at /etc/rc.d or equivalent. If you start tracing all the scripts and services invoked in these startup scripts, I believe you should be able to capture all the places you'd need to modify the path names.
you can create a folder called system and the move all the files into the /system folder. and after that create symlinks, so the system can still be used. example:
su -i
cd /
mkdir system
mv /usr /system/usr
ln -s /system/usr /usr
I just did it........it broke my system XD (i think it was because i moved all the files into /system , including /boot witch is used by GRUB)
The chance of breaking the system is huge if you don't have background knowledge. Example if you move /bin to /system/bin, then you won't be able to create the symlink afterwards because the ln command (which is a program) is located in the /bin folder so moving it will end up in an error.
also, check out gobolinux.org which is based around what i just did. The entire system has been reorganized and to maintain compatibility, they have created symlinks so that they don't have to reprogram an app when porting applications.
Can I safely rename the cygdrive folder? Also, I would like to add other folders at root and map them to folders on windows in the same way as /cygdrive/c maps to my C drive. Is that possible?
Yes, you can. See The Cygwin Mount Table in Cygwin's documentation. I have my documents folder mounted as /doc. These mounts end up in the registry and are retained across reboots etc.
I wouldn't rename cygdrive as I don't know what that would do, but you can map other directories at root to various windows directories using the mount command.