Error attempting to run alsamixer

Circuits · January 22, 2019, 11:25am

I am working on an embbeded system. On the system in /usr/bin there are a host of programs one of which is called alsamixer. I want to use this utility but whenever I try to run any alsamixer commands I get and error message:

Error opening terminal: vt100

Anyone ever seen this error before or know how to deal with it?

joeyg · January 22, 2019, 2:21pm

You probably want to see/verify your current terminal configuration.
echo $TERM
will display this

Now, I am not sure whether that error message is telling you that you ARE using VT100, or that you want VT100.
So, if not returning VT100 from above command, you may want to set to VT100.
If you are already VT100, more research needed to learn what terminal mode is expected.

Circuits · January 22, 2019, 4:14pm

Interesting echo $TERM shows that I am currently on vt100. I quick Google search doesn't yield any results as to the proper terminal mode but I will keep digging.

wisecracker · January 22, 2019, 5:03pm

Check that you have 'ncurses' installed.
'alsamixer' uses it to work.

Circuits · January 22, 2019, 5:20pm

Well I don't see any executable's for ncurses. Although, I do have an ncurses directory @ buildroot-2011.02/package/ncurses; however, there is only two files inside of it: Config.in and ncruses.mk. Has this directory been gutted or does that sound correct?

wisecracker · January 22, 2019, 5:59pm

AFAIK, it is a library and has no executable.
As I use OSX 10.14.x then I can't tell you where it lies but it seems, and I am guessing here, that the library is not being seen by your embedded system or it has the wrong filename for the alsamixer version you are using.
You could more <each_filename> and see what you can find from either of those two files and try man ncurses too.

Corona688 · January 23, 2019, 1:53pm

Embedded Linux systems sometimes don't end up with usable terminals on boot. How to fix this would be up to your distribution usually. What is it?

Circuits · January 23, 2019, 2:36pm

Ubuntu 16.04 is the distribution of my PC. Are you wondering what the version of the kernel on the embedded device is? The kernel version on the device is: 2.6.35.14

Corona688 · January 24, 2019, 10:24am

I am wondering not just the kernel of the embedded device, but what software is running on it!

Circuits · January 24, 2019, 10:34am

U-Boot 2009.08 - dub-1.5.2.1 - GCC 4.4.6 - DigiOpenGL - crosstool-ng-1.20.0

Corona688 · January 25, 2019, 4:23pm

So, no init system or anything? Your terminal probably hasn't been set up. This is a surprisingly tricky bit of "magic" done with a special syscall which we're for the most part happy to let some linux distribution do for us.

One workaround for it, funny enough, could be ssh-ing into your device. A virtual terminal should be close enough.

I was sure that busybox had a utility for it, and their faq turns out to have that and a better explanation what it does:

"Why do I keep getting "sh: can't access tty; job control turned off" errors? Why doesn't Control-C work within my shell?"

Job control will be turned off since your shell can not obtain a controlling terminal. This typically happens when you run your shell on /dev/console. The kernel will not provide a controlling terminal on the /dev/console device. You should run your shell on a normal tty such as tty1 or ttyS0 and everything will work.

Example: you booted into your machine with init=/bin/sh and got "sh: can't access tty" error because sh has its stdio opened to /dev/console. You want to reopen stdio to, say, /dev/tty1 and thus acquire a controlling tty.
   # Let's try this:
   exec </dev/tty1 >/dev/tty1 2>&1
   # No, doesn't work: even if opening /dev/tty1 gave sh the ctty,
   # sh wouldn't know it - it checks for ctty just once at startup.

   # Let's try re-execing sh:
   exec </dev/tty1 >/dev/tty1 2>&1
   exec sh
   # Got "sh: can't access tty" again. Why?
   # The reason is somewhat obscure: kernel starts process with PID=1
   # (in this case, shell) with SID=0 and PGID=0, not with SID=1 and PGID=1
   # as you'd expect. IOW: our sh is not a session leader, and therefore
   # cannot acquire ctty by opening /dev/tty1 (or any other tty).

   # Let's try making us a session leader:
   exec setsid sh
   exec </dev/tty1 >/dev/tty1 2>&1
   exec sh
   # Yes, this worked!

   # This can be combined into one command,
   # but need to be careful and perform these operations
   # in the correct order:
   # 1. make ourself session leader,
   # 2. open /dev/tty1 and thus acquire a ctty,
   # 3. re-execute the shell, allowing it to notice that it has a ctty:
   exec setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1'