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


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

Jessie for Udoo X86?

Started byLarry Dighera <LDighera@att.net>
First post2017-04-17 06:30 +0200
Last post2017-04-24 14:40 +0200
Articles 7 on this page of 27 — 7 participants

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 2 of 2 — ← Prev page 1 [2]


#180662 — Re: Console fonts

FromFelix Miata <mrmazda@earthlink.net>
Date2017-05-03 22:20 +0200
SubjectRe: Console fonts
Message-ID<tD8UF-1LK-5@gated-at.bofh.it>
In reply to#180658
Larry Dighera composed on 2017-05-03 10:08 (UTC-0700):
...
> 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

Quoting from there:

"Heads up! The processors of the UDOO X86 and the Wi-Fi/BT module are released
only few time ago so we suggest to use a recent distribution to find all the
latest drivers already installed and have all the devices operating properly."

Originally released ~24 months ago, Jessie is the oldest most recent "stable"
release among the top 25 in Distrowatch's page hit ranking.
-- 
"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]


#180672 — Re: Console fonts

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2017-05-04 02:40 +0200
SubjectRe: Console fonts
Message-ID<tDcYh-4mS-7@gated-at.bofh.it>
In reply to#180658
On Wed 03 May 2017 at 10:08:42 (-0700), Larry Dighera wrote:
> 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.

No blame intended. I received a private email to which this was a
general reply. The ambiguity is elsewhere.

> 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.  

I'm just watching this to see if it's a cheap way of getting some
up-to-date hardware now I've stopped moving house for a while.
While jessie has delivered some new functionality on my old hardware
(but also lost some), it hasn't delivered any appreciable speed gain.

Cheers,
David.

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


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

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2017-05-01 18:30 +0200
SubjectRe: Console fonts, was Re: Jessie for Udoo X86?
Message-ID<tCmn0-2Xx-19@gated-at.bofh.it>
In reply to#180560
On Sun 30 Apr 2017 at 16:40:49 (-0700), Larry Dighera wrote:
> 
> 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 think the cause may be explained in the earlier reply to this post.
I've not really played with the framebuffer specifications.

> 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.

As it says, these variables can only reduce the width used by default,
not increase it. I've never used them. I just set the fontsize and
then record the resulting size with COLUMNS/LINES for future reference.

> 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.

That may be the case.

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

If you're editing that file to make changes, then yes. But I
don't like using setupcon because I usually have an X server running,
which can interfere with things. (I might be maligning it; it could
be keyboard changes which interfere, I don't remember.)

> 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.

That's why I posted my-font-usr-share-consolefonts which gives
the location of the possible files you can use. Just look through
/usr/share/consolefonts/

> 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.
> >
> 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.

         ↑↑↑↑↑↑↑ do you mean setupcon <variant> where variant would be
small in your example. I used to use this method IIRC but you end up
with all the VCs the same, whereas with setfont you can have different
VCs with a larger font for editing, say, and a smaller font for
displaying more of files with unwrapped long lines.

Cheers,
David.

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


#180422

FromLarry Dighera <LDighera@att.net>
Date2017-04-23 21:40 +0200
Message-ID<tzvwt-4fK-13@gated-at.bofh.it>
In reply to#180240
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]


#180425

FromGiaThnYgeia <GiaThnYgeia@openmailbox.org>
Date2017-04-24 00:20 +0200
Message-ID<tzy1k-6dI-7@gated-at.bofh.it>
In reply to#180422
Larry Dighera:
> 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 don't have an appropriate answer but if you have a fast i/net
connection you may want to remove lightdm or whatever desktop and
display manager you have installed and that will leave the system login
in the command line.  $ apt remove lightdm   will probably do it.

$ inxi -c10 -v3
Will list basic system info and hardware

$ lshw
will list more hardware details

$ more /var/log/Xorg.*.log*

Will tell you the what the logs were like for when X11 tried to come up
but run into problems.


> 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.

I know, sometimes I get that on stretch but on jessie it seems to be
working better.  The prompt where it tells you to hit CtrlD or enter the
root password sometimes doesn't show up.  So when you see the screen
stop rolling hit return and it clears up.

You then have to research online to see if there is firmware that
relates to the hardware that is causing the problem.  It might exist in
the contrib or non-free repositories.  To add them you edit (I use nano)
root$ nano /etc/apt/sources.list  and add at the end of the lines where
it says main contrib non-free   This makes apt look into the three
directories of that repository.  With nano once you edit hit Ctrl-O to
save or Ctrl-X to exit where it prompts you to save and you say yes if
you are sure of the editing.

Let's say the firmware missing is in misc-firmware-non-free
root$ apt install misc-firmware-non-free

If you find somewhere else a package in ***.deb format you use dpkg to
install it after you download it.

Keep us up to date

Larry Dighera:
> 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.
> 
> 

-- 
 "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]


#180427

Fromsongbird <songbird@anthive.com>
Date2017-04-24 01:50 +0200
Message-ID<tzzqp-74c-1@gated-at.bofh.it>
In reply to#180422
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.

  hope so!  also check the session logs in lightdm...


> 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?  

  install the base system to start and then add the
next layers after.

  lightdm by default should not take you any further
than the lightdm greeter login screen without you
adjusting the configuration files.

  is there some reason not to give the current 
testing images for the installer a try?  it may
have better support for newer hardware.


> 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.

  the keyword being "new" there makes me go "hmm..."  :)

  [i have no idea what a Udoo is...]


  songbird

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


#180446

FromGreg Wooledge <wooledg@eeg.ccf.org>
Date2017-04-24 14:40 +0200
Message-ID<tzLrA-6Zn-15@gated-at.bofh.it>
In reply to#180422
On Sun, Apr 23, 2017 at 12:37:10PM -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.

As I said last week, the prompt IS displayed, but the kernel messages
from subsystems that are still being initialized may appear after it.
Thus, the prompt may be well hidden in the middle of unrelated output.

> 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?  

There are multiple ways to do it, depending on which version of Debian
this is.  Some people favor one way over another.

Removing the display manager pacakge will definitely work.  If the
display manager does not exist, it can't be run.

Disabling the display manager service MAY work, depending on which init
system is in play.  If it's sysvinit, then removing the symlink from
/etc/rc2.d (or whatever your system's default run level is) should do it.
If it's systemd, then "systemctl disable whatever" may work, but I have
heard conflicting reports about this.

If it's systemd, another way is to change the default "target" (analogous
to run level).  Debian with systemd has adopted the old Red Hat convention
of having separate targets for "boot with a display manager" versus
"boot with all multi-user services except the display manager", and the
default is the one that includes the display manager.

To see the default target:

  $ systemctl get-default

To change the default target:

  # systemctl set-default multi-user.target

Here, "graphical.target" is the name of the one that includes the DM,
and "multi-user.target" is the one that does not.

Finally, I'm told there is a way to specify the target from the GRUB
menu as a kernel parameter, though I have never tried it myself:

https://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/s1-grub-targets.html

Of course this is a one-shot thing, not a permanent change to your boot
processes.

[toc] | [prev] | [standalone]


Page 2 of 2 — ← Prev page 1 [2]

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


csiph-web