Dear Maintainer,

below i describe multiple bugs in booting in jessie, which
might be relevant to stretch.

most are grave or critical.  many are accessibility-related.

please forgive any solecisms, such as putting more than one
thing into a bug report.  i am limited in computer use.

i provide suggested fixes where possible. however, i am just
an ordinary user.

===

notes:

just to be clear, i have never used lvm.

i have no /dev/mapper/sda7_crypt.  i do not
hibernate my desktop.

===

i want to document that my user experience booting in jessie
is broken.  separate bugs will not accomplish this.

it has taken me more than 3 months to debug this far -- 3
months of broken booting.  i still cannot boot to jessie.
(update much later: i finally was able to.)

the experience was unexpectedly hostile.  here are examples.

they are in sequence.

0.

i upgraded to jessie and found out that x won't work due to
modesetting something or other, unlike in wheezy.  turning
off or on modesetting introduces different bugs, which i
will not report here.  after months of debugging, i figured
out i might need nonfree firmware.  i tried forever to avoid
that, but nothing worked and nothing was documented.  so i
guessed that i need the firmware.

bug fix: document this in release notes

1.

rebooted, and discovered that the font was unreadably small,
unlike wheezy.

after difficulty, i figured out i had to change grub.  did
so.  that worked.  FOR A WHILE.

this is an accessibility bug.  it means that i cannot use
the computer.

bug fix: accessible defaults
bug fix: say how to change fonts

2.

booted.

after saying one line, it said "cryptsetup: lvm is not
available" repeatedly.

it was not possible to stop.

I HAVE NEVER RUN LVM.  i avoid lvm to avoid bugs.  and now
it is STILL causing bugs.  :(

to me as an ordinary user, this error message could be
improved to tell me what the problem is or give me a chance
to fix it.

there is nothing intelligible on the web about this.

bug fix: defensive programming
bug fix: meaningful error message please with sugar on top?
bug fix: ask the user for the partition
bug fix: don't assume it's lvm
bug fix: say what partition you tried

i don't think the ordinary user should be made to debug his
own initramfs.  or even know what an initramfs is.

2.5

update: [2017-02-11 Sat 12:41] it is absolutely confirmed
that the lvm is not available bug is intermittent.  just
now, i booted and got the bug.  then i booted again and it
was ok.  on previous occasions, it would not book.

3.

after those 3 months of debugging, i figured out that the
"lvm is not available" message means "you used
/dev/disk/by-id to specify partitions in fstab/crypttab and
we no longer support that in jessie, for unknown reasons".

i was told this was definitely fine to do.  furthermore, it
works on wheezy.

by-id notation is user friendly because you know what drive
you are on, unlike with uuid, and you don't have to screw
around with labels.  when you are new to debugging booting,
you want the information that by-id provides to fix
problems.  sometimes you have to reboot to find out what
drive it is.

arch wiki recommends it too.

however, on jessie, apparently the symlinks are not set up
at boot time.  but uuid and label symlinks are.

as of [2017-01-14 Sat] i do not use by-id, precisely because
of this bug.  HOWEVER, I STILL GET THE BUG.

bug fix: set up the symlinks.  why is by-id bad here?
bug fix: error message saying that /dev/disk/by-id symlink target not found
bug fix: document that they work or don't work
bug fix: offer a shell to set them up
bug fix: set them up as a special customer service if there is a bug
bug fix: have update-initramfs fail loudly instead of silently

4.

one of my goals is to set up a new drive as a backup -- with
accessibility fixed as much as possible -- in case there are
problems booting to my main drive.  however, this is
problematic.

with or without this:

i have had many, many, runins with update-initramfs.  i
finally settled on something that seemed to work:

    # of course i looked for error messages
    update-initramfs -u -k all &&
        echo update-initramfs returned normal exit code. like i believe that.
    # fixme update-grub should, but does not, create /boot/grub/grub.cfg
    update-grub
    # we do either grub-install or dpkg-reconfigure
    # dpkg-reconfigure says what future upgrades should install to
    echo enter argument to grub-install like /dev/sdb and sacrifice a goat:
    grub-install `line`

maybe this is totally wrong.  i am an ordinary person just
trying to get my computer to work.  i tried dpkg-reconfigure
grub-pc also.

in order to put in the brittle, hardcoded partition syntax,
i did the above.

but guess what?  update-initramfs silently failed to change
initrd/conf/conf.d/cryptroot!

in the past it silently failed to create it at all, so this
is progress!

bug fix: don't silently fail
bug fix: don't fail to write a file
bug fix: don't fail to update a file
bug fix: don't make user edit his or her initrd
bug fix: don't make user have to debug

5.

after i figured all of this out and put in the brittle,
hardcoded partition syntax into the initrd...

and remember, i didn't even know what an initrd was....

i rebooted and it worked.

FOR A FEW SECONDS.

it then SWITCHED FONT BACK TO UNREADABLE, DESPITE MY HAVING
FIXED GRUB.  apparently debian wants to make its fonts
unreadable because accessibility is communist and should be
abolished or the world will start singing "Imagine" and
waving a hammer and sickle around.

bug fix: stick with the wheezy 640x480 fonts by default
bug fix: say how to change font size
bug fix: default to what grub did for fonts
bug fix: remember that accessibility is needed
bug fix: make future software accessible
bug fix: *PUT ACCESSIBILITY IN THE DEBIAN SOCIAL CONTRACT*
bug fix: document accessibility basics
bug fix: remember how debian was supposed to be for EVERYBODY?

imagine ALL the people.  please.

6.

there are still bugs.

they have something to do with "emergency mode" and there
are unreadable instructions (because bugs) about journalctl.
and something like "start job is running for".  and it
doesn't like control alt delete.  charming i'm sure.

but the font is too small and i can't fix them.  or even
report them adequately.

even if i could read them, i'd have to write them down.  the
kernel does not save errors to, e.g. /boot so you can get
help with errors or search for them.

bug fix: if you're going to introduce stuff user has to do,
offer to put those instructions onto a partition in a file.

bug fix: write logs, errors, and instructions to a file
bug fix: if you are in emergency mode, say WHY
bug fix: fix whatever bug caused the problem

7.

it prompted to do ^D to continue.  i did so.  nothing
happened.

bug fix: you get the drill

8.

whenever i have to use the linux console, i have significant
neurological issues, due to the blinking cursor.

this includes when booting, logging in, using the command
line, using emacs, etc.

bug fix: do not blink by default.  i suggest a large inverted box.
bug fix: blinking is an accessibility issue

there is an ansi sequence that turns off blinking, but it
frequently gets reset again for unknown reasons.
furthermore, emacs resets the terminal to blink again.
furthermore, an ansi sequence is not somethign that you can
memorize for when you are having computer problems.

===

8.5.

accessibility issues in debian are often given less credence
than mere wishlist items.  there is a pervasive sense of
dismissal.  people often say "it does not affect me,
therefore it does not matter".

even where somebody doesn't think it's a problem for
themselves, they will sometimes fix somebody's wishlist, but
if it is an accessibility issue there is sometimes
hostility, and demands for biomedical proof, and so on.
this is clear bigotry.

it would be great if accessibility were in the social
contract.  explicit acknowledgement that people matter.

===

note: i got the bogus "lvm is
not available" bug again today [2017-01-14 Sat]  when
upgrading.  i then rebooted again and it worked.  so it's
intermittent.

also, today i got the "inability to shut down because a
stop job is waiting" systemd bug.  but i finally got through
that one.  but i fear it.  it could bite me at any time.
just as "lvm is not available" could.

===

most of these are /dealbreaker bugs/.  they are /grave or
critical/.  i hope this will not be downgraded.

as an ordinary user, i think i have gone the extra mile in
trying to debug this.

===

i have severe rsi preventing detailed contact.  future email
will be limited.


*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Hi gofloss,
made a note about it, I believe because you put so many issues into one
bug report, it was too overwhelming for everybody that looked at your
bug to do the proper cloning and reassigning. I acknowledge that you got
frustrated, but the tone of your report was not very friendly in the
end, which may have contribution to the lack of response.

Unfortunately you reported the issue against the pseudo package base,
which doesn't get much attention. Because most of your issues were
upgrade issues, I suggest for next time to use release-notes or
upgrade-reports as the package to file your report to. Also, for future
reference, adding the accessibility list in CC may help. I am doing that
now, and add your original report as an attachment so that interested
people can comment. If any of you can identify packages to assign one of
the issues to, please clone and reassign. I'll clone/reassign issue 4,
the initramfs issue, shortly.

I am tagging this report for accessibility (a11y).

The accessibility Wiki has some answers to you questions already:
https://wiki.debian.org/accessibility e.g. on you grub magnification
issue. Maybe we can improve the Wiki with answers to issues you encountered.

Paul

Hello,

gofloss gofloss, le mar. 06 juin 2017 13:52:05 -0700, a ecrit:

[...]

I guess that your computer has a screen with a quite high dpi?

This was already reported as bug #816111, and also #595696 mentioned
generating rasterized fonts, we definitely need to fix this to have sane
console sizes.

Samuel

gofloss gofloss, le mar. 06 juin 2017 13:52:05 -0700, a ecrit:

Nope.  I understand that you got a big pile of frustration like hell,
but unfortunately what followed this sentence can't get anything
positive done.  Debian clearly does have accessibility goals.  But like
all software, it does have bugs.  No, we don't intentionally make fonts
unreadable, there are just bugs, and the introduction of hidpi screens
really do not help.  And until somebody manages to find the time to fix
bugs, yes, there will be bugs.  It does not mean we don't want to fix
them, but that we haven't found the time to fix them yet.

I haven't ever seen such a thing in Debian.

Oh, I did not know that even just the blinking cursor could have an
impact.

The problem is that the tty defaults (as in: casted into hardcoded
values that really can't be changed) is to blink.

You can put it in $PS1, though.

Samuel

Hello,

I'm here looking for opinions from debian-accessibility from people with
low vision.

Samuel Thibault, le lun. 10 juin 2019 22:02:05 +0200, a ecrit:

We can probably try to change the default value in the kernel (it's
really not only about Debian), if it makes consensus that it doesn't
hurt most people. I guess the kernel uses a small blinking cursor by
default solely because that was the default VGA hardware parameter.

When looking around in xterms and such, I see that they are using by
default a blocked cursor. Xterms usually don't make it blink, I see only
Gnome-terminal making it blink by default.

A non-blinking small cursor would pose visibility problem, but perhaps a
non-blinking big cursor would be fine? (perhaps even more visible than
the current blinking small cursor?)

Samuel

Hello,

I've got low vision as well and don't like the blinking cursor either. I'm
using gnome-terminal most of the time and find the big, blinking cursor
quite nice. Maybe a non-blinking cursor might catch less attention,
especially when you're in some kind of ncurses UI, maybe even one with
a changed colorset) and the cursor is somewhere you don't expect it to be.

But I agree: the current console cursor isn't friendly to people with
low vision.

Best regards
Robert

In Bash it is possible to set a feature that runs when a command runs
called precmd to an ANSI sequence that sets a non-blinking block
cursor.  This make Bash usable.

However, that fails if there is no Bash or you not have your .bashrc.
There are shell-like entitities that are needed to fix booting.

Also, Emacs still blinks!  It seems to be either the Linux console or
the Emacs C code. Elisp lets you control blinking if you are running
Emacs in an terminal under X or as GUI uner X, but not if you are
running Emacs in the Linux console.  So if you need Emacs to fix a
booting problem, you can't use it if you have problems with blinking.

Finally, an off-topic comment that white and blue are too bright at
night for me, and that the debconf blue and grey have the same problem
(the red is OK).  Not all can physically adjust their monitors.  What
would be good is the ability to adjust the console text color to
amber, and debconf to a contrasty amber theme, and brightness.