This switches various things to use /dev for device nodes instead of /tmp.
Tested by installing on a box with both raid and LVM. I suppose long-term
we'd switch to udev and just assume the device nodes are there.
Bill
Hello,
I am developing a fedora spin using pungi for a custom 'appliance' which
uses a serial touchscreen interface; there is no keyboard nor mouse.
I have written a small application which uses the touchscreen so the
user can select either a full install or an upgrade. The application
then writes the appropriate kickstart file to automate the anaconda
installation. I have read the anaconda source code and have 2 questions
I could not answer by looking at the code alone:
1) How can I launch my application before anaconda? I've seen
references to /sbin/loader; but I don't understand how /sbin/loader
starts anaconda. Is this hardcoded in the loader? Is there a config
file that controls what application the loader starts?
2) A follow-up question; once getting the loader to start my application
before anaconda, how would I configure the x server to also contain the
configuration for the touchscreen?
Thanks
Sean
The attached:
1) cleans up/simplifies readImageFromFile, removing options no longer used
2) introduces a readIconFromTheme, which pulls icons from the system theme
3) uses readIconFromTheme, where available, using XDG standard names
Comments?
Bill
this patch takes care of the anaconda side of taking advantage of
livecd's created with a livecd-tools that has
turboLiveInst/genMinInstDelta support. But the code does check for the
legacy situation, and handles it gracefully. Thus this patch is safe
even in the absence of the actual beneficial final patch to livecd-tools.
even if turboLiveInst/genMinInstDelta didn't depend on this, it is not a
bad idea to move resize2fs earlier in the anaconda livecd backend.
Though practically, this is entirely for the benefit of turboLiveInst.
even if turboLiveInst/genMinInstDelta didn't depend on this, it is a
good idea anyway for anaconda's livecd backend to use dumpe2fs to
determine the size of data to copy during install, rather than looking
at the size of the block device holding the filesystem.
logically there is no reason why resize2fsToMinimal should require an
argument of the size in blocks of the filesystem that is passed in as
it's first argument, when that can be calculated by pointing dumpe2fs at
that first argument.
This series of 7 patches is a pure split of the prior turboLiveInst v3
monolithic patch. (i.e. produces identical tree, therefore I have done
no further testing)