debian-installer issues with no wireless network connection after a text based Jessie installation

2016-05-19 Thread Nick Gawronski
Hi, I am using the net installer of Jessie version 8.0.0 that includes 
the firmware as I am totally blind and found that the latest installer 
once it was installed I had no software speech after installing the 
system.  I was installing Debian Jessie on my laptop with just a text 
based system mainly for a rescue system for when X windows is down and 
for times when I don't wish to use X windows.  I found that during the 
installation I was able to connect to the internet and successfully 
install the system but once the system was rebooted I had no internet 
access over any network method.  What would it take for the debian 
installation to copy the network settings from the installer to the 
target system as it makes no sence why networking would be setup and 
working during a text based installation but not in the target system?  
What file should I edit to add my wireless network as well as my wired 
network using DHCP so they both will work when my text based system 
boots?  Nick Gawronski




Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

2016-05-19 Thread Felipe Sateler
On 18 May 2016 at 17:42, Anton Zinoviev  wrote:
> On Wed, May 18, 2016 at 01:33:06PM -0300, Felipe Sateler wrote:
>>
>> Ok. I see that the rules file appears to invoke the scripts in /etc
>> directly. Is this intended
>
> Yes.  The keyboard is configured by /lib/console-setup/keyboard-setup.sh
> and the font by the scripts in /etc.
>
> Notice that /lib/console-setup/console-setup.sh does not run the scripts
> in /etc at all.  If necessary it runs setupcon.

Oh, right.

>
>> (IOW, shouldn't they invoke the wrappers at /lib/console-setup)?
>
> Although setupcon is an universal and reliable tool, this cames at a
> price --- it is slow.  Many people have complained that console-setup
> slows down the boot and thats the only reason I decided to use scripts
> in /etc instead of setupcon.
>
> By the way, the only thing /lib/console-setup/console-setup.sh does in
> addition to the scripts in /etc is to rebuild the scripts in /etc if
> necessary.  And it is necessary to rebuild these scripts only if the
> sysadmin modifies the console configuration by hand and doesn't run
> `setupcon --save-only` afterwards.  In this case the wrapper will
> rebuild the scripts in /etc during the first reboot.

OK, this clarifies things. Thanks.

>
>> But upstream systemd and udev have pushed for mounting /usr in the
>> initramfs for a long time,
>
> Is there a place where one can learn about such things?

AFAIK, there is no document I can point at for this particular thing
(which is a shame though). There is a page making the case for the
merged /usr (ie, drop the distinction between / and /usr), and this
necessitates that /usr is mounted before executing init (because init
will live in /usr)[1]. Russ Allbery did a short summary during a
recent thread discussing the same /usr merge in debian[2]

[1] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[2] http://article.gmane.org/gmane.linux.debian.devel.general/206431


>
>> Note that because it has no WantedBy line, this service will not be
>> actually executed during boot. If the service should run as part of
>> normal system boot, it should have either WantedBy=sysinit.target or
>> WantedBy=multi-user.target.
>> Services WantedBy=sysinit.target will be pulled in both single user
>> and multi user boots. Services in multi-user.target will only be
>> pulled in multi user boots.
>
> OK, then it has to be WantedBy=multi-user.target.  Rebuilding the
> scripts in /etc is not something we want in single user mode.

Right, writing to /etc is probably not something that should be done there.

-- 

Saludos,
Felipe Sateler