[arch-general] almost got archlinux installed
kyle at gmx.ca
Tue Sep 11 22:08:39 EDT 2012
According to Jude DaShiell:
# When I boot the computer with the arch hard drive in it, the system
waits until I hit enter to start talking.
Syslinux does run a boot menu, similar to the grub boot menu. You can
turn this off by adjusting the timeout setting in
/boot/syslinux/syslinux.cfg and/or by commenting out both ui lines. A
text-based menu (menu.c32) is uncommented by default, and vesamenu.c32
should already be commented. Having said this, the system should still
come up talking if you haven't pressed enter, because the boot menu only
runs for I believe 5 seconds by default.
# Not a problem since it does talk but > only for a few seconds then
espeak turns off. If I log in very quickly, I
# get a root prompt. If I wait for a few seconds after that then espeak
goes off again. I did save the state of the sound card with alsactl
# before rebooting the system too.
This sounds like a sound problem or maybe a kernel problem that is
entirely unrelated to syslinux. If the system is booting and starts
talking, then syslinux is doing its job. Are you running a strictly
command line system, or have you tried installing GNOME? GNOME requires
PulseAudio, which appears to mute some cards. Also, you may be able to
login just before GDM is started, which makes no sound. Try typing your
login name and password as you normally do and then try to run orca, if
indeed you have installed GNOME. If this doesn't work, and
alt-control-f1 doesn't get you back to a talking prompt, you may be
interested in the hack I posted to automatically unmute the master
channel once PulseAudio is started. If none of this works, or if you are
running a command line system without PulseAudio or GNOME, it's possible
your kernel is crashing after you press a Speakup key. For now, it is
still recommended to use the linux-lts package until the necessary
Speakup patch makes it into the mainline kernel, which is I believe
scheduled for the 3.6 release.
# I followed instructions for syslinux and changed the lines in
syslinux.cfg to point at /sda1 rather than sda3 as is
# the default too which is why the system comes up as far as it now does.
Yes. The syslinux.cfg file has fairly sane defaults, but does need to be
slightly modified on most installations, since the root of the
filesystem on many systems is /dev/sda1 or /dev/sda2 rather than
/dev/sda3. Still, I would recommend labeling your filesystems, usually
with the -L <label> option to the appropriate mkfs, and then using
/dev/disk/by-label/<label> as the root parameter in your kernel append line.
# Does syslinux run some kind of splash screen or screen saver by default
# once it starts up? If so I may need to turn that off and then everything
# should be working correctly.
See my comment above regarding the boot menu and how to turn it off. It
is usually recommended, however, to simply decrease the timeout, as you
may end up needing to arrow down one time to Arch Linux Fallback after a
kernel upgrade, which you would no longer be able to do if you
completely turn off the menu. A timeout value between 10 and 20 is
likely good enough in your case.
# If what I read in syslinux.cfg is correct users of the beginner's
guide ought to be told to link or copy one of
# those files from /boot/lib/syslinux into the /boot/syslinux directory I
# didn't do that and that may be the cause for all of what is breaking now.
will do this automatically. All files are linked in /boot/syslinux and
/boot/syslinux/syslinux.cfg is created automatically with its default
configuration and comments.
# The syslinux-update command is mentioned twice and the first time it's
# mentioned in the section on syslinux, it's mentioned too early since the
# edits to /boot/syslinux/syslinux.cfg need to happen before the
# syslinux-update command gets run unless that syslinux-update command
# actually needs to be run twice for some reason.
I can't figure why it needs to be run twice, unless you want to cover
all bases after a package upgrade. However, the first run should always
happen before editing /boot/syslinux/syslinux.cfg, since it rarely has
to run later. Note that like grub, editing the syslinux configuration
does not require the boot code to be rewritten. This is different from
lilo, which required an update of the MBR boot code every time any
change was made to the config file. Hope this helps.
More information about the arch-general