I am making my own AMIs (Virtual machines on Amazon's EC2). I can't use the default kernel. I have to use one of the other provided amazon kernels. I am trying to make this AMI be really really easy to use and make sure an idiot can start it up. However there is the important step where they have to choose this kernel. Is there anyway to 'associate' a kernel with an AMI? I'd like if, when someone is launching this AMI, that kernel is automatically and always the selected choice in the 'Choose your kernel' select box. This way, someone can just click Next, next, next etc. to start it
Sure you can. From the docs:
In addition to specifying an AKI at
launch time, you can create new AMIs
that launch with a specified AKI by
default. You can either rebundle an
existing instance that was bundled
with the desired AKI (as described
above) or you can provide optional
arguments to the ec2-bundle-vol
command.
Related
The title really says it all, but just in case, here's some context:
Each time you change your configuration in NixOS, you need to run nixos rebuild to create a new boot image, which will be listed in Grub when you start the computer. A new configuration might require a new kernel. If it does, and you build it, will your old configurations continue to work?
In Ubuntu it appears that one can indeed host multiple kernels on the same machine. And I read somewhere the linux kernel can be pretty small, like 60 MB. Those two facts lead me to expect NixOS will retain the old kernels. But I haven't found anything online that really makes that explicit.
I am currently building a configuration that uses Musnix. If you ask for it, Musnix will build you a realtime kernel. I'm currently building such a new configuration, and hoping I'll still be able to boot my computer after it. I worry because GIthub user #magnetophon, who is involved in Musnix's development, said the Musnix realtime kernel is borken.
This is one of the cool features of NixOS. When you run nixos-rebuild boot (or nixos-rebuild switch too for that matter), it will create new boot entries alongside the old ones. These entries have the right kernel and system configuration in them. So if your experimental kernel doesn't work, you can just reboot and start a previous version of your system, knowing that it will work, even if your kernel also came with userland changes.
The nixos-rebuild command is documented here in the NixOS manual: https://nixos.org/nixos/manual/#sec-changing-config
My embedded board uses Linux Kernel version 3.18.
I would like to configure my Wifi (using wpa_supplicant and then dhcpcd commands) automatically, as soon as the board boots up.
I made a shell script for the same (I verified the script by executing it manually) and placed this in "/etc/init.d" directory.
Then made a symbolic link to the shell script file in the "/etc/rc.d" directory.
However, doing this change does not serve my purpose. Can anyone please help me out.
PS: It is important to note that it takes around 3-4 seconds for my Wifi module to be inserted into the kernel once the board boots up.
TLDR;
in initscript call differant script managing wpa_supplicant,dhcpd so that init-script won't block.
It is nice practice not to block in init-scripts. so you can do differed processing in init-script. i.e. start different script in background which checks module insertion and wpa_supplicant also can modify it to keep checking status. Something similar happens in Desktop Linux OS. The program name is NetworkManager.
I was wondering if it is possible to gather information about a running virtualized system (e.g. enumerating processes, finding window captions, window positions on a windows system).
My naive approach was using ReadProcessMemory() on vmware-vmx.exe and searching for data structures like _tagWND. This didn't work out as expected. :/
I don't want to "touch" the guest system if I don't have to.
So, how could I achieve this?
There are APIs to talk to the VMware Tools inside the guest. See the VMware VIX API here.
In the list of common tasks from the documentation, there are the following guest operations that would probably do what you're after:
VixVM_ListProcessesInGuest()
VixVM_RunProgramInGuest()
VixVM_RunScriptInGuest()
I am trying to open the X display like so:
disp = XOpenDisplay(NULL);
When I run this from my users shell it works fine but if it is run from a udev event (Ubuntu 10.10) the function call returns NULL. I wondered if this has something to do with the differing environment so have tried XOpenDisplay(":0.0") also but no avail.
Does anyone know why this happens?
XOpenDisplay(NULL) would inspect the DISPLAY environment variable, which usually is not set in udev context. To be able to use XOpenDisplay(something) (including something=NULL), you need the access key to the X server instance.
The XAUTHORITY environment variable is to be set to the location of the key file if you want to use XOpenDisplay or any graphical program that makes use of it. If this env var is empty, ~/.Xauthority is used as a fallback.
Trying to start some graphical program from udev is a bad idea (read: something is wrong in your approach and design): You don't know the X display number. You cannot guess it either, because there may be very well more than one X server active. And then you need to have its key file, which is not always possible to determine or obtain either. udev may run as root, but there are things like NFS mounts with root_squash, and the XAUTHORITY variable with which people can relocate their key file.
The way graphical problems work these days is that the user, or the desktop environment s/he is using, has to start a background program specifically listening for certain events. Just so that you cannot simply intrude on people's screens, but have to abide by their event notification system.
I am porting an application which runs as a background service in windows at startup, we are porting the application to linux(SUSE Enterprise server), I'am completely new to linux. Can somebody help me on how to proceed with this. Like
Should I build the linux executable
After builiding the binary, what changes should I make to linux startup files to run this executable
How my service can register call back function to modify or change or send commands to my service while it is running
Yes, you should build a Linux binary. You may want to rephrase your question since I doubt this is the answer you want :-)
You should generally create what is known as an "init" file, which lives in /etc/init.d. Novell has a guide online which you can use to author the file. Note that while the init file is common, the exact method of letting the operating system use it varies depending on the distribution.
This is going to be a marked change for you. If you are doing simple actions such as re-loading a configuration file, you can use the signals functionality, especially the SIGHUP/HUP signal which is generally used for this purpose. If you require extended communication with your daemon, you can use a UNIX domain socket (think of it as a named pipe) or a network socket.
Another task you are going to need to accomplish is to daemonize your application. Generally this is done by first fork()ing your process, then redirecting the stdin/stdout pipes in the child. There are more details which can be answered by reading this document
See how-to-migrate-a-net-windows-service-application-to-linux-using-mono.
Under Linux, deamons are simple background processes. No special control methods (e.g start(), stop()) are used as in Windows. Build your service as a simple (console) application, and run it in the background. You can use a tool like daemonize to run a program as a Unix daemon.