Linux General Questions

It's really weird how backward that is. For, god, it's been almost 20 years, Linux font rendering was always so much worse than Windows'.

Windows warps fonts to fit pixels on the screen, so they're very readable on a low-DPI display (which is what we've had, for the last twenty years). So it's really easy to read the screen, but if you print out a page, and then hold it up next to the screen, you can see that the letters are deformed. The Mac preserves the overall shapes of the fonts, so if you print something out, it will look almost exactly the same as what's on screen. But the onscreen fonts are a little blurry, because of this.

Whatever they're doing now in Linux is different again. It doesn't seem deformed, but I don't do much printing, so I don't know for sure. But, from a very nonexpert point of view (I know very little about fonts in general), it seems like it's combining the Windows readability with the Mac shape preservation. I didn't think that would be possible, but that's what it looks like to this total font amateur.

Select 310 video drivers and now I only get the desktop. How do I revert?

Right-click on the desktop and go to Change Background. Then you can "back" out of that to get to general system settings. You can also CTRL-ALT-F1 to open a shell and use apt to rollback. Or you can reboot into recovery mode.

Here is a question that might not be a general question.

At work we have a product that is a custom linux kernel and install and our method to update leaves something to be desired. So my question is, what are some common methods of updating Linux? As far as my limited knowledge knows, there are a variety of ways of doing this.

Send everything that is updated via a zip and reflash it all.
Leverage some package manager to use something like a repository.
KSplice
Puppet
?

Suggestions?

LiquidMantis wrote:

Right-click on the desktop and go to Change Background. Then you can "back" out of that to get to general system settings. You can also CTRL-ALT-F1 to open a shell and use apt to rollback. Or you can reboot into recovery mode.

Thanks! Worked, as I am posting using Ubuntu again

So my question is, what are some common methods of updating Linux?

On Debian, if I need custom kernel settings, the kernel source code package has everything needed to generate new .deb package files, which is what the packaging system uses. It's been awhile since I've done it -- with regular source packages, you use the 'debuild' command to make .debs, but I don't remember whether that works with the kernel. On Debian, that generates two or three packages; one is the kernel proper, and then there's a headers .deb, and something else. Whether or not you need the additional packages depends on your installation.

Once they're ready, installing is just a matter of copying them to the target machine, and then running "dpkg -i kernelpackage*.deb". If you have correctly incremented your build version, the update scripts should fix GRUB to boot the most recent kernel automatically. Once I know it's working well, I can then remove old versions with dpkg --purge oldlinuxkernelname. (plus, possibly, -headers, and something else that I can't quite think of at the moment.)

If you're on an RPM-based distro, like RedHat, there will almost certainly be an easy to do this, but I don't know what it is, offhand. There will some kind of utility to generate kernel RPMs, and then you can use the standard RPM package management from there.

If you're on a custom distro, or one that doesn't use a package manager, then I think tar/gzip, and manual editing of your boot configuration, is the only real option.

Package managers are good things. Always use them if you can.

Malor wrote:
So my question is, what are some common methods of updating Linux?

If you're on an RPM-based distro, like RedHat, there will almost certainly be an easy to do this, but I don't know what it is, offhand. There will some kind of utility to generate kernel RPMs, and then you can use the standard RPM package management from there.

Depending on the number of systems in this situation, and if RPM based, you could set up a Spacewalk server (essentially Redhat Satellite Server, but the upstream version) which acts as your repo manager and update supplier, you could then create a custom repo for your built kernels and subscribe the required systems to that custom channel to receive them.

This may be too much if we're only talking a few systems, though.

The amount of systems is in the 5 figures and likely to grow in the coming years.

Wow, that's certainly more than a few...

What flavour of linux are we talking here? That may dictate which direction your best solution lies..

It's all custom (it's an embedded system).

Ah, in that case I'm not sure of any 'appliance' or application that would fill your needs, without spending a lot of money on something you don't use 90% of the functionality. As far as I know, ksplice is really just for 'hot-patching' a running kernel, avoiding the need to reboot a system into a new kernel. Sadly, Oracle (no offence to anyone associated) bought Ksplice, so I won't be seeing in in RH any time soon.

Anyway, the matter in hand. How is your scripting? Not all that long ago, I crafted a rather simple system just by using a cronjob, some scripts, and the timestamp of a file available over NFS. Essentially, the process went something like:

1. Each night every system would run a cronjob that kicked off a simple script.
2. The script only checked the timestamp of an empty file on a central server (over NFS).
3. If the timestamp was less than 24 hours ago, then it ran script A. Script A in my case, was also hosted on the same NFS server

My script was a custom yum update to roll out specific rpms (before my company had the money for Satellite). The script itself could be anything though - just copying/installing a custom kernel package, or even just individual files - almost akin to the "Send everything that is updated via a zip" you mentioned earlier, but at least there is some level of automation. Obviously bash scripting is pretty much just a collection of commands that you could run by hand anyway, but including variables can make it very versatile. For example, you could have the script always copy/extract the file latest, which in itself is a symlink to custom_kernel_and_files.tar.gz. All you need to change when rolling out a new version would be the symlink.

If I wanted to roll out updates that night, then just touch the empty file to update the timestamp and at the specified time, all the systems would get whatever it is they were programmed to do.

The biggest issue with the numbers you are talking here is doing 'whatever' to all the nodes to initially set up the mechanism, that could be time consuming in itself. In my case, once all systems (around 600 systems, not all requiring the same thing) had the cronjob in place, I could even use the mechanism to update the cronjob line itself, or the 'kick off' script that checked the timestamp.

Hopefully at least some of that makes sense. I have next to no experience with embedded systems, or even custom kernels, so I may be way off. I realise that the type of systems you are dealing with are probably not permanent features, but I guess without working there and seeing the environment/knowing the set up... I'm just throwing it out there..

What distro should I be playing around with to give myself a solid (re: in depth tech support level knowledge) base in *nix?

krev82 wrote:

What distro should I be playing around with to give myself a solid (re: in depth tech support level knowledge) base in *nix?

For learning Unix, I'd again advocate FreeBSD over any version of Linux I've dealt with. It has the advantage of being one coherent unit managed by one organization, where a lot of effort has been put into documentation.

The FreeBSD Handbook will take you a very long way.

From there, http://www.freebsddiary.org/ is a very useful collection of how-to's.

Any article written by Dru Lavigne is pretty useful, there are a bunch at O'Reilley: http://onlamp.com/pub/ct/15

That's not a bad recommendation, actually. If you want to really understand it, as opposed to just USE it, Unix is best learned bottom-up, the way it was written, rather than top-down. FreeBSD, being simpler and all coming from the same dev team, tends to be 'purer' Unix, if there is such a thing; there simply isn't as much to it. Other Unices (Linux in particular) have layered a lot of stuff on top, and gone off in some different directions with their system utilities.

Firing up FreeBSD is kind of like firing up Linux from 8 or 10 years ago. It doesn't have many of the desktop-style GUI tools that have been layered in, but if you actually want to understand what's going on, that's a benefit, not a drawback.

But if you actually want to USE it, as a desktop, Linux tends to be much better; all the added code makes it much friendlier, but also much harder to truly understand. A lot of the underlying reality of the computer is abstracted away, and if you're trying to get good enough with the system to be tech-support capable, learning what's really going on is important. Then you can learn the abstractions, and when the abstractions fail (as they always do), then you'll know what to do to fix things.

I'm totally not trying to pimp, but Slackware borrows a lot of conventions from BSD. I don't know the full degree, but mention it as it might be a kind of hybrid option.

Wish I had some room for playing with VMs.

Malor wrote:

That's not a bad recommendation, actually. If you want to really understand it, as opposed to just USE it, Unix is best learned bottom-up, the way it was written, rather than top-down. FreeBSD, being simpler and all coming from the same dev team, tends to be 'purer' Unix, if there is such a thing; there simply isn't as much to it. Other Unices (Linux in particular) have layered a lot of stuff on top, and gone off in some different directions with their system utilities.

Firing up FreeBSD is kind of like firing up Linux from 8 or 10 years ago. It doesn't have many of the desktop-style GUI tools that have been layered in, but if you actually want to understand what's going on, that's a benefit, not a drawback.

But if you actually want to USE it, as a desktop, Linux tends to be much better; all the added code makes it much friendlier, but also much harder to truly understand. A lot of the underlying reality of the computer is abstracted away, and if you're trying to get good enough with the system to be tech-support capable, learning what's really going on is important. Then you can learn the abstractions, and when the abstractions fail (as they always do), then you'll know what to do to fix things.

It can have any of those deskktop GUI tools; most of them exists in ports somewhere. When they don't, most things written to run on Linux can be run on FreeBSD. I'm writing this from my rather shiny gnome desktop. It is true that I had to install it, and it look a little longer than necessary because I prefer to install from ports instead of using binary packages, but that just meant I had to type "make install" and wait a bit.

There is always PC-FreeBSD, which tries to be more of a desktop out of the box, so you can avoid having to type make install. I haven't tried it yet, but it might be easier to get the shiny stuff that way.

Yeah, I almost mentioned that you can layer in many of the same GUI tools, but I'm also thinking of programs like the Ubuntu network manager applet, which feels fairly Linux- and Ubuntu-specific to me. It may have been ported, but I guess the real point I'm trying to make is that if you install Ubuntu, you'll have that utility, and will probably need to interact with it, which will prevent you from learning about /etc/network/interfaces, doing it the old manual way. The fact that it doesn't come with the base FreeBSD distro (whether or not you can load it from Ports) is really a net benefit, not a drawback, if you're trying to truly understand what's going on.

In general, while Ports is pretty slick, it's much inferior to the better Linux package managers. At least when I was last working with it, Ports was wonderful for getting programs going on a semi-alien system, but it was rotten at maintaining them afterward. You had to manually update your ports tree, regenerate new binaries from the patched sources, and then manually install them. This was semi-automated, but it takes so much more attention, and so much longer to recompile everything, than the binary Linux package managers. (rpm and dpkg, mainly.)

Once you get to the point of really depending on Ports, it may be time to switch over to a text-based Linux, like Debian, as the next step in your learning curve. Seeing how the two different systems approached so many problems from different directions will really stretch your mind, sometimes. And, after that, building a Linux From Scratch project will teach you the absolute nuts and bolts of how everything is built... you don't usually want to start there, because you won't yet have developed any skills to dig yourself out of the many holes you can create in a LFS install. But it's a great way to get down to the absolute brass tacks, just barely above the hardware, and start learning the abstractions that keep layering on up to the desktop.

As a slightly separate thought, it's also important to remember that FreeBSD is just, you know, FreeBSD. The kernel and the major system utilities all come from the same team. Everything gets maintained together. Linux proper is just the kernel, and then you've got several different possibilities for userspace; the GNU system utilities are the most commonly used (and typically are much more featureful than the BSD variants), but you also have BusyBox and Android as two possible alternatives. And Debian has a kFreeBSD port, which marries much of the Debian userland (mostly GNU-based) with the FreeBSD kernel, which tends to be quite a bit more secure than Linux. Unfortunately, a lot of the Debian system utilities are fairly Linux-dependent, so getting a kFreeBSD system running can be pretty painful. It's definitely not a first-class Debian yet.

So, basically, FreeBSD tends to be fairly uniform and of high quality, but much less featureful, and supporting much less hardware. The various Linux systems are extremely chaotic in comparison, and often quite poor for security, but offer shedloads of features, and usually run very quickly. The Linux kernel may have tons of security issues (how many, we don't really know, because the kernel devs actively try to hide them), but it does run fast.

Malor wrote:

Yeah, I almost mentioned that you can layer in many of the same GUI tools, but I'm also thinking of programs like the Ubuntu network manager applet, which feels fairly Linux- and Ubuntu-specific to me. It may have been ported, but I guess the real point I'm trying to make is that if you install Ubuntu, you'll have that utility, and will probably need to interact with it, which will prevent you from learning about /etc/network/interfaces, doing it the old manual way. The fact that it doesn't come with the base FreeBSD distro (whether or not you can load it from Ports) is really a net benefit, not a drawback, if you're trying to truly understand what's going on.

Fair point. I believe my installation of gnome on FreeBSD came with such a tool, but most such tools used to be so broken that I gave up using them. Hopefully these days that is no longer the case ... but they are still going to be too slow for anyone that understand how to use the tools they are a front-end to.

Malor wrote:

In general, while Ports is pretty slick, it's much inferior to the better Linux package managers. At least when I was last working with it, Ports was wonderful for getting programs going on a semi-alien system, but it was rotten at maintaining them afterward. You had to manually update your ports tree, regenerate new binaries from the patched sources, and then manually install them. This was semi-automated, but it takes so much more attention, and so much longer to recompile everything, than the binary Linux package managers. (rpm and dpkg, mainly.)

The time issue is definitely true if you insist on using the ports tree to install from source like I tend to do. There are however also pre-compiled binaries available that work more like the Linux package managers. I've found the system far less prone to breakage than linux package managers, but that could be a matter of luck.

Malor wrote:

So, basically, FreeBSD tends to be fairly uniform and of high quality, but much less featureful, and supporting much less hardware. The various Linux systems are extremely chaotic in comparison, and often quite poor for security, but offer shedloads of features, and usually run very quickly. The Linux kernel may have tons of security issues (how many, we don't really know, because the kernel devs actively try to hide them), but it does run fast.

I'm confused by the claim of 'more features' in Linux. I don't know of any examples of software available on Linux that won't run on FreeBSD, either natively or with the Linux compatibility layer. More hardware is probably true, but mostly limited to specialty things, like phones and embedded systems.

EDIT: I should mention that my enjoyment of FreeBSD on the desktop is a fairly recent development. I used to be a strict linux user, simply because I always ran into some annoying issue when building a FreeBSD desktop. There has been quite a bit of focus in that direction though in recent times.

I was going to install Arch on my new workstation but apparently there is an issue with it booting up on a EUFI machine.

There may be an option in your system BIOS to change to "BIOS boot manager" or some such. I have to do this with all 12G Dell servers before it will install/boot properly. I presume if your system supports UEFI, then it will also have the option to change to BIOS boot manager.

I have a question, but I am not sure if I am even asking the correct one.

I have a file that is filename.tar.md5. It is not simply a signature file, it seems to be a tar archive with maybe a wrapper around it. When I try and untar it, I get the following output:

$ tar -tf recovery-p7510.tar.md5
recovery.img
tar: Truncated input file (need to skip 2560 bytes)
tar: Error exit delayed from previous errors.

The recovery.img file does seem to be extracted, but when I try and use it later I get an error in the other application. So I am not sure if the tar is extracting that file correctly before it errors out. If not, am I supposed to strip of an appended md5 signature or something?

Hmm. I've not dealt directly with tar.md5 before, but from a quick search it appears to be most commonly used for Android ROMs and firmware.

Anyway, I downloaded a recovery.tar.md5 from dropbox, just to have something to test with.

Just performing tar -xvf recovery.tar.md5 seemed to extract recovery.img without any errors. Perhaps it's just your extraction flags that are incorrect?

EDIT: If you like, and it's not personal information, you can send the file to me and i'll see if I can get into it, providing the above doesn't change matters..

omnipherous wrote:

Hmm. I've not dealt directly with tar.md5 before, but from a quick search it appears to be most commonly used for Android ROMs and firmware.

Anyway, I downloaded a recovery.tar.md5 from dropbox, just to have something to test with.

Just performing tar -xvf recovery.tar.md5 seemed to extract recovery.img without any errors. Perhaps it's just your extraction flags that are incorrect?

EDIT: If you like, and it's not personal information, you can send the file to me and i'll see if I can get into it, providing the above doesn't change matters..

Yes, that is exactly what it is for. The file is supposedly an image for ClockworkMod, a bootloader to be flashed on a device.
Link: http://cmw.cmfs.me/p4/recovery/recov... . I haven't tried extracting with the verbose flag, I try that when I get home as our work firewall blocks that domain and I don't have the file with me.

I highly recommend just getting ROM Manager.

I get the same error as you do with that file - maybe it's the file that's dodgy? I've not much experience with ROMs etc, but the ROM manager mentioned might take out the manual step for you and it will all 'just work'

[[email protected] recoverytartest] tar -xvf recovery-p7510.tar.md5
recovery.img
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

LiquidMantis wrote:

I highly recommend just getting ROM Manager.

Totally. Although I don't remember downloading any roms that ended in .md5....

I looked it up, and apparently .tar.md5 files are regular tar files, with an md5 checksum slapped on the end. Tar skips everything after a double blank entry, so you can glue anything you like onto a tar file, and it will be ignored.

The error you're getting is at the beginning, which indicates that you ended up with a corrupt file. In this case, the .md5 part is irrelevant... you've got a bum download.

It was more normal, historically, to distribute the .tar and the .md5 files separately... this gluing idea is new, and a bit weird. The standard md5sum won't, I think, deal with these files properly, so it strikes me as a purely stupid idea. Just distribute two files, fer chrissake.

Malor wrote:

I looked it up, and apparently .tar.md5 files are regular tar files, with an md5 checksum slapped on the end. Tar skips everything after a double blank entry, so you can glue anything you like onto a tar file, and it will be ignored.

The error you're getting is at the beginning, which indicates that you ended up with a corrupt file. In this case, the .md5 part is irrelevant... you've got a bum download.

It was more normal, historically, to distribute the .tar and the .md5 files separately... this gluing idea is new, and a bit weird. The standard md5sum won't, I think, deal with these files properly, so it strikes me as a purely stupid idea. Just distribute two files, fer chrissake.

Using the file you downloaded to verify the same file makes no sense to me. Actually I guess it's probably impossible for the file and the md5 to both be corrupt in a way that still lines up.

I agree, it seems stupid. The actual key file at the site in the same directory is then named recovery-p7510.tar.md5.md5 . I imagine I'll just need to go a different route, like LiquidMantis' suggestion of ROM Manager. Thanks.

Update: Xubuntu was a pretty hot jam until I tried Lubuntu. Lower overhead and battery usage, beautiful interface... I think I'll be using this buntu.