[arch-general] almost got archlinux installed

Kyle 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.

syslinux-install_update -iam

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.
~Kyle


More information about the arch-general mailing list