Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #180201 > unrolled thread

Jessie for Udoo X86?

Back to article view | Back to linux.debian.user

Contents

  Jessie for Udoo X86? Larry Dighera <LDighera@att.net> - 2017-04-17 06:30 +0200
    Re: Jessie for Udoo X86? Eduard Bloch <edi@gmx.de> - 2017-04-17 11:00 +0200
      Re: Jessie for Udoo X86? Larry Dighera <LDighera@att.net> - 2017-04-17 17:30 +0200
      Re: Jessie for Udoo X86? GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-17 18:00 +0200
        Re: Jessie for Udoo X86? Larry Dighera <LDighera@att.net> - 2017-04-18 01:00 +0200
          Re: Jessie for Udoo X86? GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-18 10:40 +0200
            Re: Jessie for Udoo X86? Larry Dighera <LDighera@att.net> - 2017-04-20 16:20 +0200
              Re: Jessie for Udoo X86? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-04-20 16:30 +0200
              Re: Jessie for Udoo X86? David Wright <deblis@lionunicorn.co.uk> - 2017-04-20 21:20 +0200
                Re: Jessie for Udoo X86? Larry Dighera <LDighera@att.net> - 2017-04-24 04:00 +0200
                  Console fonts, was Re: Jessie for Udoo X86? David Wright <deblis@lionunicorn.co.uk> - 2017-04-24 05:30 +0200
                    Re: Console fonts, was Re: Jessie for Udoo X86? Larry Dighera <LDighera@att.net> - 2017-05-01 01:50 +0200
                      Re: Console fonts Felix Miata <mrmazda@earthlink.net> - 2017-05-01 03:40 +0200
                        Re: Console fonts Larry Dighera <LDighera@att.net> - 2017-05-02 21:30 +0200
                          Re: Console fonts Felix Miata <mrmazda@earthlink.net> - 2017-05-03 01:00 +0200
                          Re: Console fonts David Wright <deblis@lionunicorn.co.uk> - 2017-05-03 01:50 +0200
                            Re: Console fonts Larry Dighera <LDighera@att.net> - 2017-05-03 18:40 +0200
                              Re: Console fonts David Wright <deblis@lionunicorn.co.uk> - 2017-05-04 02:40 +0200
                          Re: Console fonts David Wright <deblis@lionunicorn.co.uk> - 2017-05-03 03:30 +0200
                            Re: Console fonts Larry Dighera <LDighera@att.net> - 2017-05-03 19:10 +0200
                              Re: Console fonts Felix Miata <mrmazda@earthlink.net> - 2017-05-03 22:20 +0200
                              Re: Console fonts David Wright <deblis@lionunicorn.co.uk> - 2017-05-04 02:40 +0200
                      Re: Console fonts, was Re: Jessie for Udoo X86? David Wright <deblis@lionunicorn.co.uk> - 2017-05-01 18:30 +0200
            Re: Jessie for Udoo X86? Larry Dighera <LDighera@att.net> - 2017-04-23 21:40 +0200
              Re: Jessie for Udoo X86? GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-24 00:20 +0200
              Re: Jessie for Udoo X86? songbird <songbird@anthive.com> - 2017-04-24 01:50 +0200
              Re: Jessie for Udoo X86? Greg Wooledge <wooledg@eeg.ccf.org> - 2017-04-24 14:40 +0200

Page 1 of 2  [1] 2  Next page →

#180201 — Jessie for Udoo X86?

The new Udoo X86 boards have just begun to ship: <http://www.udoo.org/>. 

Is anyone able to provide a link to the 64-bit Debian Jessie USB/SD
installation ISO/img?

ADVthanksANCE

[toc] | [next] | [standalone]

#180203

Hallo,
* Larry Dighera [Sun, Apr 16 2017, 09:27:46PM]:
> 
> The new Udoo X86 boards have just begun to ship: <http://www.udoo.org/>. 
> 
> Is anyone able to provide a link to the 64-bit Debian Jessie USB/SD
> installation ISO/img?

Did you try the regular installer from USB stick already?

Data sheet indicates that it supports "All Linux Flavors for x86". Which
means that it's probably usual Intel hardware inside. It might lack a
few drivers for recent hardware revisions but you could install a
kernel from jessie-backports in that case.

Best regards,
Eduard.

[toc] | [prev] | [next] | [standalone]

#180208

On Mon, 17 Apr 2017 10:55:23 +0200, Eduard Bloch <edi@gmx.de> wrote:

>Hallo,
>* Larry Dighera [Sun, Apr 16 2017, 09:27:46PM]:
>> 
>> The new Udoo X86 boards have just begun to ship: <http://www.udoo.org/>. 
>> 
>> Is anyone able to provide a link to the 64-bit Debian Jessie USB/SD
>> installation ISO/img?
>
>Did you try the regular installer from USB stick already?
>
>Data sheet indicates that it supports "All Linux Flavors for x86". Which
>means that it's probably usual Intel hardware inside. It might lack a
>few drivers for recent hardware revisions but you could install a
>kernel from jessie-backports in that case.
>
>Best regards,
>Eduard.


Hello Eduard,

Thank you for your response to my inquiry.

No; I have not yet tried the "regular installer from USB stick."  Are you
able to provide a link to the correct one?  

That sounds like what I'm looking for to install Debian Jessie 64-bit on the
Udoo X86 Advanced board with Intel Celeron N3160 CPU clocked at 2.24 GHz:
<http://shop.udoo.org/usa/preorder-x86.html>.

Best regards,
Larry

[toc] | [prev] | [next] | [standalone]

#180212

Eduard Bloch:
> Hallo,
> * Larry Dighera [Sun, Apr 16 2017, 09:27:46PM]:
>>
>> The new Udoo X86 boards have just begun to ship: <http://www.udoo.org/>. 
>>
>> Is anyone able to provide a link to the 64-bit Debian Jessie USB/SD
>> installation ISO/img?
> 
> Did you try the regular installer from USB stick already?

https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/

If live runs well chances are that you can install it

there is Puppy Linux among others that run entirely on RAM, once loaded
no disk is required, ideally they will run as long as there is a
continuous power supply.  Given enough ram you can modify most linux to
run this way, but some are designed and modified specifically saving you
the trouble.

> Data sheet indicates that it supports "All Linux Flavors for x86". Which
> means that it's probably usual Intel hardware inside. It might lack a
> few drivers for recent hardware revisions but you could install a
> kernel from jessie-backports in that case.

Interesting and seems more potent than the raspberry system.  But if
size did not matter so damn much for less money you can get a decent
USFF box and throw the box away and pretend you are building from
scratch.  I suspect the quality of some older USFF is higher.  Yes the
processor and cooling aparatus is a bit bulky ... but it depends on the
use and available space/weight requirement.



-- 
 "The most violent element in society is ignorance" rEG

"Who died and made you the superuser?"  Brooklinux

"keep rocking in the non-free world" Neilznotyoung

[toc] | [prev] | [next] | [standalone]

#180235

On Mon, 17 Apr 2017 15:51:00 +0000, GiaThnYgeia
<GiaThnYgeia@openmailbox.org> wrote:

>Eduard Bloch:
>> Hallo,
>> * Larry Dighera [Sun, Apr 16 2017, 09:27:46PM]:
>>>
>>> The new Udoo X86 boards have just begun to ship: <http://www.udoo.org/>. 
>>>
>>> Is anyone able to provide a link to the 64-bit Debian Jessie USB/SD
>>> installation ISO/img?
>> 
>> Did you try the regular installer from USB stick already?
>
>https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
>
>If live runs well chances are that you can install it
>
>there is Puppy Linux among others that run entirely on RAM, once loaded
>no disk is required, ideally they will run as long as there is a
>continuous power supply.  Given enough ram you can modify most linux to
>run this way, but some are designed and modified specifically saving you
>the trouble.
>
>> Data sheet indicates that it supports "All Linux Flavors for x86". Which
>> means that it's probably usual Intel hardware inside. It might lack a
>> few drivers for recent hardware revisions but you could install a
>> kernel from jessie-backports in that case.
>
>Interesting and seems more potent than the raspberry system.  But if
>size did not matter so damn much for less money you can get a decent
>USFF box and throw the box away and pretend you are building from
>scratch.  I suspect the quality of some older USFF is higher.  Yes the
>processor and cooling aparatus is a bit bulky ... but it depends on the
>use and available space/weight requirement.

Thank you for your response.

I found the 'debian-8.7.1-amd64-DVD-1.iso' image here:
<http://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/>, burned it to
SD card in a USB reader with Rufus <https://rufus.akeo.ie/>, and booted it
from USB on the Udoo X86 Advanced hardware (Intel quad-core Celeron N3160
2.24 GHz & Intel® Quark SE core 32 MHz plus 32-bit ARC core 32 MHz, Intel HD
Graphics 400 Up to 640 MHz 12 execution units, 4 GB DDR3L Dual Channel RAM
and 32GB eMMC Storage).  

I selected the GUI Install from the menu, and all proceeded remarkably fast
and smooth without a hitch (except the WiFi, but gigabit Ethernet enabled
downloading all required additional files) until the last when it came to
grub.  

The installer advised that it had detected another OS being installed, and
presented me with a few choices to which I wasn't sure of the correct one,
so I took the default.  That must have been wrong, as now Debian won't boot
with grub from the eMMC "Hard Drive."  I'm not at all familiar with grub.

I can boot into recovery mode though, and from the command line it appears
the install was successful.  So I'm close, but don't know exactly how to
proceed to make it bootable.

Any clues sincerely appreciated.

[toc] | [prev] | [next] | [standalone]

#180240

Larry Dighera:
> I found the 'debian-8.7.1-amd64-DVD-1.iso' image here:
> <http://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/>, burned it to
> SD card in a USB reader with Rufus <https://rufus.akeo.ie/>, and booted it
> from USB on the Udoo X86 Advanced hardware (Intel quad-core Celeron N3160
> 2.24 GHz & Intel® Quark SE core 32 MHz plus 32-bit ARC core 32 MHz, Intel HD
> Graphics 400 Up to 640 MHz 12 execution units, 4 GB DDR3L Dual Channel RAM
> and 32GB eMMC Storage). 

The link I sent you was for live versions where a complete Debian
installation boots up (if it is possible based on the hardware) which is
a very good indication that your installation will act just like it.
You can select any desktop and then switch and install any desktop you
like from the system once it is running.  I always use lxde as it is
lean and mean.  This live version includes the debian installer which
you can reboot and run from scratch or run it within the live debian
system.  I prefer to reboot and run the installer alone after I have
made sure live runs fine.  This gives the installer maximum resources
and there are less things to confuse it.  You see from live when grub is
installed it picks up the live drive as one of the installed systems.
You have to keep an eye on what you select on the grub installation.
But this would be a small problem, having an invalid boot option on your
grub.

> I selected the GUI Install from the menu, and all proceeded remarkably fast
> and smooth without a hitch (except the WiFi, but gigabit Ethernet enabled
> downloading all required additional files) until the last when it came to
> grub.  

Don't get me started down that path ;)

> The installer advised that it had detected another OS being installed, and
> presented me with a few choices to which I wasn't sure of the correct one,
> so I took the default.  That must have been wrong, as now Debian won't boot
> with grub from the eMMC "Hard Drive."  I'm not at all familiar with grub.

Were you aware that there was an installed system on that disk and what
it is?  Is it now an option on the grub boot-up screen? Remember that if
you move the arrow up and down within the first 5" the default autostart
that is timed to 5" is deactivated and you now have time to study it.
Your first option on the base screen should be the debian you installed.
 The second should be for recovery which opens up a second screen where
recovery is the 2nd option.  Is that what you used?
Then on the base screen you should have 3 lines of memtest options, and
at the bottom the "other" system that was previously installed.  It may
be freedos or something factory???

> I can boot into recovery mode though, and from the command line it appears
> the install was successful.  So I'm close, but don't know exactly how to
> proceed to make it bootable.

In order to get to the grub part of the installation the system was
completely installed and it is there.  There is an option to install
grub to handle booting of all systems on the drive (possibly sda) and/or
the partition itself where Debian was installed in which case it makes
the partition bootable.  I assume the default is the first.

> Any clues sincerely appreciated.

When you pick the first option of Debian to boot, what do you see on the
screen?  Lines of white text running some green and maybe red stuff?
If it is all green you are in good shape, if it is red you have to
concentrate on that first red tag and tell us what it says.

Again, if there was a hardware issue the live system would have
identified and displayed what the obstacle was.  Possibly you have to go
into recovery, edit the sources (/etc/apt/sourced.list) and add "main
contrib non-free" to where it says "main" if such firmware exist.  Then
$apt update, $apt upgrade but then you have to know what you are missing
to find the appropriate package to add if it exists.

-- 
 "The most violent element in society is ignorance" rEG

"Who died and made you the superuser?"  Brooklinux

"keep rocking in the non-free world" Neilznotyoung

[toc] | [prev] | [next] | [standalone]

#180331

On Tue, 18 Apr 2017 08:30:00 +0000, GiaThnYgeia
<GiaThnYgeia@openmailbox.org> wrote:

>
>
>Larry Dighera:
>> I found the 'debian-8.7.1-amd64-DVD-1.iso' image here:
>> <http://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/>, burned it to
>> SD card in a USB reader with Rufus <https://rufus.akeo.ie/>, and booted it
>> from USB on the Udoo X86 Advanced hardware (Intel quad-core Celeron N3160
>> 2.24 GHz & Intel® Quark SE core 32 MHz plus 32-bit ARC core 32 MHz, Intel HD
>> Graphics 400 Up to 640 MHz 12 execution units, 4 GB DDR3L Dual Channel RAM
>> and 32GB eMMC Storage). 
>
>The link I sent you was for live versions where a complete Debian
>installation boots up (if it is possible based on the hardware) which is
>a very good indication that your installation will act just like it.
>You can select any desktop and then switch and install any desktop you
>like from the system once it is running.  I always use lxde as it is
>lean and mean.  This live version includes the debian installer which
>you can reboot and run from scratch or run it within the live debian
>system.  I prefer to reboot and run the installer alone after I have
>made sure live runs fine.  This gives the installer maximum resources
>and there are less things to confuse it.  You see from live when grub is
>installed it picks up the live drive as one of the installed systems.
>You have to keep an eye on what you select on the grub installation.
>But this would be a small problem, having an invalid boot option on your
>grub.
>
>> I selected the GUI Install from the menu, and all proceeded remarkably fast
>> and smooth without a hitch (except the WiFi, but gigabit Ethernet enabled
>> downloading all required additional files) until the last when it came to
>> grub.  
>
>Don't get me started down that path ;)
>
>> The installer advised that it had detected another OS being installed, and
>> presented me with a few choices to which I wasn't sure of the correct one,
>> so I took the default.  That must have been wrong, as now Debian won't boot
>> with grub from the eMMC "Hard Drive."  I'm not at all familiar with grub.
>
>Were you aware that there was an installed system on that disk and what
>it is?  Is it now an option on the grub boot-up screen? Remember that if
>you move the arrow up and down within the first 5" the default autostart
>that is timed to 5" is deactivated and you now have time to study it.
>Your first option on the base screen should be the debian you installed.
> The second should be for recovery which opens up a second screen where
>recovery is the 2nd option.  Is that what you used?
>Then on the base screen you should have 3 lines of memtest options, and
>at the bottom the "other" system that was previously installed.  It may
>be freedos or something factory???
>
>> I can boot into recovery mode though, and from the command line it appears
>> the install was successful.  So I'm close, but don't know exactly how to
>> proceed to make it bootable.
>
>In order to get to the grub part of the installation the system was
>completely installed and it is there.  There is an option to install
>grub to handle booting of all systems on the drive (possibly sda) and/or
>the partition itself where Debian was installed in which case it makes
>the partition bootable.  I assume the default is the first.
>
>> Any clues sincerely appreciated.
>
>When you pick the first option of Debian to boot, what do you see on the
>screen?  

It happens very quickly.  There is a brief flash of color, and perhaps a few
lines of text, then an interminable black screen with no response to
keyboard/mouse input.

>Lines of white text running some green and maybe red stuff?
>If it is all green you are in good shape, if it is red you have to
>concentrate on that first red tag and tell us what it says.
>

I'm familiar with the dmesg output at boot time.  I see that when I choose
to boot into recovery mode from the grub menus.  When the scrolling text
stops, I'm left with what I thought was a frozen screen, but it turns out to
be login, without a prompt, waiting for me to provide the root password.
Once I submit the root password, I have a command line interface to a
reasonably functional Debian system.

>
>Again, if there was a hardware issue the live system would have
>identified and displayed what the obstacle was.  Possibly you have to go
>into recovery, edit the sources (/etc/apt/sourced.list) and add "main
>contrib non-free" to where it says "main" if such firmware exist.  Then
>$apt update, $apt upgrade but then you have to know what you are missing
>to find the appropriate package to add if it exists.
>

What I have discovered thus far, is that Debian wants to launch X11 by
default, instead of the command line UI.  That appears to result in a black
screen with a frozen system.  

At this point, I have no idea of the correct way to boot to the command line
interface, so I temporarily renamed lightdm, and now it boots to the command
line interface apparently after X11 fails to launch.  So, it appears that it
is X11 that has possible issues with the hardware or is misconfigured.
Perhaps there is something in X11's /var/log file that will provide a clue
about why it was failing to successfully launch.

So, it appears that grub is correctly configured after all.  

What is the correct way to configure the system to boot to the command line
UI instead of X11?  Do I need to edit things, or add files to, /etc/rc.d
someplace?  Or is there a higher-level way to tell systemd that I prefer to
manually launch X11?  

I'm aware that running the startx script is a reasonable way to launch X11
when I want it, but I'll have to diagnose its issue(s) first.  My past
familiarity with AT&T Unix from the early '80s through the '90s was pre-X11,
so I'm going to have to learn how to administrate X11 now I suppose.  

I sincerely appreciate your kind efforts in guiding me.  I gives me the
motivation to continue spending the time to get Jessie up on the new Udoo
X86 platform.

[toc] | [prev] | [next] | [standalone]

#180332

On Thu, Apr 20, 2017 at 07:11:53AM -0700, Larry Dighera wrote:
> I'm familiar with the dmesg output at boot time.  I see that when I choose
> to boot into recovery mode from the grub menus.  When the scrolling text
> stops, I'm left with what I thought was a frozen screen, but it turns out to
> be login, without a prompt, waiting for me to provide the root password.
> Once I submit the root password, I have a command line interface to a
> reasonably functional Debian system.

Debian's GRUB menu passes a "quiet" parameter[1] to the kernel to
suppress most of the normal messages.  If this parameter is omitted
(e.g. when you use the "Recovery mode" choice in GRUB), you get kernel
messages from various subsystems as they are brought up.

Before systemd, booting was a much more linear process.  Subsystems
would be brought up one by one, and when enough of them were ready,
you'd get a login prompt.

Now, however, the highly parallelized systemd boot means multiple
subsystems are being brought up simultaneously, and some of them are
still initializing when the login prompt is displayed.  If you're also
seeing their output, what this means is *sometimes*, depending on how
the race conditions play out, you might get system output *after* the login
prompt has already been displayed.  If you aren't carefully reading
everything on the screen, it may be easy to overlook the login prompt
buried several lines up (or in a very bad case scenario, even scrolled
off the visible terminal).

Normally, once things seem like they've reached a stable point, if you
aren't sure if there's a login prompt, it should be safe for you to
press Enter.  If you're seeing a regular getty login prompt, then
you should simply get another one.  If you're getting the single user
mode "enter root password to continue" prompt, you should get another
one of those as it considers your blank password to be a failed login
attempt, and it shouldn't self-destruct or anything like that after
just one failed attempt.

[1] See GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub.

[toc] | [prev] | [next] | [standalone]

#180344

On Thu 20 Apr 2017 at 07:11:53 (-0700), Larry Dighera wrote:

> What I have discovered thus far, is that Debian wants to launch X11 by
> default, instead of the command line UI.  That appears to result in a black
> screen with a frozen system.  
> 
> At this point, I have no idea of the correct way to boot to the command line
> interface, so I temporarily renamed lightdm, and now it boots to the command
> line interface apparently after X11 fails to launch.  So, it appears that it
> is X11 that has possible issues with the hardware or is misconfigured.
> Perhaps there is something in X11's /var/log file that will provide a clue
> about why it was failing to successfully launch.
> 
> So, it appears that grub is correctly configured after all.  
> 
> What is the correct way to configure the system to boot to the command line
> UI instead of X11?  Do I need to edit things, or add files to, /etc/rc.d
> someplace?  Or is there a higher-level way to tell systemd that I prefer to
> manually launch X11?  

For jessie/systemd,

# systemctl set-default multi-user.target

and, to revert,

# systemctl set-default graphical.target

Removing the display manager was, I think, the old way.
Not installing one, OTOH, is still the normal way if
you don't want a DE (like me).

> I'm aware that running the startx script is a reasonable way to launch X11
> when I want it, but I'll have to diagnose its issue(s) first.  My past
> familiarity with AT&T Unix from the early '80s through the '90s was pre-X11,
> so I'm going to have to learn how to administrate X11 now I suppose.  
> 
> I sincerely appreciate your kind efforts in guiding me.  I gives me the
> motivation to continue spending the time to get Jessie up on the new Udoo
> X86 platform.

There are several recent threads in this list about getting the
right video drivers and X servers installed. Most of it goes
over my head because my hardware is so old.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#180435

David,

Thank you for you great response to my inquiry.  Very much appreciated.

My comments in-line below:


On Thu, 20 Apr 2017 14:14:40 -0500, David Wright <deblis@lionunicorn.co.uk>
wrote:

>On Thu 20 Apr 2017 at 07:11:53 (-0700), Larry Dighera wrote:
>
>> What I have discovered thus far, is that Debian wants to launch X11 by
>> default, instead of the command line UI.  That appears to result in a black
>> screen with a frozen system.  
>> 
>> At this point, I have no idea of the correct way to boot to the command line
>> interface, so I temporarily renamed lightdm, and now it boots to the command
>> line interface apparently after X11 fails to launch.  So, it appears that it
>> is X11 that has possible issues with the hardware or is misconfigured.
>> Perhaps there is something in X11's /var/log file that will provide a clue
>> about why it was failing to successfully launch.
>> 
>> So, it appears that grub is correctly configured after all.  
>> 
>> What is the correct way to configure the system to boot to the command line
>> UI instead of X11?  Do I need to edit things, or add files to, /etc/rc.d
>> someplace?  Or is there a higher-level way to tell systemd that I prefer to
>> manually launch X11?  
>
>For jessie/systemd,
>
># systemctl set-default multi-user.target
>
>and, to revert,
>
># systemctl set-default graphical.target
>

That worked perfectly.  Thank you very much.

>
>Removing the display manager was, I think, the old way.
>Not installing one, OTOH, is still the normal way if
>you don't want a DE (like me).
>
>> I'm aware that running the startx script is a reasonable way to launch X11
>> when I want it, but I'll have to diagnose its issue(s) first.  My past
>> familiarity with AT&T Unix from the early '80s through the '90s was pre-X11,
>> so I'm going to have to learn how to administrate X11 now I suppose.  
>> 
>> I sincerely appreciate your kind efforts in guiding me.  I gives me the
>> motivation to continue spending the time to get Jessie up on the new Udoo
>> X86 platform.
>
>There are several recent threads in this list about getting the
>right video drivers and X servers installed. Most of it goes
>over my head because my hardware is so old.
>
>Cheers,
>David.

I'll have to search the list archives.  Thank you for the pointer.


I'd like to have more lines/rows and columns on the console tty.  I've read
that 'vidcontrol' may do what I want, unfortunately 'apt-cache show
vidcontrol' reports that it is virtual (unavailable).  

I am grateful for any clues you may be able to provide.

Best regards,
Larry

[toc] | [prev] | [next] | [standalone]

#180439 — Console fonts, was Re: Jessie for Udoo X86?

On Sun 23 Apr 2017 at 18:55:03 (-0700), Larry Dighera wrote:

> I'd like to have more lines/rows and columns on the console tty.  I've read
> that 'vidcontrol' may do what I want, unfortunately 'apt-cache show
> vidcontrol' reports that it is virtual (unavailable).  
> 
> I am grateful for any clues you may be able to provide.

Best to start a new thread with a new subject, but anyway…

The Debian Way to set a default font for dmesg output, login prompt,
etc is (I think) to edit /etc/default/console-setup
I like Terminus fonts (package console-setup-linux, I think),
so I have:

ACTIVE_CONSOLES="/dev/tty[1-6]"
CHARMAP="UTF-8"
CODESET="Lat15"
#FONTFACE="Fixed"
FONTFACE="Terminus"
FONTSIZE="10x20"
#FONTSIZE="12x24"
#FONTSIZE="14x28"
#FONTSIZE="16x32"
VIDEOMODE=

in there, with various sizes available.

However, I prefer using aliases like:

alias my-font-tiny="setfont Lat15-Terminus12x6"
alias my-font-small="setfont Lat15-Terminus14"
alias my-font-medium="setfont Lat15-Terminus20x10"
alias my-font-large="setfont Lat15-Terminus24x12"
alias my-font-huge="setfont Lat15-Terminus28x14"
alias my-font-vast="setfont Lat15-Terminus32x16"

because you can then have different font sizes on each VC.
I also have a bash function to choose an arbitrary font:

function my-font-usr-share-consolefonts {
    [ -z "$1" ] && printf '%s\n' "Usage: $FUNCNAME /usr/share/consolefonts/<fontname>.psf.gz
        sets the specified font on the current VC.
        The command name serves as a reminder of the fonts' location.
        Use filename-completion to specify the appropriate filename.
        Redundant elements of the filename are stripped out before use.
        Typically, filenames start Lat15- or Uni." >&2 && return 1
    local FILENAME="$(basename "$1")"
    setfont "${FILENAME%%.*}"
}

Typing my-font<TAB><TAB> reminds me of the name of the command,
and the name of the command reminds me of the path to type in.
<TAB><TAB> then lists the font files to use filename completion on.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#180560 — Re: Console fonts, was Re: Jessie for Udoo X86?

Hello David,

Thank you very much for taking the time to educate me about this display
issue.

My comments in-line below:


On Sun, 23 Apr 2017 22:19:47 -0500, David Wright <deblis@lionunicorn.co.uk>
wrote:

>On Sun 23 Apr 2017 at 18:55:03 (-0700), Larry Dighera wrote:
>
>> I'd like to have more lines/rows and columns on the console tty.  I've read
>> that 'vidcontrol' may do what I want, unfortunately 'apt-cache show
>> vidcontrol' reports that it is virtual (unavailable).  
>> 
>> I am grateful for any clues you may be able to provide.
>
>Best to start a new thread with a new subject, but anyway…
>
>The Debian Way to set a default font for dmesg output, login prompt,
>etc is (I think) to edit /etc/default/console-setup
>I like Terminus fonts (package console-setup-linux, I think),
>so I have:
>
>ACTIVE_CONSOLES="/dev/tty[1-6]"
>CHARMAP="UTF-8"
>CODESET="Lat15"
>#FONTFACE="Fixed"
>FONTFACE="Terminus"
>FONTSIZE="10x20"
>#FONTSIZE="12x24"
>#FONTSIZE="14x28"
>#FONTSIZE="16x32"
>VIDEOMODE=
>
>in there, with various sizes available.
>

The default console display size is 80 columns by 25 rows.  

Setting FONTFACE="Terminus" and FONTSIZE="12x6", in the hope reducing the
font size from 10x20 would result in getting more characters on the console
display, I found it didn't change anything.  I presume the 12 in 12x6 refers
to the height of the character matrix block, and the 6 the width, so if
that's correct it should permit about three times as many characters in a
row.  

I read the console-setup manual pages, and noticed SCREEN_WIDTH and
SCREEN_HEIGHT mentioned, so I put SCREEN_WIDTH="50" in the
/etc/default/console-setup file as a test to see if my edits were able to
effect some viable change in the console display.  Upon reboot, indeed the
screen was set to 50 columns, so I did a 'stty columns 80', and it was
restored to the default 80x25 size.

I suspect the failure to see any change when specifying FONTSIZE="12x6" was
probably a result of a limitation of the Udoo X86's Intel HD-graphics
display hardware limitations or the BIOS or something.

I found that 'setupcon' would cause the system to re-read the
/etc/default/console-setup file, so I could test edits without rebooting.   

The 'setfont' command does appear to be an alternate method of loading
console fonts.  But, it's difficult to know what valid arguments might be
for my system.

I tried the 'resizecons' command with -lines 132, and indeed there was some
change, however the screen was unreadable.  The resizecons man page is very
terse.  

So, after much experimentation and frustration, I'm afraid I've failed to
increase the amount of information that can be displayed on the console
screen.  Oh well...  

I am very grateful for your kind assistance, David.  And I'm willing to keep
trying if you are.  :-)



>
>However, I prefer using aliases like:
>
>alias my-font-tiny="setfont Lat15-Terminus12x6"
>alias my-font-small="setfont Lat15-Terminus14"
>alias my-font-medium="setfont Lat15-Terminus20x10"
>alias my-font-large="setfont Lat15-Terminus24x12"
>alias my-font-huge="setfont Lat15-Terminus28x14"
>alias my-font-vast="setfont Lat15-Terminus32x16"
>
>because you can then have different font sizes on each VC.
>I also have a bash function to choose an arbitrary font:
>
>function my-font-usr-share-consolefonts {
>    [ -z "$1" ] && printf '%s\n' "Usage: $FUNCNAME /usr/share/consolefonts/<fontname>.psf.gz
>        sets the specified font on the current VC.
>        The command name serves as a reminder of the fonts' location.
>        Use filename-completion to specify the appropriate filename.
>        Redundant elements of the filename are stripped out before use.
>        Typically, filenames start Lat15- or Uni." >&2 && return 1
>    local FILENAME="$(basename "$1")"
>    setfont "${FILENAME%%.*}"
>}
>
>Typing my-font<TAB><TAB> reminds me of the name of the command,
>and the name of the command reminds me of the path to type in.
><TAB><TAB> then lists the font files to use filename completion on.
>
>Cheers,
>David.

Thanks for that, but I'm not there yet.  :-)

Apparently it's possible to do something similar by creating additional
/etc/default/console-setup files with filenames e.g. console-setup-small to
enable setfont to load alternate console line and column setups also.

[toc] | [prev] | [next] | [standalone]

#180566 — Re: Console fonts

Larry Dighera composed on 2017-04-30 16:40 (UTC-0700):
[...]
Previously, in OP https://lists.debian.org/debian-user/2017/04/msg00534.html :
http://www.udoo.org/
***
	Without anything there indicating date of release, that URI strongly suggests
to me nevertheless that his hardware is newer than Jessie can be expected to
support.

GiaThnYgeia later wrote:
$ inxi -c10 -v3
Will list basic system info and hardware
***
	I found nothing in the archive or on original reading of the thread responding
to this, but then later I did see OP wrote:

Intel quad-core Celeron N3160
2.24 GHz & Intel® Quark SE core 32 MHz plus 32-bit ARC core 32 MHz, Intel HD
Graphics 400 Up to 640 MHz 12 execution units, 4 GB DDR3L Dual Channel RAM
and 32GB eMMC Storage
***
	This supports my suspicion. Later, OP provided logs, which contained:

Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64
root=UUID=f0748180-a596-4f02-85d8-34b09b57cb42 ro quiet
(EE) open /dev/dri/card0: No such file or directory
(EE) open /dev/dri/card0: No such file or directory
(EE) open /dev/fb0: No such file or directory
(EE) open /dev/fb0: No such file or directory
(EE) Screen 0 deleted because of no matching config section.
(EE) Screen 0 deleted because of no matching config section.
***
	These support my suspicion, and explain why his ttys are stuck in 80x25 mode,
unresponsive to later instruction from David Wright. Lack of /dev/fb0 is a not
unusual pre-KMS result from a kernel cmdline (from the selected Grub stanza, as
modified, if modified) that lacks anything telling the kernel not to enable
framebuffer, resulting in use of 80x25 text mode on the ttys. Since Jessie's
3.16 kernel does support KMS, his 1920x1080 Samsung SyncMaster display's native
mode should be picked up by KMS, but that depends on the kernel supporting his
Intel HD Graphics 400 device. Possibly Grub could be reconfigured to make a
lesser mode like 1440x900 or less explicit. Lack of /dev/dri/card0 explains why
X doesn't work, the kernel found no supported gfx device.

When I boot an Intel video Jessie PC with no video parameters on cmdline,
root=LABEL=deb8jessie plymouth.enable=0 noresume
I see kernel messages begin in 80x25 mode, after which the kernel figures out
the display's native mode and switches to it, resulting in ttys producing 210
columns by 65 rows.
# inxi -c0 -G
Graphics:  Card: Intel 82945G/GZ Integrated Graphics Controller
           Display Server: X.org 1.16.4 drivers: intel (unloaded: fbdev,vesa)
           tty size: 210x65 Advanced Data: N/A for root out of X

When I reboot same PC with framebuffer disabled to emulate OP's boot condition thus,
root=LABEL=deb8jessie plymouth.enable=0 noresume nomodeset
# ls -l /dev/fb*
ls: cannot access /dev/fb*: No such file or directory
the ttys stay in 80x25 mode:
# inxi -c0 -G
Graphics:  Card: Intel 82945G/GZ Integrated Graphics Controller
           Display Server: X.org 1.16.4 drivers: intel (unloaded: fbdev,vesa)
           tty size: 80x25 Advanced Data: N/A for root out of X

I've seen nothing in thread explicitly explaining why he has no /dev/fb0, but
unless and until /dev/fb0 exists, ttys are stuck in 80x25. Maybe that is
something installing a working Plymouth can fix. I don't know, as I never use
Plymouth, and suspect it would also be victim of unsupported hardware.

Even if OP can get the ttys working to his liking, I still think it's very
likely a lost cause trying to use Jessie on his hardware. Stretch is very near
ready to release, and probably OP's better next move.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#180616 — Re: Console fonts

Hello Felix,

Thank you for your informative response to my issue.

My comments in-line below:


On Sun, 30 Apr 2017 21:34:14 -0400, Felix Miata <mrmazda@earthlink.net>
wrote:

>Larry Dighera composed on 2017-04-30 16:40 (UTC-0700):
>[...]
>Previously, in OP https://lists.debian.org/debian-user/2017/04/msg00534.html :
>http://www.udoo.org/
>***
>	Without anything there indicating date of release, that URI strongly suggests
>to me nevertheless that his hardware is newer than Jessie can be expected to
>support.
>

Yes.  It's a new single-board computer platform that began shipping ~April
14, 2017.  I can personally confirm that Tails Linux X11 runs fine on this
platform, and the manufacturer (Udoo) claims to have successfully installed
Debian.  

Specs are here: http://www.udoo.org/new-resources-udoo-x86/
Intel® Celeron® N3160, Quad Core @1.6GHz (Turbo Boost 2.24GHz), 2MB
Cache, 6W TDP.
Integrated Intel® HD Graphics controller
Three independent display support
HW decoding of HEVC(H.265), H.264, MPEG2, MVC, VC-1, VP8, WMV9,
JPEG/MJPEG formats
HW encoding of H.264, MVC and JPEG/MPEG formats
Video Interfaces
HDMI connector
2 x miniDP++ connectors
Video Resolution
Up to 3840 x 2160 24bpp @ 30Hz, 2560 x 1600 24bpp @60Hz
CIR (Consumer InfraRed) Sensor
Arduino 101 compatible shield
Integrated 6-axis combo sensor with accelerometer and gyroscope
------------

Here is data from Debian Jessie on the Udoo X86 platform:

--------------- System Information----------------
Kernel name:	Linux 
Network node Hostname:	UdooX86Debian 
Kernel release:	3.16.0-4-amd64 
Kernel version:	#1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux
Machine hardware name:	 
Operating system:	

------------------- OS Release -------------------
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

 ---------------- CPU Information -----------------
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 76
Model name:            Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz
Stepping:              4
CPU MHz:               499.800
CPU max MHz:           2332.3999
CPU min MHz:           499.8000
BogoMIPS:              3199.86
Virtualization:        VT-x
L1d cache:             24K
L1i cache:             32K
L2 cache:              1024K
NUMA node0 CPU(s):     0-3
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 76
model name	: Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz
stepping	: 4
microcode	: 0x40a
cpu MHz		: 499.800
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand
lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept
vpid tsc_adjust smep erms
bogomips	: 3199.86
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 76
model name	: Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz
stepping	: 4
microcode	: 0x40a
cpu MHz		: 499.800
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 4
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand
lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept
vpid tsc_adjust smep erms
bogomips	: 3199.86
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 2
vendor_id	: GenuineIntel
cpu family	: 6
model		: 76
model name	: Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz
stepping	: 4
microcode	: 0x40a
cpu MHz		: 500.060
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 2
cpu cores	: 4
apicid		: 4
initial apicid	: 4
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand
lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept
vpid tsc_adjust smep erms
bogomips	: 3199.86
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 76
model name	: Intel(R) Celeron(R) CPU  N3160  @ 1.60GHz
stepping	: 4
microcode	: 0x40a
cpu MHz		: 499.800
cache size	: 1024 KB
physical id	: 0
siblings	: 4
core id		: 3
cpu cores	: 4
apicid		: 6
initial apicid	: 6
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand
lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept
vpid tsc_adjust smep erms
bogomips	: 3199.86
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:
---------

>
>GiaThnYgeia later wrote:
>$ inxi -c10 -v3
>Will list basic system info and hardware
>***
>	I found nothing in the archive or on original reading of the thread responding
>to this, but then later I did see OP wrote:
>
>Intel quad-core Celeron N3160
>2.24 GHz & Intel® Quark SE core 32 MHz plus 32-bit ARC core 32 MHz, Intel HD
>Graphics 400 Up to 640 MHz 12 execution units, 4 GB DDR3L Dual Channel RAM
>and 32GB eMMC Storage
>***
>	This supports my suspicion. Later, OP provided logs, which contained:
>
>Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64
>root=UUID=f0748180-a596-4f02-85d8-34b09b57cb42 ro quiet
>(EE) open /dev/dri/card0: No such file or directory
>(EE) open /dev/dri/card0: No such file or directory
>(EE) open /dev/fb0: No such file or directory
>(EE) open /dev/fb0: No such file or directory
>(EE) Screen 0 deleted because of no matching config section.
>(EE) Screen 0 deleted because of no matching config section.
>***
>	These support my suspicion, and explain why his ttys are stuck in 80x25 mode,
>unresponsive to later instruction from David Wright. Lack of /dev/fb0 is a not
>unusual pre-KMS result from a kernel cmdline (from the selected Grub stanza, as
>modified, if modified) that lacks anything telling the kernel not to enable
>framebuffer, resulting in use of 80x25 text mode on the ttys. Since Jessie's
>3.16 kernel does support KMS, his 1920x1080 Samsung SyncMaster display's native
>mode should be picked up by KMS, but that depends on the kernel supporting his
>Intel HD Graphics 400 device. 
>

I'm very impressed with your insight into this issue, and deep understanding
of Debian Jessie, not to mention grateful you have chosen to share your
knowledge.

I don't know when Intel HD Graphics 400 was released, but Tails Linux runs
X11 on the Udoo X86, so apparently there is a Linux driver available.

>Possibly Grub could be reconfigured to make a
>lesser mode like 1440x900 or less explicit. 
>

I'm willing to edit grub, if you're willing to provide specific
instructions.  Unfortunately, my Unix experience predates grub (AT&T Unix
SVR3 ~1994).

>
>Lack of /dev/dri/card0 explains why
>X doesn't work, the kernel found no supported gfx device.
>

It sounds like you've discovered the root cause of the issue.  I failed to
find /dev/dri let alone card0.  I have no idea what this means.

>
>When I boot an Intel video Jessie PC with no video parameters on cmdline,
>root=LABEL=deb8jessie plymouth.enable=0 noresume
>

???

>
>I see kernel messages begin in 80x25 mode, after which the kernel figures out
>the display's native mode and switches to it, resulting in ttys producing 210
>columns by 65 rows.
>

Now we're talking...

>
># inxi -c0 -G
>Graphics:  Card: Intel 82945G/GZ Integrated Graphics Controller
>           Display Server: X.org 1.16.4 drivers: intel (unloaded: fbdev,vesa)
>           tty size: 210x65 Advanced Data: N/A for root out of X
>
>When I reboot same PC with framebuffer disabled to emulate OP's boot condition thus,
>root=LABEL=deb8jessie plymouth.enable=0 noresume nomodeset
># ls -l /dev/fb*
>ls: cannot access /dev/fb*: No such file or directory
>the ttys stay in 80x25 mode:
># inxi -c0 -G
>Graphics:  Card: Intel 82945G/GZ Integrated Graphics Controller
>           Display Server: X.org 1.16.4 drivers: intel (unloaded: fbdev,vesa)
>           tty size: 80x25 Advanced Data: N/A for root out of X
>
>I've seen nothing in thread explicitly explaining why he has no /dev/fb0, but
>unless and until /dev/fb0 exists, ttys are stuck in 80x25. Maybe that is
>something installing a working Plymouth can fix. I don't know, as I never use
>Plymouth, and suspect it would also be victim of unsupported hardware.
>

I did install Plymouth: apt-get install Plymouth.  It didn't seem to make
any noticeable change.  (There are some Plymouth entries in daemon.log and
syslog.)  Subsequently running lightdm still yields a black display screen.

>
>Even if OP can get the ttys working to his liking, I still think it's very
>likely a lost cause trying to use Jessie on his hardware. Stretch is very near
>ready to release, and probably OP's better next move.
>

In this message thread:
http://www.udoo.org/forum/threads/debian-jessie-linux-os-installation.6819/
others have also suggested Stretch.  I looked at the existing bugs:
https://bugs.debian.org/release-critical/other/testing.html
https://bugs.debian.org/release-critical/

Release-critical bugs status

Tue May 2 17:00:00 UTC 2017

Total number of release-critical bugs: 1649
Number that have a patch: 271
Number that have a fix prepared and waiting to upload: 38
Number that are being ignored: 78
Number concerning the current stable release: 699
Number concerning the next release: 149
----

The reason for installing Debian was because I have been impressed with its
stability and few update issues compared to other Linux flavors I've used,
so I was/am reluctant to overwrite Jessie with Stretch.

Given the Udoo team claims to have installed Debian on their hardware, and
Tails Linux runs on it, I'd prefer to sort out the issues, and see if I
(we?) can effect a useable system.

Thank you again for sharing your knowledge, and the time you've spent in
investigating this issue.

Best regards,
Larry

[toc] | [prev] | [next] | [standalone]

#180623 — Re: Console fonts

Larry Dighera composed on 2017-05-02 12:20 (UTC-0700):
...
>>Possibly Grub could be reconfigured to make a
>>lesser mode like 1440x900 or less explicit. 

> I'm willing to edit grub, if you're willing to provide specific
> instructions.  Unfortunately, my Unix experience predates grub (AT&T Unix
> SVR3 ~1994).

In general, this is enough howto:
https://askubuntu.com/questions/19486/how-do-i-add-a-kernel-boot-parameter

When I want 1440x900 as the mode on my Jessie ttys, I append as instructed there:

	video=1440x900@60

The result is that

	# fbset; inxi -G

reports mode 1440x900 using 180 columns and 56 rows. That won't produce a tty
result you can appreciate before your missing /dev/fb0 problem is solved, but is
the manner in which troubleshooting parameters can be supplied to the kernel in
attempting to identify solutions to video (and other) problems.

>>Lack of /dev/dri/card0 explains why
>>X doesn't work, the kernel found no supported gfx device.

> It sounds like you've discovered the root cause of the issue.  I failed to
> find /dev/dri let alone card0.  I have no idea what this means.
Technically, I don't either, but the gist as I understand it is that you have
video hardware that pure Jessie does not support.

DRI is Direct Rendering Infrastructure, just one of a multitude of software bits
that comprise working video on a Linux PC.

>>When I boot an Intel video Jessie PC with no video parameters on cmdline,
>>root=LABEL=deb8jessie plymouth.enable=0 noresume

> ???

That shows the cmdline from that boot included no video parameters other than
one to disable Plymouth functionality.

To find out what video parameters were on your cmdline on current boot, do:

	# cat /proc/cmdline

>>I've seen nothing in thread explicitly explaining why he has no /dev/fb0, but
>>unless and until /dev/fb0 exists, ttys are stuck in 80x25. Maybe that is
>>something installing a working Plymouth can fix. I don't know, as I never use
>>Plymouth, and suspect it would also be victim of unsupported hardware.

> I did install Plymouth: apt-get install Plymouth.  It didn't seem to make
> any noticeable change.  (There are some Plymouth entries in daemon.log and
> syslog.)  Subsequently running lightdm still yields a black display screen.

Since it didn't help, and unless you have reason to think you might want or need
Plymouth in the future, I recommend keeping your Jessie simpler by reversing the
process:

	# apt-get purge plymouth

> Given the Udoo team claims to have installed Debian on their hardware, and
> Tails Linux runs on it, I'd prefer to sort out the issues, and see if I
> (we?) can effect a useable system.
I seriously doubt Udoo's team installed pure Debian Jessie on the hardware you
have. Tails 2.12 uses the same Xorg version as Jessie (1.16.4), but with
approximately the same kernel as Debian Stretch (4.9 vs 4.9.13). This suggests
Jessie might work for you if you enable backports and install a linux-image much
newer than Jessie's 3.16. To enable backports, see:

	https://wiki.debian.org/Backports

Once enabled you can check availability before choosing whether or which to install:

	# apt-cache search linux-image
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#180625 — Re: Console fonts

On Tue 02 May 2017 at 12:20:01 (-0700), Larry Dighera wrote:
> On Sun, 30 Apr 2017 21:34:14 -0400, Felix Miata <mrmazda@earthlink.net> wrote:
> >
> >Even if OP can get the ttys working to his liking, I still think it's very
> >likely a lost cause trying to use Jessie on his hardware. Stretch is very near
> >ready to release, and probably OP's better next move.
> >
> 
> In this message thread:
> http://www.udoo.org/forum/threads/debian-jessie-linux-os-installation.6819/
> others have also suggested Stretch.  I looked at the existing bugs:
> https://bugs.debian.org/release-critical/other/testing.html
> https://bugs.debian.org/release-critical/
> 
> Release-critical bugs status
> 
> Tue May 2 17:00:00 UTC 2017
> 
> Total number of release-critical bugs: 1649
> Number that have a patch: 271
> Number that have a fix prepared and waiting to upload: 38
> Number that are being ignored: 78
> Number concerning the current stable release: 699
> Number concerning the next release: 149
> ----
> 
> The reason for installing Debian was because I have been impressed with its
> stability and few update issues compared to other Linux flavors I've used,
> so I was/am reluctant to overwrite Jessie with Stretch.

Scaling up the words of that ridiculous advert:
699 (stable/jessie) is greater than 149 (testing/stretch).

But, seriously, those figures need a lot of interpreting.

> Given the Udoo team claims to have installed Debian on their hardware, and
> Tails Linux runs on it, I'd prefer to sort out the issues, and see if I
> (we?) can effect a useable system.

Reference? It's worth posting exactly what they installed;
distribution, kernel version, etc.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#180655 — Re: Console fonts

On Tue, 2 May 2017 18:46:34 -0500, David Wright <deblis@lionunicorn.co.uk>
wrote:

>On Tue 02 May 2017 at 12:20:01 (-0700), Larry Dighera wrote:
>> On Sun, 30 Apr 2017 21:34:14 -0400, Felix Miata <mrmazda@earthlink.net> wrote:
>> >
>> >Even if OP can get the ttys working to his liking, I still think it's very
>> >likely a lost cause trying to use Jessie on his hardware. Stretch is very near
>> >ready to release, and probably OP's better next move.
>> >
>> 
>> In this message thread:
>> http://www.udoo.org/forum/threads/debian-jessie-linux-os-installation.6819/
>> others have also suggested Stretch.  I looked at the existing bugs:
>> https://bugs.debian.org/release-critical/other/testing.html
>> https://bugs.debian.org/release-critical/
>> 
>> Release-critical bugs status
>> 
>> Tue May 2 17:00:00 UTC 2017
>> 
>> Total number of release-critical bugs: 1649
>> Number that have a patch: 271
>> Number that have a fix prepared and waiting to upload: 38
>> Number that are being ignored: 78
>> Number concerning the current stable release: 699
>> Number concerning the next release: 149
>> ----
>> 
>> The reason for installing Debian was because I have been impressed with its
>> stability and few update issues compared to other Linux flavors I've used,
>> so I was/am reluctant to overwrite Jessie with Stretch.
>
>Scaling up the words of that ridiculous advert:
>699 (stable/jessie) is greater than 149 (testing/stretch).
>
>But, seriously, those figures need a lot of interpreting.
>

Are you intimating that the current stable Debian release (Jessie) contains
~4.5 times the number of release-critical bugs of stretch!?  

>
>> Given the Udoo team claims to have installed Debian on their hardware, and
>> Tails Linux runs on it, I'd prefer to sort out the issues, and see if I
>> (we?) can effect a useable system.
>
>Reference? It's worth posting exactly what they installed;
>distribution, kernel version, etc.
>

I have submitted that question to the Udoo support team, and am awaiting a
response. 

Also, there is a post here
http://www.udoo.org/forum/threads/debian-jessie-linux-os-installation.6819/#post-26261
that indicates that "Debian Stretch
(debian-stretch-DI-rc3-amd64-xfce-CD-1.iso from
[https://cdimage.debian.org/mirror/cdimage/stretch_di_rc3/amd64/iso-cd/]) is
working much better for me than Jessie..."

>
>Cheers,
>David.

Thank you for your interest in this issue, and your kind support.

Best regards,
Larry

[toc] | [prev] | [next] | [standalone]

#180671 — Re: Console fonts

On Wed 03 May 2017 at 09:31:37 (-0700), Larry Dighera wrote:
> On Tue, 2 May 2017 18:46:34 -0500, David Wright <deblis@lionunicorn.co.uk> wrote:
> >On Tue 02 May 2017 at 12:20:01 (-0700), Larry Dighera wrote:
> >> Release-critical bugs status
> >> 
> >> Tue May 2 17:00:00 UTC 2017
> >> 
> >> Total number of release-critical bugs: 1649
> >> Number that have a patch: 271
> >> Number that have a fix prepared and waiting to upload: 38
> >> Number that are being ignored: 78
> >> Number concerning the current stable release: 699
> >> Number concerning the next release: 149
> >> ----
> >> 
> >> The reason for installing Debian was because I have been impressed with its
> >> stability and few update issues compared to other Linux flavors I've used,
> >> so I was/am reluctant to overwrite Jessie with Stretch.
> >
> >Scaling up the words of that ridiculous advert:
> >699 (stable/jessie) is greater than 149 (testing/stretch).
> >
> >But, seriously, those figures need a lot of interpreting.
> >
> 
> Are you intimating that the current stable Debian release (Jessie) contains
> ~4.5 times the number of release-critical bugs of stretch!?  

That's right…and this ratio will increase until stretch is released.
If you look at the full history graph at
https://bugs.debian.org/release-critical/graph.png
you can see that as any release date approaches, the green line
(testing) falls (developers are squashing bugs in preparation for
release), but the blue line (stable) rises (bugs are still being
found). Security bugs get fixed in stable, but other bugs might
not be. If they get fixed in the upstream version, the status of
stable (it stays the same) prevents their upgrading and may
prevent their inclusion entirely.

Some background on bugs:

https://www.debian.org/Bugs/Developer#severities
https://release.debian.org/testing/rc_policy.txt
https://people.debian.org/~vorlon/rc-bugsquashing.html

> >> Given the Udoo team claims to have installed Debian on their hardware, and
> >> Tails Linux runs on it, I'd prefer to sort out the issues, and see if I
> >> (we?) can effect a useable system.
> >
> >Reference? It's worth posting exactly what they installed;
> >distribution, kernel version, etc.
> >
> 
> I have submitted that question to the Udoo support team, and am awaiting a
> response. 
> 
> Also, there is a post here
> http://www.udoo.org/forum/threads/debian-jessie-linux-os-installation.6819/#post-26261
> that indicates that "Debian Stretch
> (debian-stretch-DI-rc3-amd64-xfce-CD-1.iso from
> [https://cdimage.debian.org/mirror/cdimage/stretch_di_rc3/amd64/iso-cd/]) is
> working much better for me than Jessie..."

Yes, that post was what made me ask. I assume that ♂ is an ordinary
user from their joining date; prolific though. (Nice aeroplane, BTW.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#180626 — Re: Console fonts

On Tue 02 May 2017 at 12:20:01 (-0700), Larry Dighera wrote:

> Yes.  It's a new single-board computer platform that began shipping ~April
> 14, 2017.  I can personally confirm that Tails Linux X11 runs fine on this
> platform, and the manufacturer (Udoo) claims to have successfully installed
> Debian.  
[...]
> Given the Udoo team claims to have installed Debian on their hardware, and
> Tails Linux runs on it, I'd prefer to sort out the issues, and see if I
> (we?) can effect a useable system.

I'm sorry if everyone knows which Debian (jessie, stretch, sid)
and kernel version that the Udoo team installed. My deduction
from the lines above was that the OP ran Tails¹, not that the
Udoo team ran Tails.

Hence my thinking that there might be a reference to what the
Udoo team installed that I (and perhaps others) hadn't seen.
Sorry to mystify anyone.

¹
http://distrowatch.com/table.php?distribution=tails

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#180658 — Re: Console fonts

On Tue, 2 May 2017 20:22:01 -0500, David Wright <deblis@lionunicorn.co.uk>
wrote:

>On Tue 02 May 2017 at 12:20:01 (-0700), Larry Dighera wrote:
>
>> Yes.  It's a new single-board computer platform that began shipping ~April
>> 14, 2017.  I can personally confirm that Tails Linux X11 runs fine on this
>> platform, and the manufacturer (Udoo) claims to have successfully installed
>> Debian.  
>[...]
>> Given the Udoo team claims to have installed Debian on their hardware, and
>> Tails Linux runs on it, I'd prefer to sort out the issues, and see if I
>> (we?) can effect a useable system.
>
>I'm sorry if everyone knows which Debian (jessie, stretch, sid)
>and kernel version that the Udoo team installed. My deduction
>from the lines above was that the OP ran Tails¹, not that the
>Udoo team ran Tails.
>

That is correct.  I apologize for any ambiguity.

>
>Hence my thinking that there might be a reference to what the
>Udoo team installed that I (and perhaps others) hadn't seen.
>Sorry to mystify anyone.
>
>¹
>http://distrowatch.com/table.php?distribution=tails
>
>Cheers,
>David.

While I am currently unable to locate the post asserting the Udoo team
successfully installed Jessie, this post from a Udoo user alludes to a
successful Jessie install:
http://www.udoo.org/forum/threads/no-audio-output-on-linux-over-hdmi.6803/

On the other hands, there is a user also encountering the blank-screen
syndrome with Jessie on the Udoo X86 platform:
http://www.udoo.org/forum/threads/linux-xfce-debian-jessie-blank-screen.6854/

And another who found stretch more stable than Jessie:
http://www.udoo.org/forum/threads/debian-jessie-linux-os-installation.6819/#post-26261

I believe this may have been where I saw the mention of Debian on the Udoo
X86 platform: http://www.udoo.org/docs-x86/Software_&_OS_Distro/Linux.html

When/if I receive a response to my inquiry from the Udoo support team
regarding which Jessie distribution they installed, I'll post it here.

Larry

PS: It is the integrated Arduino hardware and very low power requirement
that make this new platform interesting to me for portable/battery-power
use.  

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web