I am looking for a solution how to duplicate a Linux installation for multiple systems. The Linux installation is based on openSUSE 12.2. All systems use the absolute identical hardware.
The official solution would be to use AutoYaST (see http://doc.opensuse.org/projects/autoyast/). But since all systems use the same hardware I was thinking about taking an disk-image from an installation and "dd" to all new systems? What do you think, any best practices?
try using the parted or gparted applications. gparted is the GUI for parted.
http://www.gnu.org/software/parted/manual/html_chapter/parted_8.html
I am sure there are better ways to do this than dd. I tried that some ten years ago on identical machines and it did work, but was slow. I believe nowadays it makes more sense to be using tools like:
Partimage. I tried this a while ago and it was quite good.
Clonezilla. I've only heard it does the job, but have no observations of my own.
For more info, check this link.
dd will work, but is very slow because you'll have to copy over the whole disk, not just the data. I install hundreds of systems all the time and use SALI and System Imager. I use SALI to actually install the images and System Imager to manage variations of hardware and images. There's several ways to do it in SALI, but the standard method is via a pxeboot loader. But that's not required.
Related
I know the answer might be negative, but is there any way to run Gnss-Sdr on Windows Instead of Linux/Mac OS?
I Use it on Linux Already But I have just wondered if it can be done.
only related answers please.
It's possible. I'm just doing this. The problem is that some code fragments are written under Linux. The build system and library search methods are also under it. For the first time, I had to cut TCP data transfer and heavily correct some CMake files. I build it with the help MSYS2 under MinGW. The biggest problem is linking files. At this stage, I build most of the individual components. It was also required to manually build all the libraries. With my little experience in porting programs from system to system, it was hard
I would like to generalize a build system to compile on several (somewhat similar) platforms. What is a good method for determining the type of host that the shell script or Makefile is running on. I would like to distinguish between mac and linux, but also different specific distributions of linux (e.g. RHEL, Ubuntu). Cygwin is not important for me, but if you include it in your response I am sure others will find it valuable.
The rationale may include using the host type to fetch and install the correct versions of binary packages when it is more convenient to do so than compile from source. In addition, some commercial software is binary-packaged for specific distros, so part of the motivation is to grab the right binary.
Thanks,
SetJmp
Autotools to the rescue. It has tons of macros that help you do this kind of stuff.
http://www.lrde.epita.fr/~adl/autotools.html
uname -a to distinguish major *nix variants
Not so sure what the best way to distinguish red hat from ubuntu would be - could look for package managing tools and query installed packages, eventually helping you narrow down different debian derivatives, etc. There's probably something more obvious and up front though.
linux variants generally store distro information in /etc/issue.
most kernels will put info in /proc/version
It's not completely straightforward. You can use uname to find out the general parameters but to differentiate between distributions is a harder task. Maybe you should consider using something like autoconf to generalise your build system?
Just in case you're using Qt, there's this really nice set of defines, Q_OS_*, that guide you to the Operating System you're compiling on:
Q_OS_AIX
Q_OS_BSD4
Q_OS_BSDI
Q_OS_CYGWIN
Q_OS_DARWIN
Q_OS_DGUX
Q_OS_DYNIX
Q_OS_FREEBSD
Q_OS_HPUX
Q_OS_HURD
Q_OS_IRIX
Q_OS_LINUX
Q_OS_LYNX
Q_OS_MAC
Q_OS_MSDOS
Q_OS_NETBSD
Q_OS_OS2
Q_OS_OPENBSD
Q_OS_OS2EMX
Q_OS_OSF
...
They are defined in QtGlobal. There are even defines that help you figure out the compiler used Q_CC_* or the target Windowing System Q_WS_*.
But if you're not using Qt and want to go for a generic method, you most likely have to fall back to the Autotools package or CMake.
Determining Linux distributions is pretty tricky, but not hard. You first have to figure out what distributions you care about and then make all kinds of distribution specific file/configuration checks like in this example for the ones you've chosen, since you can't really support all of the myriad of Linux distros available out the. :-)
As for the Mac side i'll let the Mac experts answer, but it shouldn't be that hard, since at least the diversity issue is out of the question.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to play around with some embedded linux. I want it to be able to run on an x86 processor (for start, it will be running on my regular PC). I have looked online, but the ones I have found seem hard to setup or lack proper documentation. So what are some good embedded x86 compatible linux distros that are easy to setup or have good documentation on how to get things setup?
Since the definition of "embedded" vary depending on who you talk to, what is considered an embedded Linux distribution will also vary.
As other have said, you can go with distribution building tool kit, like :
T2 SDE
OpenEmbedded
LinuxFromScratch
Buildroot
You can also use any "standard" Linux distribution, which can often be customized for an embedded environment. They have the advantage of being heavily tested in their normal environment. So you can choose any of :
Fedora (with Revisor, Instalinux)
OpenSuse (with SuseStudio, Instalinux)
Debian (with Reconstructor, Instalinux)
Ubuntu (with Reconstructor, Instalinux)
Gentoo
Slackware (with NimbleX)
CentOS (with Instalinux)
gNewSense (with Builder)
Finally, you can also build your own completely, from source. In that case, BusyBox will probably be helpful since it provide a lot of functionalities and common application. To help you with that, there is the nice 3 parts series : Building Tiny Linux Systems with Busybox (part 1, part 2, and part 3)
You may want to take a look at the OpenEmbedded project. It is a meta-distribution, meaning it's more of a distribution construction kit rather than ready distribution. But using it may take effort on your part. The same applies to all embedded solutions, though.
BusyBox
BusyBox is designed to be a small executable for use with the Linux kernel, which makes it ideal for use with embedded devices. It provides a fairly complete environment for any small or embedded system.
What do you actually mean by "Embedded Linux"? It depends what you want to run on that.
For example you can use OpenWRT, but there are surely others which might better fit your purpose.
If you want to build some multimedia thing, Moblin might be a solution as well.
You might want to look at the Beagle Board.
It's not x86, but decent community of developers, and it will give a good idea how to build and run embedded Linux.(i.e. flash file system, somewhat limited RAM...) and its real cheap!
I can also recommend these two books:
Building Embedded Linux Systems and
Embedded Linux Primer
I'd start by having a look at the output of the buildroot tool which comes with busybox.
You are suggesting that you want to make your own Linux distribution, this is fine but you really need to know how to use an existing one first. I am assuming you understand fully how Linux boots and works on a basic level. You'll need
Some kind of boot media (in some cases this CAN be a rom, but usually isn't) that the firmware can boot from (in most cases the firmware on x86 is some kind of bios, or bios-like - except on things like Macs)
A boot loader - I like to use syslinux because it's easy (and boots from a dos filesystem)
A kernel
A root filesystem of some kind - you can use an initramfs for this in which case, it's loaded by the bootloader and expanded at boot time. Initramfs is cool, it avoids the need for a "real" root fs or block device drivers etc (at the expense of some ram, but ram is easy).
A C library (unless all your exes are static linked)
Some userspace software
I'd strongly recommend using an emulator (such as vmware) to test this, it reduces turnaround time a lot. A development system will need to have rather a lot of disc space, as you'll probably need to compile everything in the above list, and possibly some other tools as well (such as gcc and C library) which aren't small. Your build box will probably need to be running a proper Linux distribution.
I have done this and it's good fun, but frustrating at times (debugging can be a mission in itself)
Happy hacking :)
Busybox + LFS, Gentoo, Arch all do the job well
First to you'd compile your stuff in a chroot jail on dev computer, last you don't need to compile but you need to mirror/keep your own repository because you can't get old packages from official arch repositories.
I suggest debian
I want to be able to distribute a program in Linux without distributing the source with it. The current solution is distributing a tar.gz with a precompiled binary. What is the easiest way to have this binary be placed in the Applications Menu? Is there a way to do this that is common across most linux distributions, but Ubuntu, Fedora, and OpenSUSE would be the priority.
You will want to create a .deb and a .rpm. The former covers Ubuntu (Debian variants), and the latter Red Hat variants. You can also supply a standalone executable for other users who can deal with things like menus themselves.
You will have to deal with Gnome and KDE menu management, and also different distributions lay out their menus differently. There is also the issue of netbook variants such as Moblin, that have a netbook interface that probably has its own "add application" mechanism. I don't know if it is possible for a single .deb to handle both Gnome and KDE menus systems (for Ubuntu and Kubuntu respectively) but I imagine the capability is there to reduce duplication of effort for Ubuntu.
All recent distributions should have xdg-utils installed, which provides scripts such as
xdg-desktop-icon
xdg-desktop-menu
which seem to be what you're looking for.
Haven't looked into it lately...but back in the day (which really wasn't all that long ago) when I was using Linux, RPM was the easiest way to distribute pre-combiled binaries (most distributations had, and still have, some kind of support for RPM packages).
Here's an old how-to on building an RPM package:
Linux Online - RPM How-To
You could look at BitRock intaller.
Try Autopackage or other solutions posted in another question.
Do tar.gz and then give community rights to redistribute modified packages. They will make RPMs, DEBs and any other packages for their beloved distributions... which will probably fit their distros much better than you could ever make.
There is really too many differences between distributions to make one-size-fits-all package, often subtle ones. For example some distributions has "Application" section, other "Applications"... and this made menu items disappear on some distros. Libraries can be different, default settings can be different, and so on...
RPMs and DEBs aren't so portable as it is believed. With one package there might be problems even with different versions of a single distribution, and there is nothing worse than fighting to install badly prepared package correctly.
JeeBee is correct that you would want to go with .deb or .rpm.
For Ubuntu/Debian (the .deb) I would add that you do not send it to people but you create a "repository" and have the users add that url to their /etc/apt/sources.list, then you get a easy way to update the software as well.
That way you solve the distribution and updated problem at the same time.
And here is a example of how this could look like:
http://www.avrfreaks.net/wiki/index.php/Documentation:AVR32_General/Installing_tools_on_Ubuntu_Linux#Ubuntu_8.04_-_Hardy_Heron
And how a repository could look like:
http://www.atmel.no/avr32/ubuntu/
But don't repeat Atmels mistake and only do i386 because there is a lot of other common architectures out there right now, like the amd64.
/Johan
For RPM, this three-part tutorial by IBM is the best beginner's guide to packaging I know:
http://www.ibm.com/developerworks/library/l-rpm1/
http://www.ibm.com/developerworks/library/l-rpm2/
http://www.ibm.com/developerworks/library/l-rpm3.html
I'm looking for some software that allows me to control a server based application, that is, there are bunch of interdependent processes that I'd like to be able to start up, shut down and monitor in a controller manner.
I've come across programs like Autosys, but that's expensive and very much over the top for what I want. I've also seen AppCtl, but that seems not to handle dependencies. Maybe it would be possible to repurpose the init scripts?
Oh, and as an added complication it should be able to run on a Solaris 10 or Linux box without installing any new binaries. On the boxes I've seen recently, that means shell scripts and Perl but not Python.
Do any such programs exist or do I need to dust off my copy of Programming Perl?
Try Supervise, which is what qmail uses to keep track of it's services/startup applications:
http://cr.yp.to/daemontools/supervise.html
G'day,
Have a look in /etc/init.d for something similar and use that as a basis. See also crontab, or maybe at, to run on a regular basis.
cheers,
Rob
Solaris-only as far as I know, but wouldn't Solaris 10's SMF do what you want?
Try GNU Batch. It looks like it supports what you need.
http://www.gnu.org/software/gnubatch/