Today: And what if I want to remove some files?
It’s easy and obvious to add new files with a driver update (DUD). But what if you need to remove some files? Or, related: can you replace some read-only file by a writable copy?
Let’s for this article assume you want to modify the Xorg configuration. Say,
/usr/share/X11/xorg.conf.d/10-evdev.conf troubles you.
The direct way would be to write an
update.pre script than removes the file and include this into a DUD.
update.pre is run right after the DUD has updated the files in the installation system.
echo \ rm /usr/share/X11/xorg.conf.d/10-evdev.conf \ > update.pre mkdud --create test1.dud --dist tw --name "remove 10-evdev.conf" update.pre
But when we try
test1.dud we run into this:
Driver Update: remove 10-evdev.conf Driver Updates added: remove 10-evdev.conf [...] rm: cannot remove '/usr/share/X11/xorg.conf.d/10-evdev.conf': Read-only file system
So, we see the catch: much of the installation system resides on a read-only file system! You can’t just go and modify things.
But how does the driver update process manage to add new files to the installation system then? It does so by restructuring the file system using symlinks. In the process all directories that need to be modified are replaced by writable copies.
In other words: if you include the file you want to remove in the DUD – you will be able to remove it. It’s actually sufficient to include the directory the file resides in to make this work.
So, let’s try this:
mkdir -p /tmp/dud/usr/share/X11/xorg.conf.d echo \ "rm /usr/share/X11/xorg.conf.d/10-evdev.conf" \ > update.pre mkdud --create test2.dud --dist tw --name "remove 10-evdev.conf" update.pre /tmp/dud
Now we don’t get any error applying
test2.dud and when we login to the installation system, we see:
console:vm9732:/ # ls -l /usr/share/X11/xorg.conf.d total 0 console:vm9732:/ #
For easy testing a DUD, boot the machine withstartshell=1 sshd=1 password=*** dud=<URL>
startshell=1wi ll stop the installation workflow after the installation system has been fully prepared just before
YaSTwill be started.
sshd=1will start an SSH daemon and you’ll be able to connect to the machine and look around.
A similar trick can be used to make files writable (watch out for correct shell quoting):
mkdir -p /tmp/dud/usr/share/X11/xorg.conf.d echo \ cp --remove-destination '$(readlink -f /usr/share/X11/xorg.conf.d/10-evdev.conf)' \ /usr/share/X11/xorg.conf.d/10-evdev.conf \ > update.pre mkdud --create test3.dud --dist tw --name "make 10-evdev.conf writable" update.pre /tmp/dud
We can verify the result:
console:vm9732:/ # ls -l /usr/share/X11/xorg.conf.d total 4 -rw-r--r-- 1 root root 1099 Apr 24 13:06 10-evdev.conf console:vm9732:/ #
The file is now writable.
Both comments and pings are currently closed.