Shallow Thoughts : : install
Akkana's Musings on Open Source, Science, and Nature.
Sat, 27 Mar 2010
Three times now I've gotten myself into a situation where I was trying
to install Ubuntu and for some reason couldn't burn a CD. So I
thought hey, maybe I can make a bootable USB image on this handy
thumb drive here. And spent the next three hours unsuccessfully
trying to create one. And finally gave up, got in the car and went to buy
a new CD burner or find someone who could burn the ISO to a CD because
that's really the only way you can install or run Ubuntu.
There are tons of howtos on the web for creating live USB sticks for
Ubuntu. Almost all of them start with "First, download the CD image
and burn it to a CD. Now, boot off the CD and ..."
The few that don't discuss apps like usb-creator-gtk or unetbootin
tha work great if you're burning the current Ubuntu Live CD image
from a reasonably current Ubuntu machine, but which fail miserably
in every other case (wildly pathological cases like burning the
current Ubuntu alternate installer CD from the last long-term-support
version of Ubuntu. I mean, really, should that be so unusual?)
Tonight, I wanted a bootable USB of Fedora 12. I tried the Ubuntu
tools already mentioned, but usb-creator-gtk won't even try with
an image that isn't Ubuntu, and unetbootin wrote something but the
resulting stick didn't boot.
I asked on the Fedora IRC channel, where a helpful person
pointed me to this paragraph on
copying an ISO image with dd.
Holy mackerel! One command:
dd if=Fedora-12-i686-Live.iso of=/dev/sdf bs=8M
and in less than ten minutes it was ready. And it booted just fine!
Really, Ubuntu, you should take a look at Fedora now and then.
For machines that are new enough, USB boot is much faster and easier
than CD burning -- so give people an easy way to get a bootable USB
version of your operating system. Or they might give up and try
a distro that does make it easy.
Tags: linux, install, fedora, ubuntu
[
22:01 Mar 27, 2010
More linux/install |
permalink to this entry
]
Mon, 02 Nov 2009
The syntax to log in automatically (without gdm or kdm) has changed
yet again in Ubuntu Karmic Koala. It's similar to the
Hardy
autologin, but the file has moved:
under Karmic,
/etc/event.d is no longer used, as documented
in the
releasenotes
(though, confusingly, it isn't removed when you upgrade, so it may still
be there taking up space and looking like it's useful for something).
The new location is
/etc/init/tty1.conf.
So here are the updated instructions:
Create /usr/bin/loginscript if you haven't already,
containing something like this:
#! /bin/sh
/bin/login -f yourusername
Then edit /etc/init/tty1.conf and look for the
respawn line, and replace the line after it,
exec /sbin/getty -8 38400 tty1, with this:
exec /sbin/getty -n -l /usr/bin/loginscript 38400 tty1
As far as I know, it's safe to delete /etc/event.d since it's now unused.
I haven't verified that yet. Better rename it first, and see if anything
breaks.
Tags: linux, ubuntu, boot
[
19:46 Nov 02, 2009
More linux/install |
permalink to this entry
]
Sun, 23 Aug 2009
Noticing that every article I write ends up including a section on
"This doesn't work under Ubuntu; here's a link to the year-old bug
with a patch and several workarounds," I decided to try Fedora 11
and see if it was any better.
I downloaded and burned the latest netinst CD ISO and booted it
on the Atom machine. It greeted me with this prompt:
1.
2.
Select CD-ROM boot type:
I am not getting warm fuzzies about Fedora being the solution to
the Linux distro problem.
What do you think? Should I choose 1. or 2. ?
Tags: linux, install, fedora
[
20:09 Aug 23, 2009
More linux/install |
permalink to this entry
]
Sun, 07 Jun 2009
I upgraded to Ubuntu's current 9.04 release, "Jaunty Jackalope", quite a
while ago, but I haven't been able to use it because its X server
crashes or hangs regularly. (Fortunately I only upgraded a copy
of my working 8.10 "Intrepid" install, on a separate partition.)
The really puzzling thing, though, wasn't the crashes, but the fact
that X acceleration didn't work at all. Programs like tuxracer
(etracer) and Google earth would display at something like one frame
update every two seconds, and glxinfo | grep renderer said
OpenGL renderer string: Software Rasterizer
But that was all on my old desktop machine, with an
ATI Radeon 9000 card that I know no one cares about much.
I have a new machine now! An Intel dual Atom D945GCLF2D board
with 945 graphics. Finally, a graphics chip that's supported!
Now everything would work!
Well, not quite -- there were major teething pains, including
returning the first nonworking motherboard, but that's a
separate article. Eventually I got it running nicely with Intrepid.
DRI worked! Tuxracer worked! Even Google Earth worked! Unbelievable!
I copied the Jaunty install from my old machine to a partition on
the new machine. Booted into it and -- no DRI.
Just like on the Radeon.
Now, there's a huge pile of bugs in Ubuntu's bug system on problems
with video on Jaunty, all grouped by graphics card manufacturer even
though everybody seems to be
seeing pretty much the same problems on every chipset.
But hardly any of the bugs talk about not getting any DRI at all --
they're all about whether EXA acceleration works
better or worse than XAA and whether it's worth trying UXA.
I tried them all: EXA and UXA both gave me no DRI, while XAA
crashed/rebooted the machine every time. Clearly, there was something
about my install that was disabling DRI, regardless of
graphics card. But I poked and prodded and couldn't figure out what it was.
The breakthrough came when, purely by accident, I ran that same
glxinfo | grep renderer from a root shell. Guess what?
OpenGL renderer string: Mesa DRI Intel(R) 945G GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
As me (non-root), it still said "Software Rasterizer."
It was a simple permissions problem! But wait ... doesn't X run as root?
Well, it does, but the DRI part doesn't, as it turns out.
(This is actually a good thing, sort of, in the long term:
eventually the hope is to get X not to need root permissions either.)
Armed with the keyword "permissions" I went back to the web, and the
Troubleshooting
Intel Performance page on the Ubuntu wiki, and found the
solution right away.
(I'd looked at that page before but never got past the part right at
the beginning that says it's for problems involving EXA vs. UXA
vs. XAA, which mine clearly wasn't).
The Solution
In Jaunty, the user has to be in group video to use DRI in X.
But if you've upgraded from an Ubuntu version prior to Jaunty, where
this wasn't required, you're probably not in that group. The upgrader
(I used do-release-upgrade) doesn't check for this or warn you
that you have desktop users who aren't in the video group,
so you're on your own to find out about the problem.
Fixing it is easy, though:
edit /etc/group as root and add your user(s) to the group.
You might think this would have been an error worth reporting,
say, at X startup, or in glxinfo, or even in /var/log/Xorg.0.log.
You'd think wrong. Xorg.0.log blithely claims that DRI is enabled
and everything is fine, and there's no indication of an error
anywhere else.
I hope this article makes it easier for other people with this problem
to find the solution.
Tags: linux, ubuntu, x11, jaunty
[
19:23 Jun 07, 2009
More linux/install |
permalink to this entry
]
Wed, 13 May 2009
Someone asked on a mailing list whether to upgrade to a new OS release
when her current install was working so well. I thought I should write
up how I back up my old systems before attempting a risky upgrade
or new install.
On my disks, I make several relatively small partitions, maybe
15G or so (pause to laugh about what I would have thought ten or
even five years ago if someone told me I'd be referring to 15G
as "small"), one small shared /boot partition, a swap partition,
and use the rest of the disk for /home or other shared data.
Now you can install a new release, like 9.04, onto a new partition
without risking your existing install.
If you prefer upgrading rather than running the installer, you can
do that too. I needed a jaunty (9.04) install to test
whether a bug was fixed. But my intrepid (8.10) is working fine and
I know there are some issues with jaunty, so I didn't want to risk
the working install. So from Intrepid, I copied the whole root
partition over to one of my spare root partitions, sda5:
mkfs.ext3 /dev/sda5
mkdir /jaunty
mount /dev/sda5 /jaunty
cp -ax / /jaunty
(that last step takes quite a while: you're copying the whole system.)
Now there are a couple of things you have to do to make that /jaunty
partition work as a bootable install:
1. /dev on an ubuntu system isn't a real file system, but something
magically created by the kernel and udev. But to boot, you need some
basic stuff there. When you're up and running, that's stored in
/dev/.static, so you can copy it like this:
cp -ax /dev/.static/dev/ /jaunty/
Note: it used to work to copy it to /jaunty/dev/.
The exact semantics of copying directories in cp and rsync, and
where you need slashes, seem to vary with every release.
The important thing is that you want /jaunty/dev to end up
containing a lot of devices, not a directory called dev or
a directory called .static. So fiddle with it after the cp -ax
if you need to.
Note 2: Doesn't it just figure? A couple of days
after I posted this, I found out that the latest udev has removed
/dev/.static so this doesn't work at all any more. What you can do
instead is:
cd /jaunty/dev
/dev/MAKEDEV generic
Note 3: If you're running MAKEDEV from Fedora, it
will target /dev instead of the current directory, so you need
MAKEDEV -d /whatever/dev generic
.
However, caution: on Debian and Ubuntu -d deletes the
devices. Check man MAKEDEV first to be sure.
Ain't consistency wonderful?
2. /etc/fstab on the system you just created points to the wrong
root partition, so you have to fix that. As root, edit /etc/fstab
in your favorite editor (e.g. sudo vim /etc/fstab or whatever)
and find the line for the root filesystem -- the one where the
second entry on the line is /. It'll look something like this:
# /dev/sda1
UUID=f7djaac8-fd44-672b-3432-5afd759bc561 / ext3 relatime,errors=remount-ro 0 1
The easy fix is to change that to point to your new disk partition:
# jaunty is now on /dev/sda5
/dev/sda5 / ext3 relatime,errors=remount-ro 0 1
If you want to do it the "right", ubuntu-approved way, with UUIDs,
you can get the UUID of your disk this way:
ls -l /dev/disk/by-uuid/ | grep sda5
Take the UUID (that's the big long hex number with the dashes) and
put it after the UUID= in the original fstab line.
While you're editing /etc/fstab, be sure to look for any lines that
might mount /dev/sda5 as something other than root and delete them
or comment them out.
Now you should have a partition that you can boot into and upgrade.
Now you just need to tell grub about it. As root, edit
/boot/grub/menu.lst and find the line that's booting your current
kernel. If you haven't changed the file yourself, that's probably
right after a line that says:
## ## End Default Options ##
It will look something like this:
title Ubuntu 8.10, kernel 2.6.27-11-generic
uuid f7djaac8-fd44-672b-3432-5afd759bc561
kernel /vmlinuz-2.6.27-11-generic root=UUID=f7djaac8-fd44-672b-3432-5afd759bc561 ro
initrd /initrd.img-2.6.27-11-generic
Make a copy of this whole stanza, so you have two identical copies,
and edit one of them. (If you edit the first of them, the new OS
it will be the default when you boot; if you're not that confident,
edit the second copy.) Change the two UUIDs to point to your new disk
partition (the same UUID you just put into /etc/fstab) and change
the Title to say 9.04 or Jaunty or My Copy or whatever you want the
title to be (this is the title that shows up in the grub menu when
you first boot the machine).
Now you should be able to boot into your new partition.
Most things should basically work -- certainly enough to start
a do-release-upgrade without risking your original
install.
Tags: linux, ubuntu
[
09:44 May 13, 2009
More linux/install |
permalink to this entry
]
Sun, 05 Apr 2009
(after attempting to install Ubuntu onto it)
I'm not a Mac person, but Dave hit this a few days ago on a brand
shiny new Mac Mini and it was somewhat traumatic. Since none of the
pages we found were helpful, here's my contribution to the googosphere.
Ubuntu through Intrepid (supposedly this will be fixed in Jaunty;
we didn't test it) have a major bug in their installer which will
render Macs unable to boot -- even off a CD.
(I should mention that the problem isn't limited to Ubuntu --
I did see a few Fedora discussions while I was googling.)
What happens is that in the grub install stage, gparted writes the
partition table (even if you didn't repartition) to the disk in a format
that's incompatible with the Mac boot loader.
For the gory details, it's
Bug
222126: Partition Table is cleared during install on Intel Macs.
There's some discussion in a couple of Ubuntu forums threads:
8.04 won't boot
and
Intel Macs with Hardy 'no bootable devices'
and all of them point to an open source Mac app called
rEFIt (yes, it's supposed
to be capitalized like that). But Dave had already tried to install
rEFIt, he thought, unsuccessfully (it turned out it was installed but
wasn't showing its menu properly, perhaps due to an issue of his Apple
keyboard not properly passing keys through the USB KVM at boot time.
Ah, the Apple world!)
Anyway, none of the usual tricks like holding Alt or C during boot
were working, even when he took the KVM out of the loop. After much
despair and teeth gnashing, though, he finally hit on the solution:
Cmd-Option-P-R during boot to reset the Parameter RAM back
to factory defaults.
We still aren't clear how the Ubuntu installer managed to change the
Parameter RAM. But a couple of iterations of Cmd-Option-P-R cleared
up the Mini's boot problem and made it able to boot from CD again,
and even made rEFIt start showing its menu properly.
There's one more step: once you get the machine straightened out
enough to show the rEFIt menu, you have to right-arrow into rEFIt's
partition manager, hit return, and hit return when it asks whether to
synchronize the partitions. That will reformat the incorrect
gparted-format partition table so the Mac can use it.
(And with any luck, that is the last time that I will EVER have
to type rEFIt!)
(Though a better way, if you could go back and do it over again, is
to click the Advanced button on the last screen of the Ubuntu live
installer, or else use the alternate installer instead. Either way
gives you the option of writing grub to the root partition where
you installed Ubuntu, rather than to the MBR, leaving you much less
horked. You'll still need to rewrite the partitions with rEFIt (grumble,
I knew I wasn't quite through typing that!) but you might avoid the
Parameter RAM scare of not being able to boot at all.)
That's the story as I understand it. I hope this helps someone else
who hits this problem.
Tags: ubuntu, mac
[
22:49 Apr 05, 2009
More linux/install |
permalink to this entry
]
Wed, 11 Mar 2009
I finally got around to upgrading to the current Ubuntu, Intrepid
Ibex. I know Intrepid has been out for months and Jaunty is just
around the corner; but I was busy with the run-up to a couple of
important conferences when Intrepid came out, and couldn't risk
an upgrade. Better late than never, right?
The upgrade went smoothly, though with the usual amount of
babysitting, watching messages scroll by for a couple of hours
so that I could answer the questions that popped up
every five or ten minutes. Question: Why, after all these years
of software installs, hasn't anyone come up with a way to ask all
the questions at the beginning, or at the end, so the user can
go have dinner or watch a movie or sleep or do anything besides
sit there for hours watching messages scroll by?
XKbOptions: getting Ctrl/Capslock back
The upgrade finished, I rebooted, everything seemed to work ...
except my capslock key wasn't doing ctrl as it should. I checked
/etc/X11/xorg.conf, where that's set ... and found the whole
file commented out, preceded by the comment:
# commented out by update-manager, HAL is now used
Oh, great. And thanks for the tip on where to look to get my settings
back. HAL, that really narrows it down.
Google led me to a forum thread on
Intrepid
xorg.conf - input section. The official recommendation is to
run sudo dpkg-reconfigure console-setup ... but of
course it doesn't allow for options like ctrl/capslock.
(It does let you specify which key will act as the Compose key,
which is thoughtful.)
Fortunately, the release
notes give the crucial file name: /etc/default/console-setup.
The XKBOPTIONS= line in that file is what I needed.
It also had the useful XKBOPTIONS="compose:menu" option left over
from my dpkg-configure run. I hadn't known about that before; I'd
been using xmodmap to set my multi key. So my XKBOPTIONS now looks
like: "ctrl:nocaps,compose:menu".
Fixing the network after resume from suspend
Another problem I hit was suspending on my desktop machine.
It still suspended, but after resuming, there was no network.
The problem turned out to lie in
/etc/acpi/suspend.d/55-down-interfaces.sh.
It makes a list of interfaces which should be brought up and down like this:
IFDOWN_INTERFACES="`cat /etc/network/run/ifstate | sed 's/=.*//'`"
IFUP_INTERFACES="`cat /etc/network/run/ifstate`"
However, there is no file /etc/network/run/ifstate, so this always
fails and so
/etc/acpi/resume.d/62-ifup.sh fails to bring
up the network.
Google to the rescue again. The bad thing about Ubuntu is that they
change random stuff so things break from release to release. The good
thing about Ubuntu is a zillion other people run it too, so whatever
problem you find, someone has already written about. Turns
out ifstate is actually in /var/run/network/ifstate
now, so making that change in
/etc/acpi/suspend.d/55-down-interfaces.sh
fixes suspend/resume.
It's bug
295544, fixed in Jaunty and nominated for Intrepid (I just learned
about the "Nominate for release" button, which I'd completely missed
in the past -- very useful!) Should be interesting to see if the fix
gets pushed to Intrepid, since networking after resume is completely
broken without it.
Otherwise, it was a very clean upgrade -- and now I can build
the GIMP trunk again, which was really the point of the exercise.
Tags: ubuntu, linux, install, X11, net
[
17:28 Mar 11, 2009
More linux/install |
permalink to this entry
]
Sun, 01 Mar 2009
"Pinning" is the usual way Debian derivatives (like Ubuntu) deal
with pulling software from multiple releases. For instance, you
need an updated gtk or qt library in order to build some program,
but you don't want to pull in everything else from the newer release.
But most people, upon trying to actually set up pinning,
get lost in the elaborate documentation
and end up deciding maybe they don't really need it after all.
For years, I've been avoiding needing to learn pinning because of a wonderful
LinuxChix Techtalk posting from Hamster years ago on
easier
method of pinning releases
Basically, you add a line like:
APT::Default-Release "hardy";
to your
/etc/apt/apt.conf (creating it if it doesn't already exist).
Then when you need to pull something from the newer repository you
pull with
apt-get install -t hardy-backports packagename.
That's generally worked for me, until yesterday when I tried to pull
a -dev package and found out it was incompatible with the library
package I already had installed. It turned out that the lib package
came from hardy-security, which is considered a different archive
from hardy, so my Default-Release didn't apply to security updates
(or bugfixes, which come from hardy-updates).
You can apparently only have one Default-Release. Since Ubuntu
uses three different archives for hardy the only way to
handle it is pinning. Pinning is documented in the man page
apt_preferences(5) -- which is a perfect example of a well
intentioned geek-written Unix man page.
There's tons of information there -- someone went to
a lot of work, bless their heart, to document exactly what happens
and why, down to the algorithms used to decide priorities -- but
straightforward "type X to achieve effect Y" examples are lost in
the noise. If you want to figure out how to actually set this up
on your own system, expect to spend a long time going back and
forward and back and forward in the man page correlating bits from
different sections.
Ubuntu guru Mackenzie Morgan was nice enough to help me out, and with
her help I got the problem fixed pretty quickly. Here's the quick recipe:
First, remove the Default-Release thing from apt.conf.
Next, create /etc/apt/preferences and put this in it:
Package: *
Pin: release a=hardy-security
Pin-Priority: 950
Package: *
Pin: release a=hardy-updates
Pin-Priority: 940
Package: *
Pin: release a=hardy
Pin-Priority: 900
# Pin backports negative so it'll never try to auto-upgrade
Package: *
Pin: release a=hardy-backports
Pin-Priority: -1
Here's what it means:
a= means archive, though it's apparently not really needed.
The hardy-security archive has the highest priority, 950.
hardy-updates is right behind it with 940 (actually, setting these
equal might be smarter but I'm not sure it matters).
hardy, which apparently is just the software initially installed,
is lower priority so it won't override the other two.
Finally, hardy-backports has a negative priority so that apt will
never try to upgrade automatically from it; it'll only grab things
from there if I specify apt-get install -t hardy-backports.
You can put comments (with #) in /etc/apt/preferences
but not in apt.conf -- they're a syntax error there (so don't
bother trying to comment out that Default-Release line).
And while you're editing apt.conf, a useful thing to put there is:
APT::Install-Recommends "false";
APT::Install-Suggests "false";
which prevents apt from automatically installing recommended or
suggested packages. Aptitude will still install the recommends and
suggests; it's supposed to be configurable in aptitude as well, but
turning it off never worked for me, so mostly I just stick to apt-get.
Tags: debian, ubuntu, pinning
[
20:19 Mar 01, 2009
More linux/install |
permalink to this entry
]
![[feed]](http://shallowsky.com/images/logos/feed-icon-14x14.png){kind=icon}