[BRLTTY] "Can't access console"

[Mario Lang]

Dave Mielke <dave at mielke.cc> writes:

>>Actually, initramfs moves the /dev hierarchy over to the
>>new root directory, so the /dev directory is actually not different,
>>but I guess it could happen that brltty still lives in the old root.
>
> Yes, the current root directory is part of a process's data. Even a "cd /" 
> would still go to the initramfs roto. Perhaps we could add an option to specify 
> where teh root will move to (relative to the initramfs root) and brltty could 
> then keep checking for it until it shows up.

"Shows up" is going to be complicated, because it might as well take some
time until the chroot actually happens and the root fs is fully populated (e.g.,
I use a custom setup at work where the root fs is actually retrieved
with rsync, that can take some time). But yes, that sounds like a plan.

>>I just checked, tty<n> exists, but vcsa1 is the only device
>>that exists (because init has not yet started and there are no gettys yet).
>
> I don't think gettys create those. I think its udev that does.

Yes, but as a side-effect of gettys being started.

> By the way: Does the initramfs stay mounted to the final root file system?

No.  The process is roughly this:
 * initramfs gets called via /init by the kernel.
 * /proc gets mounted (I believe /sys as well, would have to check).
 * A series of scripts is executed to setup services like udev, load keymap,
   initialize lvm and cryptodisks and so on.
 * The real root filesystem is mounted to /root (${rootmnt}).
 * The /dev tree created/mounted by udev is moved over from /dev to /root/dev.
 * Some cleaning up of the ramfs files is done, I dont rememeber how exactly.
 * finally, a special binary does the pivot_root/chroot dance
   and finally executes init (the binary is started with exec, so that the
   initial initramfs process with PID 1 gets replaced by the
   new /sbin/init process from the real root filesystem).

I currently start brltty directly after udev, and before
all other service scripts that might lead to output or
even input (passphrase for crypto, or a failure to mount the real root fs
will actually launch a shell).

Could we perhaps use a special signal to implement this?
We could have some parameter to brltty that tells it what the path
of the new root fs is going to be, and if brltty receives this
signal, it will reopen all its filehandles based on the
new root?  We could then just send this signal in
the sysvinit script if we detect that brltty was started
by initramfs...

-- 
CYa,
  Mario