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$
Related
I have an application in /opt/MyApp that I need to pack into an RPM package using FPM as follows:
fpm -e -s dir -t rpm --name 'MyApp' --version '1.0' --iteration "12345" --directories /opt/MyApp --epoch 0 /opt/MyApp
(other options are not relevant here)
All files and directories in MyApp are owned by root (both user and group). Also there is a directory called "help" with different permissions like
drwxrwxrwx.
i.e. all users can write into that directory.
When I inspect the spec file generated by FPM, it has
%defattr(-,root,root,-)
and all directories (%dir) and files are then listed, so I would expect that all original permissions are preserved in this package. However, when I inspect it using
rpm -qlvp MyApp.rpm
the permission on the "help" directory are reset to:
drwxrwxr-x
i.e. other users cannot write there anymore.
My first guess was to add the option
--rpm-use-file-permissions
but it made things even worse, because now all files in RPM are owned by the user that called FPM.
Edited:
I've achieved the result using
--rpm-use-file-permissions --rpm-user root --rpm-group root
but still it doesn't feel elegant and flexible.
Thanks in advance.
The comment about %defattr, and absence of comments about the BUILDROOT tree may indicate some confusion. According to rpm.org:
If a particular attribute does not need to be specified (usually because the file is installed with that attribute set properly), then that attribute may be replaced with a dash
That is, if no explicit permission is given in %defattr, then the permissions from build-time %install when constructing the rpm are satisfactory. There is no guarantee that those match (or are even compatible with) the actual system on which the rpm is later installed.
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.
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.
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.