[Ltsp-discuss] Ubuntu LTSP for RaspBerry2 fails

[Russell Ekerete]

Hi

I have been following UbuntuLTSP/RaspBerryPi guide
(https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi) successfully
since 15.04 but in 16.04 it appears to fail and I am left with a blank /
frozen screen at bootup on the RaspBerry. I have the same result
whether I use Xubuntu or Ubuntu Mate, which as I mentioned worked
previously (I also got Lubuntu and Edubuntu to work previously).

While monitoring the setup process during the stage "Build A Thin
Chroot" (executing the command ltsp-build-client --arch armhf --config
/etc/ltsp/ltsp-build-client-raspi2.conf), I got the following warning:
update-initramfs: Generating /boot/initrd.img-4.4.0-1017-raspi2
warning: root device does not exist
unable to abort; system will probably be broken!

I have not seen any other obvious errors and I am able to complete the
remaining steps of the guide, but the RaspBerry fails to boot. However I
have found that if I replace the current vmlinuz and initrd.img created
from this process, with copies created from a previous working version
of Ubuntu following this guide, the RaspBerry boots fine and I am able
to access the login screen of the Xubuntu Host (one caveat is that I
must comment out the line KERNEL_DEVICE=/dev/mmcblk0p1 in the LTS.conf
file to stop these older files being replaced on the SD with the current
copies).

A quick search on Google reveals at least one other user has had a
similar warning and is currently looking for a fix which leads me to
believe it is not a problem confined to my particular setup so please
can anyone help?

--

Regards,

Russell

[Robert Mavrinac]

All of a sudden I can't login to my LTSP clients (LTSP-PNP)


After a long delay on the LDM login screen, I get the following error on the login screen:


"The authenticity of host '<server ip> (<server ip>)' can't be established. ECDSA fingerprint is <ECDSA_fingerprint>. Are you sure you want to continue connecting"


and shortly afterwards the LDM login screen resets.


How do I resolve this?

[SZABO Zsolt]

On Wed, 3 Aug 2016, Robert Mavrinac wrote:

> All of a sudden I can't login to my LTSP clients (LTSP-PNP)

Did any update/upgrade happen @ltsp-server/dhcp-server?

> After a long delay on the LDM login screen, I get the following error on
> the login screen:
>
> "The authenticity of host '<server ip> (<server ip>)' can't be
> established. ECDSA fingerprint is <ECDSA_fingerprint>. Are you sure you
> want to continue connecting"
>
> and shortly afterwards the LDM login screen resets.
>
> How do I resolve this?

Try to access a shell (e.g. SCREEN_12 = shell in lts.conf and
then C-A-F12 @ltsp-client console),
and try to "ssh <server ip>" or other to figure out where the
authentication method fails...

--
Zs

[Robert Mavrinac]

That's the problem. I can login just fine to the server remotely from any other console, from a shell on the ltsp client, but not from screen 7 on the ltsp client (ldm).


And ltsp-update-sshkeys doesn't really seem to do anything in an ltsp-pnp setup. Where else would it be looking for keys?


As far as updates, none other than usual. I did add another server

________________________________
From: SZABO Zsolt <***@mm.bme.hu>
Sent: August 3, 2016 10:40 AM
To: ltsp-***@lists.sourceforge.net
Subject: Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key error

On Wed, 3 Aug 2016, Robert Mavrinac wrote:

> All of a sudden I can't login to my LTSP clients (LTSP-PNP)

Did any update/upgrade happen @ltsp-server/dhcp-server?

> After a long delay on the LDM login screen, I get the following error on
> the login screen:
>
> "The authenticity of host '<server ip> (<server ip>)' can't be
> established. ECDSA fingerprint is <ECDSA_fingerprint>. Are you sure you
> want to continue connecting"
>
> and shortly afterwards the LDM login screen resets.
>
> How do I resolve this?

Try to access a shell (e.g. SCREEN_12 = shell in lts.conf and
then C-A-F12 @ltsp-client console),
and try to "ssh <server ip>" or other to figure out where the
authentication method fails...

--
Zs

------------------------------------------------------------------------------
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
Ltsp-discuss Info Page - SourceForge<https://lists.sourceforge.net/lists/listinfo/ltsp-discuss>
lists.sourceforge.net
To see the collection of prior postings to the list, visit the Ltsp-discuss Archives. Using Ltsp-discuss: To post a message to all the list members ...


For additional LTSP help, try #ltsp channel on irc.freenode.net

[Robert Mavrinac]

Hmm ... the following is repeatable ...


After booting the ltsp client, if I login using 'ssh server' from screen 1 (shell) on the ltsp-client (creating /root/.ssh/know_hosts with an entry for server), I am immediately able to login to the server from screen 7 (ldm).


If I reboot the same ltsp client, /root/.ssh/know_hosts is of course missing again and I can't login from screen 7 (ldm).



________________________________
From: SZABO Zsolt <***@mm.bme.hu>
Sent: August 3, 2016 10:40 AM
To: ltsp-***@lists.sourceforge.net
Subject: Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key error

On Wed, 3 Aug 2016, Robert Mavrinac wrote:

> All of a sudden I can't login to my LTSP clients (LTSP-PNP)

Did any update/upgrade happen @ltsp-server/dhcp-server?

> After a long delay on the LDM login screen, I get the following error on
> the login screen:
>
> "The authenticity of host '<server ip> (<server ip>)' can't be
> established. ECDSA fingerprint is <ECDSA_fingerprint>. Are you sure you
> want to continue connecting"
>
> and shortly afterwards the LDM login screen resets.
>
> How do I resolve this?

Try to access a shell (e.g. SCREEN_12 = shell in lts.conf and
then C-A-F12 @ltsp-client console),
and try to "ssh <server ip>" or other to figure out where the
authentication method fails...

--
Zs

[Robert Mavrinac]

Just to clarify, I login at the shell as 'root' in screen 1, and as a regular unprivileged user on screen 7.

[SZABO Zsolt]

On Wed, 3 Aug 2016, Robert Mavrinac wrote:

> Just to clarify, I login at the shell as 'root' in screen 1, and as a
> regular unprivileged user on screen 7.

Hmm... I know this :-)

Are there any messages about some ssh keys when logging in from screen 1?

Check the folder /root/.ssh... before and after the login.

I guess, that the ssh_known_hosts are incorrect in the folder /etc/ssh .

If so then scp the appropriate file from /root/.ssh/ to the server
and add the relevant keys from that to the appropriate file in
${ltsp-chroot}/etc/ssh/...

(Maybe the ltsp-update-sshkeys script did not run or you have some special
setup and it messed the keys up...)

Zs
--
# Just because they are called 'forbidden' transitions does not mean that they
# are forbidden. They are less allowed than allowed transitions, if you see
# what I mean.
# -- From a Part 2 Quantum Mechanics lecture.

[Robert Mavrinac]

I think I just found the work-around.


Since this is an ltsp-pnp setup, I ran

ltsp-update-sshkeys -u server_name

on each application server, which by default creates /etc/ltsp/ssh_known_hosts.auto.


I've run into issues in the past over hostname versus ip address in known_hosts, so I made sure each key begins with server_name,server_ip_address not just the server_name

sed -i '/^server_name/server_name,server_ip_address/g' /etc/ltsp/ssh_known_hosts.auto

ltsp-update-image --cleanup /

After rebooting the ltsp client again, everything seems good now on both servers!


________________________________
From: SZABO Zsolt <***@mm.bme.hu>
Sent: August 3, 2016 1:40 PM
To: ltsp-***@lists.sourceforge.net
Subject: Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key error

On Wed, 3 Aug 2016, Robert Mavrinac wrote:

> Just to clarify, I login at the shell as 'root' in screen 1, and as a
> regular unprivileged user on screen 7.

Hmm... I know this :-)

Are there any messages about some ssh keys when logging in from screen 1?

Check the folder /root/.ssh... before and after the login.

I guess, that the ssh_known_hosts are incorrect in the folder /etc/ssh .

If so then scp the appropriate file from /root/.ssh/ to the server
and add the relevant keys from that to the appropriate file in
${ltsp-chroot}/etc/ssh/...

(Maybe the ltsp-update-sshkeys script did not run or you have some special
setup and it messed the keys up...)

Zs
--
# Just because they are called 'forbidden' transitions does not mean that they
# are forbidden. They are less allowed than allowed transitions, if you see
# what I mean.
# -- From a Part 2 Quantum Mechanics lecture.

[Valtteri Suojanen]

Hi

yes. with two application (desktop ) servers.

ltsp-update-sshkeys -u srvname1...
ltsp-update-sshkeys
ltsp-update-image

Updating keys in network with two ltsp servers and both application servers
got me thinking. I am just curious is (or how it is) in your setup ltsp
network configured with two ltsp-pnp perhaps as the defaults and in same
network? In that case you would have to manage the servers separately in
the dnsmasq dhcp configurations also and having two dhcp servers in simple
ltsp-pnp network is in my opinion not optimal for just 1-2 DE's or app
servers maintenance, especially when adding clients in such network .
Maybe I just did not now understand the setup... and apologize if messing
up too much.

In case you need to discuss about the setup in general there are some
professionals and current developers also online in #ltsp .

3.8.2016 21.29 "Robert Mavrinac" <***@uwindsor.ca> kirjoitti:

> I think I just found the work-around.
>
>
> Since this is an ltsp-pnp setup, I ran
>
> ltsp-update-sshkeys -u server_name
>
> on each application server, which by default creates
> /etc/ltsp/ssh_known_hosts.auto.
>
>
> I've run into issues in the past over hostname versus ip address in
> known_hosts, so I made sure each key begins with
> server_name,server_ip_address not just the server_name
>
> sed -i '/^server_name/server_name,server_ip_address/g' /
> etc/ltsp/ssh_known_hosts.auto
>
> ltsp-update-image --cleanup /
>
> After rebooting the ltsp client again, everything seems good now on both
> servers!
>
>
>
> ------------------------------
> *From:* SZABO Zsolt <***@mm.bme.hu>
> *Sent:* August 3, 2016 1:40 PM
> *To:* ltsp-***@lists.sourceforge.net
> *Subject:* Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key
> error
>
> On Wed, 3 Aug 2016, Robert Mavrinac wrote:
>
> > Just to clarify, I login at the shell as 'root' in screen 1, and as a
> > regular unprivileged user on screen 7.
>
> Hmm... I know this :-)
>
> Are there any messages about some ssh keys when logging in from screen 1?
>
> Check the folder /root/.ssh... before and after the login.
>
> I guess, that the ssh_known_hosts are incorrect in the folder /etc/ssh .
>
> If so then scp the appropriate file from /root/.ssh/ to the server
> and add the relevant keys from that to the appropriate file in
> ${ltsp-chroot}/etc/ssh/...
>
> (Maybe the ltsp-update-sshkeys script did not run or you have some special
> setup and it messed the keys up...)
>
> Zs
> --
> # Just because they are called 'forbidden' transitions does not mean that
> they
> # are forbidden. They are less allowed than allowed transitions, if you
> see
> # what I mean.
> # -- From a Part 2 Quantum Mechanics lecture.
>
>
> ------------------------------------------------------------------------------
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.freenode.net
>
>
> ------------------------------------------------------------------------------
>
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.freenode.net
>
>

[Robert Mavrinac]

Actually I had as many as 5 servers. I'm in the process of upgrading 32-bit servers to 64-bit because we had only 32-bit thin clients. These are all 64-bit now, so the servers all need to be migrated as well.

I used to use ltsp-cluster. Since that doesn't work with ltsp-pnp, I now use ipxe boot menus to boot the clients and load-balancing the servers. All the clients boot using HTTP, not TFTP for their final image. I have one tftp boot server/dhcp server to load the first menu. When the ltsp option is chosen, the least loaded server is chosen.

The first server was upgraded from 32-bit to 64-bit Debian Jessie - not simple or really supported, but not impossible. The second server was created with a bare-bones install and an RCP restore of the first server. I may have missed reconfiguring one of the files for the new server, which is when the SSH key problems started. Now that's resolved. The next upgrades should go without any problems.

As a side note, I had posted earlier about a VMWare View kiosk. My solution for that was to recreate a separate screen and session file for View. Now we have a browser kiosk on screen 3, a vmware view kiosk on screen 5 and the usual ldm login on screen 7. I'll have to post those files later.

--

Robert Mavrinac
Server & Network Technician
School of Computer Science
Room 3104 Lambton Tower
University of Windsor
401 Sunset Avenue, Windsor, ON N9B 3P4
519-253-3000 (4410)
Email: ***@uwindsor.ca
________________________________
From: Valtteri Suojanen <***@gmail.com>
Sent: August 3, 2016 3:38:28 PM
To: ltsp-***@lists.sourceforge.net
Subject: Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key error


Hi

yes. with two application (desktop ) servers.

ltsp-update-sshkeys -u srvname1...
ltsp-update-sshkeys
ltsp-update-image

Updating keys in network with two ltsp servers and both application servers got me thinking. I am just curious is (or how it is) in your setup ltsp network configured with two ltsp-pnp perhaps as the defaults and in same network? In that case you would have to manage the servers separately in the dnsmasq dhcp configurations also and having two dhcp servers in simple ltsp-pnp network is in my opinion not optimal for just 1-2 DE's or app servers maintenance, especially when adding clients in such network . Maybe I just did not now understand the setup... and apologize if messing up too much.

In case you need to discuss about the setup in general there are some professionals and current developers also online in #ltsp .

3.8.2016 21.29 "Robert Mavrinac" <***@uwindsor.ca<mailto:***@uwindsor.ca>> kirjoitti:

I think I just found the work-around.


Since this is an ltsp-pnp setup, I ran

ltsp-update-sshkeys -u server_name

on each application server, which by default creates /etc/ltsp/ssh_known_hosts.auto.


I've run into issues in the past over hostname versus ip address in known_hosts, so I made sure each key begins with server_name,server_ip_address not just the server_name

sed -i '/^server_name/server_name,server_ip_address/g' /etc/ltsp/ssh_known_hosts.auto

ltsp-update-image --cleanup /

After rebooting the ltsp client again, everything seems good now on both servers!


________________________________
From: SZABO Zsolt <***@mm.bme.hu<mailto:***@mm.bme.hu>>
Sent: August 3, 2016 1:40 PM
To: ltsp-***@lists.sourceforge.net<mailto:ltsp-***@lists.sourceforge.net>
Subject: Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key error

On Wed, 3 Aug 2016, Robert Mavrinac wrote:

> Just to clarify, I login at the shell as 'root' in screen 1, and as a
> regular unprivileged user on screen 7.

Hmm... I know this :-)

Are there any messages about some ssh keys when logging in from screen 1?

Check the folder /root/.ssh... before and after the login.

I guess, that the ssh_known_hosts are incorrect in the folder /etc/ssh .

If so then scp the appropriate file from /root/.ssh/ to the server
and add the relevant keys from that to the appropriate file in
${ltsp-chroot}/etc/ssh/...

(Maybe the ltsp-update-sshkeys script did not run or you have some special
setup and it messed the keys up...)

Zs
--
# Just because they are called 'forbidden' transitions does not mean that they
# are forbidden. They are less allowed than allowed transitions, if you see
# what I mean.
# -- From a Part 2 Quantum Mechanics lecture.

------------------------------------------------------------------------------
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net<http://irc.freenode.net>

[Valtteri Suojanen]

ok, I just thought it would be good to check also some short description of
the setup. you seem to have eveything supported for two application
servers

4.8.2016 3.05 "Robert Mavrinac" <***@uwindsor.ca> kirjoitti:

> Actually I had as many as 5 servers. I'm in the process of upgrading
> 32-bit servers to 64-bit because we had only 32-bit thin clients. These are
> all 64-bit now, so the servers all need to be migrated as well.
>
> I used to use ltsp-cluster. Since that doesn't work with ltsp-pnp, I now
> use ipxe boot menus to boot the clients and load-balancing the servers. All
> the clients boot using HTTP, not TFTP for their final image. I have one
> tftp boot server/dhcp server to load the first menu. When the ltsp option
> is chosen, the least loaded server is chosen.
>
> The first server was upgraded from 32-bit to 64-bit Debian Jessie - not
> simple or really supported, but not impossible. The second server was
> created with a bare-bones install and an RCP restore of the first server. I
> may have missed reconfiguring one of the files for the new server, which is
> when the SSH key problems started. Now that's resolved. The next upgrades
> should go without any problems.
>
> As a side note, I had posted earlier about a VMWare View kiosk. My
> solution for that was to recreate a separate screen and session file for
> View. Now we have a browser kiosk on screen 3, a vmware view kiosk on
> screen 5 and the usual ldm login on screen 7. I'll have to post those files
> later.
>
> --
>
> Robert Mavrinac
> Server & Network Technician
> School of Computer Science
> Room 3104 Lambton Tower
> University of Windsor
> 401 Sunset Avenue, Windsor, ON N9B 3P4
> 519-253-3000 (4410)
> Email: ***@uwindsor.ca
> ------------------------------
> *From:* Valtteri Suojanen <***@gmail.com>
> *Sent:* August 3, 2016 3:38:28 PM
> *To:* ltsp-***@lists.sourceforge.net
> *Subject:* Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key
> error
>
>
> Hi
>
> yes. with two application (desktop ) servers.
>
> ltsp-update-sshkeys -u srvname1...
> ltsp-update-sshkeys
> ltsp-update-image
>
> Updating keys in network with two ltsp servers and both application
> servers got me thinking. I am just curious is (or how it is) in your setup
> ltsp network configured with two ltsp-pnp perhaps as the defaults and in
> same network? In that case you would have to manage the servers separately
> in the dnsmasq dhcp configurations also and having two dhcp servers in
> simple ltsp-pnp network is in my opinion not optimal for just 1-2 DE's or
> app servers maintenance, especially when adding clients in such network .
> Maybe I just did not now understand the setup... and apologize if messing
> up too much.
>
> In case you need to discuss about the setup in general there are some
> professionals and current developers also online in #ltsp .
>
> 3.8.2016 21.29 "Robert Mavrinac" <***@uwindsor.ca> kirjoitti:
>
>> I think I just found the work-around.
>>
>>
>> Since this is an ltsp-pnp setup, I ran
>>
>> ltsp-update-sshkeys -u server_name
>>
>> on each application server, which by default creates
>> /etc/ltsp/ssh_known_hosts.auto.
>>
>>
>> I've run into issues in the past over hostname versus ip address in
>> known_hosts, so I made sure each key begins with
>> server_name,server_ip_address not just the server_name
>>
>> sed -i '/^server_name/server_name,server_ip_address/g' /
>> etc/ltsp/ssh_known_hosts.auto
>>
>> ltsp-update-image --cleanup /
>>
>> After rebooting the ltsp client again, everything seems good now on both
>> servers!
>>
>>
>>
>> ------------------------------
>> *From:* SZABO Zsolt <***@mm.bme.hu>
>> *Sent:* August 3, 2016 1:40 PM
>> *To:* ltsp-***@lists.sourceforge.net
>> *Subject:* Re: [Ltsp-discuss] Can't login on LTSP client due to SSH key
>> error
>>
>> On Wed, 3 Aug 2016, Robert Mavrinac wrote:
>>
>> > Just to clarify, I login at the shell as 'root' in screen 1, and as a
>> > regular unprivileged user on screen 7.
>>
>> Hmm... I know this :-)
>>
>> Are there any messages about some ssh keys when logging in from screen 1?
>>
>> Check the folder /root/.ssh... before and after the login.
>>
>> I guess, that the ssh_known_hosts are incorrect in the folder /etc/ssh .
>>
>> If so then scp the appropriate file from /root/.ssh/ to the server
>> and add the relevant keys from that to the appropriate file in
>> ${ltsp-chroot}/etc/ssh/...
>>
>> (Maybe the ltsp-update-sshkeys script did not run or you have some
>> special
>> setup and it messed the keys up...)
>>
>> Zs
>> --
>> # Just because they are called 'forbidden' transitions does not mean that
>> they
>> # are forbidden. They are less allowed than allowed transitions, if you
>> see
>> # what I mean.
>> # -- From a Part 2 Quantum Mechanics lecture.
>>
>>
>> ------------------------------------------------------------------------------
>> _____________________________________________________________________
>> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
>> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
>> For additional LTSP help, try #ltsp channel on irc.freenode.net
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _____________________________________________________________________
>> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
>> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
>> For additional LTSP help, try #ltsp channel on irc.freenode.net
>>
>>
>
> ------------------------------------------------------------------------------
>
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.freenode.net
>
>

[Valtteri Suojanen]

Hello,

there was mentioned that added another server (is this just new desktop for
clients on the network and your clients boot from perhaps old server?). If
you have two ltsp servers check which one of them is serving the client
image for the clients you have trouble with login and update on that server
the client ssh keys issuing that ltsp package server tool

1. ltsp-update-sshkeys -u server1
2. ltsp-update-sshkeys

the first one will create server public key(s) for clients and the latter
will copy/ update these keys to your clients. it's in the manual

if this is not helping... all you should need is issuing on the right
server (where you create and update the ltsp client image) the tool
ltsp-update-sshkeys similarly as I described. just run the tool in the
right server and give it the right ldm server hostname(s).

Valtteri

3.8.2016 20.42 "SZABO Zsolt" <***@mm.bme.hu> kirjoitti:

> On Wed, 3 Aug 2016, Robert Mavrinac wrote:
>
> > Just to clarify, I login at the shell as 'root' in screen 1, and as a
> > regular unprivileged user on screen 7.
>
> Hmm... I know this :-)
>
> Are there any messages about some ssh keys when logging in from screen 1?
>
> Check the folder /root/.ssh... before and after the login.
>
> I guess, that the ssh_known_hosts are incorrect in the folder /etc/ssh .
>
> If so then scp the appropriate file from /root/.ssh/ to the server
> and add the relevant keys from that to the appropriate file in
> ${ltsp-chroot}/etc/ssh/...
>
> (Maybe the ltsp-update-sshkeys script did not run or you have some special
> setup and it messed the keys up...)
>
> Zs
> --
> # Just because they are called 'forbidden' transitions does not mean that
> they
> # are forbidden. They are less allowed than allowed transitions, if you
> see
> # what I mean.
> # -- From a Part 2 Quantum Mechanics lecture.
>
>
> ------------------------------------------------------------------------------
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.freenode.net
>

[Russell Ekerete]

I have repeated the entire setup process from scratch but this time
piped the results of the command ltsp-build-client --arch armhf --config
/etc/ltsp/ltsp-build-client-raspi2.conf to a log file. Here is where
things go wrong:

Preparing to unpack .../linux-image-raspi2_4.4.0.1017.17_armhf.deb ...
Unpacking linux-image-raspi2 (4.4.0.1017.17) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up linux-image-4.4.0-1017-raspi2 (4.4.0-1017.23) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal
4.4.0-1017-raspi2 /boot/vmlinuz-4.4.0-1017-raspi2
run-parts: executing /etc/kernel/postinst.d/initramfs-tools
4.4.0-1017-raspi2 /boot/vmlinuz-4.4.0-1017-raspi2
update-initramfs: Generating /boot/initrd.img-4.4.0-1017-raspi2
Warning: root device does not exist

Unable to abort; system will probably be broken!
run-parts: executing /etc/kernel/postinst.d/ltsp-update-kernels
4.4.0-1017-raspi2 /boot/vmlinuz-4.4.0-1017-raspi2
Setting up dosfstools (3.0.28-2ubuntu0.1) ...

Regards,

Russell

On 03/08/2016 11:50, Russell Ekerete wrote:
> Hi
>
> I have been following UbuntuLTSP/RaspBerryPi guide
> (https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi)
> successfully since 15.04 but in 16.04 it appears to fail and I am left
> with a blank / frozen screen at bootup on the RaspBerry. I have the
> same result whether I use Xubuntu or Ubuntu Mate, which as I mentioned
> worked previously (I also got Lubuntu and Edubuntu to work previously).
>
> While monitoring the setup process during the stage "Build A Thin
> Chroot" (executing the command ltsp-build-client --arch armhf --config
> /etc/ltsp/ltsp-build-client-raspi2.conf), I got the following warning:
> update-initramfs: Generating /boot/initrd.img-4.4.0-1017-raspi2
> warning: root device does not exist
> unable to abort; system will probably be broken!
>
> I have not seen any other obvious errors and I am able to complete the
> remaining steps of the guide, but the RaspBerry fails to boot.
> However I have found that if I replace the current vmlinuz and
> initrd.img created from this process, with copies created from a
> previous working version of Ubuntu following this guide, the RaspBerry
> boots fine and I am able to access the login screen of the Xubuntu
> Host (one caveat is that I must comment out the line
> KERNEL_DEVICE=/dev/mmcblk0p1 in the LTS.conf file to stop these older
> files being replaced on the SD with the current copies).
>
> A quick search on Google reveals at least one other user has had a
> similar warning and is currently looking for a fix which leads me to
> believe it is not a problem confined to my particular setup so please
> can anyone help?
> --
>
> Regards,
>
> Russell

[Alkis Georgopoulos]

Hi, I developed the necessary parts in LTSP and I wrote
https://help.ubuntu.com/community/UbuntuLTSP/RaspberryPi and I verified
that it was working fine with Ubuntu 16.04 when it was in its very early
stages of the release cycle.

Unfortunately I no longer get any funding to work on LTSP, so I'm only
doing high priority or sponsored tasks for the moment, or offer
professional support.
That also means that this page hasn't been updated to work with the
final version of 16.04. It shouldn't need more than a couple of hours to
get it up to date.

Cheers,
Alkis Georgopoulos
LTSP developer

[Borders, Travis]

I recently encountered the same problem when I transplanted an image from
one server to another. The solution was to chroot into my image and accept
the unknown ECDSA value by ssh'ing to the server IP. To be thorough I
performed an ssh to the hostname, FQDN, and the IP and typed yes to accept
the ECDSA in each case. So ssh server, ssh server.domain, and ssh X.X.X.X
substituting the names and IP's of the server you are unable to connect to.

--
Travis Borders
***@woodlandschools.org
Assistant Programmer/Web Developer
Woodland School District

[Robert Mavrinac]

This may seem like overkill, but I wanted two kiosks to be available on our ltsp clients on different screens, one for a web browser kiosk, another for a vmware view kiosk. The vmware view account is also required to be a member of audio, pulse and pulse-access. We're using the VMWare Horizon View client (VMware-Horizon-Client-3.5.0-2999900.x64.bundle) supporting PCOIP and USB redirection - there may be some library dependencies to be installed and at least one library soft link to create.



Add the following three (3) files to the LTSP server (they were copied from /usr/share/ltsp/screen.d/kiosk and /usr/share/ltsp/kioskSession, respectively:



(1) /etc/ltsp/screen.d/vmware-view:

* All VIEW* environment variables can set in /var/lib/tftpboot/lts.conf.

* Added VIEW_MESSAGE for echoing a "Please wait"
* Add qoutes around the gecos data ,,, in the adduser line - it may work in the script, but it doesn't always work from the command line.
* Add $VIEW_USER to the audio, pulse and pulse-access groups.
* Escaped quotation marks were added to pass VIEW_OPTIONS for su statement in vmware-view (and the eval in vmware-view-Session) to work properly

#--- begin /etc/ltsp/screen.d/vmware-view
#!/bin/sh
#
# The following script works for LTSP5.
#
# This software is licensed under the Gnu General Public License.
# The full text of which can be found at http://www.LTSP.org/license.txt
#
#
# To customize the vmware-view session, you can add "homedir" files
# to $chroot/usr/local/share/ltspview/home/
# AND to add startup scripts that run as the user, you can add
# them as executables or symlinks to executables in:
# $chroot/usr/local/share/ltspview/startup

PATH=/bin:$PATH; export PATH
. /usr/share/ltsp/screen-x-common

[ -n "$1" ] && VIEW_EXE=$1
[ -n "$2" ] && VIEW_OPTIONS=$2

if [ -z "${VIEW_EXE}" ]; then
if [ -x "/usr/bin/vmware-view" ]; then
VIEW_EXE=/usr/bin/vmware-view
else
VIEW_EXE=unknown
fi
fi

if boolean_is_true "${VIEW_DAEMON:-"False"}"; then
export XINITRC_DAEMON="True"
fi

xinitrc=/usr/share/ltsp/xinitrc

echo ${VIEW_MESSAGE}
sleep 5

VIEW_USER=${VIEW_USER:-"ltspview"}
if [ -z "$(getent passwd ${VIEW_USER})" ]; then
# create a ltspview user
adduser --no-create-home --disabled-password --gecos ",,," ${VIEW_USER}
adduser ltspview audio
adduser ltspview pulse
adduser ltspview pulse-access
fi

# Create a tmpdir to be our homedir
TMPDIR=$(mktemp -d /tmp/.view-XXXXXX)
chown ${VIEW_USER} ${TMPDIR}

# Edit passwd homedir entry for programs that look it up from there
sed -i -e '\|'${VIEW_USER}'|s|[^:]*\(:[^:]*\)$|'$TMPDIR'\1|' /etc/passwd

su - ${VIEW_USER} -c "XINITRC_DAEMON=${XINITRC_DAEMON} VIEW_WM=${VIEW_WM} VIEW_OPTIONS=\"${VIEW_OPTIONS}\" xinit $xinitrc /etc/ltsp/vmware-view-Session ${VIEW_EXE} -- ${DISPLAY} vt${TTY} -nolisten tcp ${X_ARGS} -br" >/dev/null

rm -rf ${TMPDIR}
#--- end /etc/ltsp/screen.d/vmware-view


(2) /etc/ltsp/vmware-view-Session:


#--- begin /etc/ltsp/vmware-view-Session
#!/bin/sh


VIEW_EXE=$1
VIEW_HOME=/usr/local/share/ltspview/home
VIEW_STARTUP=/usr/local/share/ltspview/startup

VIEW_USER=${VIEW_USER:-"ltspview"}
VIEW_WM=${VIEW_WM:-"/usr/bin/metacity"}
VIEW_USER_STARTUP="${HOME}/.view-startup"

mkdir -p ${VIEW_USER_STARTUP}

if [ -x "${VIEW_WM}" ]; then
ln -s ${VIEW_WM} ${VIEW_USER_STARTUP}/00-view-wm
fi

# Copy a default homedir if present
if [ -d "${VIEW_HOME}" ]; then
cp -r ${VIEW_HOME}/* ${VIEW_HOME}/.??* ${HOME}
fi

for file in ${VIEW_STARTUP}/* ; do
if [ -f "${file}" ]; then
ln -s "${file}" "${VIEW_USER_STARTUP}/$(basename ${file})"
fi
done

[ -n "${XAUTHORITY}" ] && cp -a ${XAUTHORITY} ${HOME}

for i in ${VIEW_USER_STARTUP}/* ; do
[ -x "${i}" ] && eval "${i}" &
done

if [ "${VIEW_EXE}" = "unknown" ]; then
ldm-dialog --message "No program found."
else
eval ${VIEW_EXE} ${VIEW_OPTIONS} || ldm-dialog --message "Could not start program."
fi

[ "$USER" != "root" ] && pkill -u $USER
exit 0
#--- end /etc/ltsp/vmware-view-Session


(3) /etc/vmware/view-default-config:


#--- end /etc/vmware/view-default-configview.defaultBroker="YOUR_HORIZON_VIEW_SERVER_FQDN"
view.sslVerificationMode="2"
view.defaultDesktopSize="2"
view.defaultProtocol="PCOIP"
view.defaultDomain="YOUR_DOMAIN"
viewusb.includeFamily="bluetooth;hid;other;physical;storage;unknown;vendor;wireless;wusb"

(You may want to reduce the usb device families included - these work for our purposes, which includes Windows-based robotics programming)



Add these lines to the top of lts.conf:

SCREEN_05=vmware-view
VIEW_EXE=/usr/bin/vmware-view
VIEW_OPTIONS="--fullscreen --once --nomenubar -q"
VIEW_MESSAGE="\nPlease wait up to 30 seconds for the VMWare Horizon View clien