I want to know how to build grub 2 bootloader from it's source in ubuntu and test it with qemu emulator.
I would also like to change the default background image of grub2 bootloader in the new build?
Is this possible? If yes, how ?
Of course you can.
As shown on the GRUB website, the grub source code is available via git from git.savannah.gnu.org.
Then it is theoretically just a question of
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
However, depending on your platform, grub's default target platform may or may not be what you want. So you will need to decide which firmware platform you want to use in QEMU, which depending on your architecture can be something like
(pc) BIOS
coreboot
(U)EFI
ieee1275 (open firmware)
u-boot
Your mentioning of Ubuntu matches at least 3 possible options from the above, but I'm going to be boring and assume you mean x86_64/amd64. Since you will be running GRUB under QEMU, it does not really matter which of the two likely platforms ("pc" or "efi") your physical computer is running. So let's live a little and go for the (U)EFI variant.
You will need some prerequisites installed before configuring and building, so
$ sudo apt-get install build-essential autoconf automake
$ sudo apt-get build-dep grub-efi-amd64
So a practical build may look a bit like this:
$ # Next command is optionnal (languages):
$ ./linguas.sh
$ ./autogen.sh
$ # Next parameters are optionnal:
$ ./configure --prefix=$HOME/local --platform=efi
$ make
$ # Next command is optionnal:
$ make check
$ make install
The easiest way to get a functioning GRUB image is probably with the grub-mkstandalone command:
$ $HOME/local/bin/grub-mkstandalone -O x86_64-efi -o mygrub.efi
Note: To install grub on /dev/sda disk (instead of QEMU), use:
$ sudo grub-install /dev/sda
Note: If you don't see GRUB menu when booting, check this question. It involves pressing Shift when booting or editing /etc/default/grub to comment GRUB_HIDDEN_TIMEOUT.
Then you need some kind of UEFI image to run under your QEMU. The default choice for x86 is called OVMF and is part of Tianocore EDK2 - the de facto open source implementation of UEFI. Due to legal technicalities with regards to redistribution of the FAT filesystem driver, many Linux distributions (including Ubuntu) do not include a pre-built one. But have no fear, it is pretty straightforward to build one yourself.
However, I am not going to take this answer further off-topic than I already have, so all I am going to say is have a read through the OVMF README and look through one or two only slightly outdated blog posts about it.
Related
I found in QEMU NIOS IP https://wiki.qemu.org/Documentation/Platforms/Nios2
I have downloaded intel tool chain from their website : https://www.intel.com/content/www/us/en/programmable/products/boards_and_kits/dev-kits/altera/kit-niosii-2s60.html
I have few questions:
Is the NIOS2 in QEMU IP matching intel’s NIOS IP ?
What is the toolchain you use to compile and run it in QEMU ? Is it same tool-chain as provided by intel’s website ?
How to general Firmware code and run it on NIOS over QEMU. In the Wiki it says:
qemu-system-nios2 -M 10m50-ghrd -kernel -dtb -nographic
How to generate dtb file for it?
Do we need to take products created by the quartos/EDS for the running of the QEMU, other from the compiled binary? (DTB - board specification?)
Do we need to run it with specific QEMU parameters/arguments ?
Do you have code examples for NIOS using its peripherals?
Basically, I didn’t find any documentations/examples about how to use the NIOS2 in QEMU. Can you help with some additional info ?
Even some basic “hello would” (compile and run in QEMU) would be great…
UPDATE: the most up-to-date answer to this question may be to analyse the linux console nios test at https://gitlab.com/qemu-project/qemu/-/blob/master/tests/acceptance/boot_linux_console.py#L1029 (or of course contact a maintainer). The kernel image from advent calendar 2018 day 14 runs great. It looks like it can all be done with buildroot.
My comments started bearing fruit, so I'll try to put a partial answer together. I haven't gotten this to work yet, but maybe this can be helpful to others who might work farther.
NOTE: If you just want to run a single nios2 binary, you can pass it straight to qemu-nios2. qemu-system-nios2 is for running linux.
I believe the qemu behavior is functionality rather than intellectual property. It would be a bug if it mismatched. I do not know whether it does. Mentioning IP here, please remember that open source projects are generally run by a handful of vulnerable caring devs who usually have no legal team if ownership of intellectual property is challenged. If there's an issue, it would be polite to refer the concerning party to https://eff.org/ who often legally represents such things.
I expect that any nios2 toolchain works. Here's a toolchain from a quick internet search that led me to bootlin.com. Appears to include instructions on how to duplicate it from source.
See 4
Here is what I have so far for firmware generation:
# set up a toolchain (note: this old step is redundant with buildroot, lower down, which also installs a toolchain and even builds a kernel if asked)
wget https://toolchains.bootlin.com/downloads/releases/toolchains/nios2/tarballs/nios2--glibc--stable-2020.08-1.tar.bz2
tar -jxvf nios2--glibc--stable-2020.08-1.tar.bz2
# get kernel sources (pass --depth 1 to speed up)
git clone https://github.com/altera-opensource/linux-socfpga.git
# build kernel and device tree
cd linux-socfpga
make ARCH=nios2 CROSS_COMPILE=$(pwd)/../nios2--glibc--stable-2020.08-1/bin/nios2-linux- 10m50_defconfig 10m50_devboard.dtb vmlinux -j5
cd ..
# kernel is now at linux-socfpga/vmlinux
# device tree is now at linux-socfpga/arch/nios2/boot/dts/10m50_devboard.dtb
# set up buildroot to build a root image
git clone https://github.com/buildroot/buildroot.git
cd buildroot
# configure for qemu nios2
make qemu_nios2_10m50_defconfig
# build root image
PERL_MM_OPT= LDFLAGS= CPPFLAGS= LD_LIBRARY_PATH= make
cd ..
# rootfs images are now in buildroot/output/images/
I'm afraid I'm just a visitor and I don't know who quartos/eds are or what compiled binary you are referring to.
The qemu command line appears to be qemu-system-nios2 -M <machine> -kernel <kernel file> -dtb <dtb file> <rootfs image file>. The example machine is 10m50-ghrd which we built the kernel for above, and this may be the only one.
not yet! i'll try to update this answer if i get farther. feel free to edit it if you get farther.
I'd like to install programs with conda in one particular conda environment and to be able to use the associated commands from all conda environments.
My goal is to allow students to install Mercurial (plus few Mercurial extensions and related utilities like Meld and TortoiseHg) on any platforms (especially Windows) with one simple command (or few simple commands), and of course without compilation.
Of course the hg command should be available in the terminal from any conda environments (anaconda prompt on Windows). The Mercurial packages cannot be installed in the base environment because Mercurial still works better in Python 2.7 (anyway, it wouldn't be clean).
Now Mercurial and the extensions we need can be installed on all platforms with something like:
conda create -n py27_mercurial -c conda-forge python=2.7 mercurial dulwich ipaddress
conda activate py27_mercurial
pip install hg-evolve hg-git
Working a bit with conda-forge and a conda meta-package, it won't be difficult to do that with one very simple command. Moreover, it should not be difficult to create conda packages for Meld and TortoiseHg.
From this stage, the hg command is available when the environment is activated (and it is very simple to install other Mercurial extensions). To make it available from other environment (and in the base environment), one need to append the path of the directory containing hg to the environment variable PATH or on Unix to create a symbolic link (I don't know Windows enough to know if something similar would work). Both solutions are not straightforward and the commands are not platform independent.
I didn't find a command to do something like this in conda but sometimes conda experts are able to do impressive things! What would be an elegant solution to this issue?
It would also be nice to create icons somewhere (in the Anaconda launcher?) for the graphical applications (Meld and TortoiseHg). Is it possible?
Edit: Conda applications
I discovered that there is a way to specify in the meta.yaml file that a package is an application: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#app-section
It may help to solve the issue.
Edit after a first answer based on a bash function:
Of course, I'm looking for a solution involving very small work (and understanding) for the users and with cross-platform commands.
Note that for Linux and Bash, one can just do:
CONDA_APP_DIR=$HOME/.local/bin/bin-conda-app/
mkdir -p $CONDA_APP_DIR
echo -e "\nexport PATH=\$PATH:$CONDA_APP_DIR\n" >> ~/.bashrc
ln -s $(which hg) $CONDA_APP_DIR/hg
No need to activate/deactivate the environment each time hg is used...
Of course, such solutions dependent of the system and the shell are not satisfactory. It should be possible to do such things with cross-platform conda-like commands (see https://github.com/conda/conda/issues/8556), something like
conda config --add channels conda-forge
conda install conda-app
conda-app install mercurial
Now, I just have to implement conda-app 🙂
One can always create a shell function/alias and shove it in their shell's runtime configuration file. For example, for your use case, I'd add the following in my ~/.bashrc:
hg() {
(conda activate py27_mercurial
command hg "$#"
_hg_exit_code=$?
conda deactivate
exit $_hg_exit_code)
}
Then, regardless of which environment you are in, you always run hg from the environment it was installed in. To make sure that this function is loaded for you shell in a new session, one can always take a look at the output for: type -a hg
I do this one-time-setup for all the tools (some are custom compiled) and have an alias/shell function for each. This way I can happily switch b/w environments without having to worry much.
The solution https://stackoverflow.com/a/55900964/1779806 is buggy for scripts using command hg ... and too inefficient for this case (installation of a command-line application). See https://github.com/conda/conda/issues/8556#issuecomment-488703716
I created a tiny Python package conda-app (https://pypi.org/project/conda-app/) to improve this situation.
This should now works on Unix systems (with Bash and Fish):
conda activate base
conda config --add channels conda-forge
pip install conda-app
conda-app install mercurial
It should not be difficult to improve conda-app to also support Windows.
For the time being, Windows users can install Mercurial and important extensions by installing TortoiseHG.
I'm trying to install a .deb file... for example:
example.deb.
But the program is already installed in an older version on the Debian minimal server.
So doing dpkg -i example.deb is creating a dialog, if i want to keep the configs...
is there any way to do this none interactive?
You can pipe yes into it:
yes | dpkg -i package.deb
man yes
You seem to be looking for
dpkg --force-confold -i package.deb
to specify that dpkg should prefer the existing, old configuration files in the case when there is a conflict.
More broadly, the proper solution depends on how desperate you are to avoid interactive prompts, and which prompts precisely you want to avoid.
dpkg has a number of options to select a particular behavior for various types of situations. Refer to its man page; scroll to the section on --force-things; one of them is --force-confold, or conversely --force-confnew to always replace any existing configuration file. (Many modern packages have a facility to upgrade any unchanged configurations completely automatically, but manually changed configuration files still require manual updating or merging.)
If you aren't running dpkg directly, apt and friends allow you to pass options to it with
apt install -o Dpkg::Options::="--force-confold" install package
(Yeah, that's a lot of colons. You probably want install -y to avoid interactive prompting by Apt itself, too.)
Setting the environment variable DEBIAN_FRONTEND to the string noninteractive will make Debconf (the configuration management component of Debian) select the default answer for all questions, and disable any prompting.
If the default answers to a package's configuration questions are not suitable, you can preseed Debconf's configuration database with the settings you want. You'll need to install debconf-utils which contains the utility debconf-set-selections. See further its man page and e.g. some sections of https://wiki.debian.org/DebianInstaller/Preseed (though this is rather focused en preseeding the installer, so you can potentially perform an unattended installation of all of Debian).
The problem with
yes | dpkg -i package.deb
is that you can't exactly predict which prompts are going to be shown, depending on the package's and the hosting system's configuration; you might say yes to something you didn't want to, or perhaps tell the system that your domain name or default database user is yes. Debconf was designed to give you very detailed and, for the most part, very safe and robust control over package installation - use that power.
I know that I can install Cuda with the following:
wget http://developer.download.nvidia.com/compute/cuda/7_0/Prod/local_installers/cuda_7.0.28_linux.run
chmod +x cuda_7.0.28_linux.run
./cuda_7.0.28_linux.run -extract=`pwd`/nvidia_installers
cd nvidia_installers
sudo ./NVIDIA-Linux-x86_64-346.46.run
sudo modprobe nvidia
sudo ./cuda-linux64-rel-7.0.28-19326674.run
Just wondering if I can install Cuda without root?
Thanks,
Update The installation UI for 10.1 changed. The following works:
Deselect driver installation (pressing ENTERon it)
Change options -> root install path to a non-sudo directory.
Press A on the line marked with a + to access advanced options. Deselect create symbolic link, and change the toolkit install path.
Now installation should work without root permissions
Thank you very much for the hints in the question! I just want to complete it with an approach that worked for me, also inspired in this gist and that hopefully helps in situations where a valid driver is installed, and installing a more recent CUDA on Linux without root permissions is still needed.
TL;DR: Here are the steps to install CUDA9+CUDNN7 on Debian, and installing a pre-compiled version of TensorFlow1.4 on Python2.7 to test that everything works. Everything without root privileges and via terminal. Should also work for other CUDA, CUDNN, TensorFlow and Python versions on other Linux systems too.
INSTALLATION
Go to NVIDIA's official release web for CUDA (as for Nov. 2017, CUDA9 is out): https://developer.nvidia.com/cuda-downloads.
Under your Linux distro, select the runfile (local)option. Note that the sudo indication present in the installation instructions is deceiving, since it is possible to run this installer without root permissions. On a server, one easy way is to copy the <LINK> of the Download button and, in any location of your home directory, run wget <LINK>. It will download the <INSTALLER> file.
Run chmod +x <INSTALLER> to make it executable, and execute it ./<INSTALLER>.
accept the EULA, say no to driver installation, and enter a <CUDA> location under your home directory to install the toolkit and a <CUDASAMPLES> for the samples.
Not asked here but recommended: Download a compatible CUDNN file from the official web (you need to sign in). In my case, I downloaded the cudnn-9.0-linux-x64-v7.tgz, compatible with CUDA9 into the <CUDNN> folder. Uncompress it: tar -xzvf ....
Optional: compile the samples. cd <CUDASAMPLES> && make. There are some very nice examples there and a very good starting point to write some CUDA scripts of yourself.
(If you did 5.): Copy the required files from <CUDNN> into <CUDA>, and grant reading permission to user (not sure if needed):
cp -P <CUDNN>/cuda/include/cudnn.h <CUDA>/include/
cp -P <CUDNN>/cuda/lib64/libcudnn* <CUDA>/lib64
chmod a+r <CUDA>/include/cudnn.h <CUDA>/lib64/libcudnn*
Add the library to your environment. This is typically done adding this following two lines to your ~/.bashrc file (in this example, the <CUDA> directory was ~/cuda9/:
export PATH=<CUDA>/bin:$PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<CUDA>/lib64/
FOR QUICK TESTING OR TENSORFLOW USERS
The quickest way to get a TensorFlow compatible with CUDA9 and CUDNN7 (and a very quick way to test this) is to download a precompiled wheel file and install it with pip install <WHEEL>. Most of the versions you need, can be found in mind's repo (thanks a lot guys). A minimal test that confirms that CUDNN is also working involves the use of tf.nn.conv2d:
import tensorflow as tf
x = tf.nn.conv2d(tf.ones([1,1,10,1]), tf.ones([1,5,1,1]), strides=[1, 1, 1, 1], padding='SAME')
with tf.Session() as sess:
sess.run(x) # this should output a tensor of shape (1,1,10,1) with [3,4,5,5,5,5,5,5,4,3]
In my case, the wheel I installed required Intel's MKL library, as explained here. Again, from terminal and without root users, this are the steps I followed to install the library and make TensorFlow find it (reference):
git clone https://github.com/01org/mkl-dnn.git
cd mkl-dnn/scripts && ./prepare_mkl.sh && cd ..
mkdir -p build && cd build
cmake -D CMAKE_INSTALL_PREFIX:PATH=<TARGET_DIR_IN_HOME> ..
make # this takes a while
make doc # do this optionally if you have doxygen
make test # also takes a while
make install # installs into <TARGET_DIR_IN_HOME>
add the following to your ~/.bashrc: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<TARGET_DIR_IN_HOME>/lib
Hope this helps!
Andres
You can install using conda with the following command.
conda install -c anaconda cudatoolkit
But you need to have prior accesss to the device(GPU).
EDIT : If you are finding error in anaconda repository then change the repository to conda-forge which is frequently updated.
conda install -c conda-forge cudatoolkit
You can install CUDA and compile programs, but you won't be able to run them for a lack of device access.
I downloaded the tar.gz from qemu.org. Now how can I compile the source code only for i386 architecture?
I mean, my qemu need not be able to emulate a Power PC, Motorola 68000 or others.
I tried the steps
./configure
make
make install
But there was a failure
No rule to build target 'all'
Apart from this, the above steps compile the qemu for all architectures too.
Hope to get some help.
On Linux Machine Download Qemu Source Code and extract in directory then cd to DIR and do following:
./configure --disable-kvm [--prefix=PFX] [--target-list="i386-softmmu x86_64-softmmu"]
make
make install
first tar it (extract it)
then go to the directory on shell
then
type this commands
./configure --target-list=i386-softmmu
when build successful
press make and enter
when this done
then write
sudo make install
that's it
For general linux,
#tar xvzf qemu-1.4.0.tar.bz2
#cd qemu-1.4.0
#./configure --target-list=i386-softmmu
#make
#make install
For puppy linux wary 530,
#tar xvzf qemu-1.4.0.tar.bz2
#cd qemu-1.4.0
#./configure --target-list=i386-softmmu
#make
#new2dir make install
#cd ..
#dir2pet qemu-1.4.0-i486
./configure --target-list=x86_64-linux-user --disable-smartcard-nss
This command work for me, while building Qemu 1.6 on centOS