Flidas fails to proceed beyond a black screen with blinking cursor

2 respuestas [Último envío]
amenex
Desconectado/a
se unió: 01/03/2015

The installation was working before the SATA drive caddy in which Trisquel_8 is located
was swapped between a pair of Thinkpad T420's, the former with more RAM (7.7 vs. 3.7 GB)
and more screen resolution (1600x900 vs. 1368x768 pixels) in their respective DVD drive bays.
The present T420 is otherwise identical; and the former T20's own Flidas installation still
works OK with the present T420's DVD drive caddy and its SATA HDD.

Grub rescue enabled me to get the Etiona installation working on the present T420, and the
best I can do with the present Flidas installation with recovery mode is to recognize
a couple of errors that appear during startup:
(1) "failed to start create static device nodes in /dev" which appears three times ...
(2) File "/usr/lib/python3.5/configparser.py", line 778, in get d = self.unify.values (section,vars)
File "/usr/lib/python3.5/configparser.py", line 1138, in _unify_values
raise No SectionError (section)
configparser, No SectionError: No Section: "Files"

The first error is sometimes associated with incorrect ownership of the partition (/dev/sda5)
in which Flidas is installed, e.g., see: https://askubuntu.com/questions/1301750/ubuntu-16-04-failed-to-start-create-static-device-nodes-in-dev where it's said:
sudo stat -c "%U %G" /
In my case, this command elicits the correct response, root root

Regarding the second series of errors: I mounted /dev/sda5 in a Live instance of Etiona's media
folder and looked up "/usr/lib/python3.5/configparser.py", line 778, where it's said:
The section DEFAULT is special.
"""
try:
d = self._unify_values(section, vars)
except NoSectionError:
if fallback is _UNSET:
raise
else:
return fallback
option = self.optionxform(option)
try:
value = d[option]
except KeyError:
if fallback is _UNSET:
raise NoOptionError(option, section)
else:
return fallback

if raw or value is None:
return value
else:
return self._interpolation.before_get(self, section, option, value,

Similarly, "/usr/lib/python3.5/configparser.py", line 1138, where it's said:
def _unify_values(self, section, vars):
"""Create a sequence of lookups with 'vars' taking priority over
the 'section' which takes priority over the DEFAULTSECT.

"""
sectiondict = {}
try:
sectiondict = self._sections[section]
except KeyError:
if section != self.default_section:
raise NoSectionError(section)
# Update with the entry specific variables
vardict = {}
if vars:
for key, value in vars.items():
if value is not None:
value = str(value)
vardict[self.optionxform(key)] = value
return _ChainMap(vardict, sectiondict, self._defaults)

Suggestions for further action to bring Flidas back to life are welcome.

Magic Banana

I am a member!

I am a translator!

Desconectado/a
se unió: 07/24/2010

Trisquel 8 is not supported anymore: only use Trisquel 9.

amenex
Desconectado/a
se unió: 01/03/2015

Magic Banana reminded me:Trisquel 8 is not supported anymore: only use Trisquel 9.

Alas, Trisquel 9's not working very well. See this link:
https://trisquel.info/en/forum/trisquel9-etiona-experiences-random-freeze-which-there-no-recovery

Trying to complete a run of the same six scripts seven days in a row, some days Etiona works fine (three),
other days (three so far) there have been multiple freezes, necessitating frequent restarts; one day to go.

The data that I'm getting from nmap seem unreliable; PTR's that return "Failed to resolve" responses can
indeed be resolved with dig. It could be that the WiFi dongle is receiving data from the Internet that nmap
treats as a negative response on the bad days. I'll check the weather reports for my ZIP code for last
Wednesday through tomorrow (Tuesday June 15). What I'm finding with the data on good days may be that the
PTR's for the same set of IPv4 addresses are getting changed from one day to the next. I've written a script
for that, but haven't had time to run it.

By Thursday I may have some data to report ...