[BRLTTY] "Can't access console"

Mario Lang mlang at delysid.org
Tue Nov 13 09:30:30 EST 2007


Dave Mielke <dave at mielke.cc> writes:

>>"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.
>
> But brltty is now able to wait for resources. It doesn't need them all to be 
> available right up front. If enough devices are in the initramfs then it can 
> get going well enough, and still change to the real root file system later for 
> even better functionality. Does the initramfs remain mounted to the real root 
> file system?

No, the ramfs does not stay mounted, its gone after the real /sbin/init
starts.

>>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...
>
> Do you have a particular signal in mind?

Not really, samuel suggests to use SIGHUP.

> Is there any convnetional signal for something like that?

I dont know of any rules here.  I would have used one that
is normally not in use (like USR1...)

-- 
CYa,
  Mario | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang at db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>


More information about the BRLTTY mailing list