dCore-xenial missing libraries

[sm8ps]

I spent two thirds of last night hitting one road block after the other while trying to run dCore-xenial on a Motion M1400 machine. Xorg is not running well (Intel 885GM graphics card) because it claims to not find the i915 driver. What is worse is that I do not even get to trouble shooting. I want to have openssh-server running but this does not seem to work either.
I gave up over the following: running ''ps aux'' returns an "error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory".
I have tested the latest release candidate (21-Dec-2016 21:52) from the ISO-build as well as the latest stable release (20-Oct-2016 00:27). The MD5 sum is verified for the stable release. The only extensions are xorg-all, graphics-4.2.9-tinycore and openssh-server; everything else is a clean installation. Anybody having a clue?
Thanks and have a peaceful time!
sm

[sm8ps]

I definitely need some advice if not help! I do not seem to understand something very basic. Here is what I did for a test on the machine with my regular dCore-trusty installation on hard-disk (sda5).
. downloaded dCore-xenial.iso (stable, 20-Oct-2016 00:27) and dd'ed it to a USB-stick (sdc)
. reboot from the USB-stick with boot stanza "initrd=/boot/dCorexenial.gz quiet loglevel=3 nozswap rd.udev.log-priority=0 cde BOOT_IMAGE=/boot/vmlinuzxenial showapps", as retrieved from '/proc/cmdline'

I expected to get a minimal dCore-xenial system without any apps. Yet the boot process started loading the apps in sceboot.lst from the regular installation (sda5)! So somehow the tce-directory on the hard-disk got recognized which should not be the case, AFAICT.

I do not see what mechanism could possibly trigger such behavior. The boot-loader does load the correct kernel and initRD from the ISO-image on the USB-stick. Whatever makes it mount a partition on a totally different drive and consider it as its own tce-directory goes beyond my understanding. In fact, '/dev/sda5' is automatically mounted as '/mnt/sda5'. After loading the extensions, there is an error message that it "can't open /etc/sysconfig/cdroms: No such file or directory".

It almost goes without saying that in the end the system is totally borked. Issueing "sudo fdisk -l" for instance, results in a similar error to the above about missing librariries (libsmartcols.so.1). This intrigues me because this is a different machine than the one mentioned in the original post.

[Misalf]

Remove the  cde  bootcode. Otherwise, Core will boot into cloud-mode (tcedir will be in /tmp).
Also add the  tce=  boot code to point to your actual tce directory. Otherwise Core will search for it on your local drives and uses the first match.
For example

Code: [Select]

tce=UUID="cb6f8b98-91fd-4c96-b115-3d2bb9cb3e57"/tce-7.x


[sm8ps]

Thanks a lot for your explanation, Misalf! I do not fully understand, though, if it does not contradict itself. If I understand correctly then ...
A) the cde boot-code makes the tce-directory be in /tmp.
B) the missing tce= boot-code makes the tce-directory be seeked on hard-disk.
Contradiction? (I am assuming that the tce-directory is in both cases what is linked as '/etc/sysconfig/tcedir'.)

Anyways, the actual behavior of the ISO-build does not seem to match the principle of least surprise. I think that most users would intend to run the ISO-build precisely in cloud mode, similar to a live system without persistency. The whole point in the ISO-build was, IIRC, to get quickly going with dCore without the hassle of boot-loaders.

[Misalf]

Since CDs are not writable, the tcedir will switch to  /tmp/tce  after boot, in order to be able to download extensions.
Until then, the tce directory that was either specified or found will be used during boot.

/etc/sysconfig/tcedir is linked accordingly, yes.

[sm8ps]

I have been bitten by three separate issues:
1. The behavior of the ISO-build with respect to the tce-directory.
2. OpenSSH-server needing additional libraries.
3. An issue with the i915 kernel module in the 4.2.9 kernel.
By a peculiar twist of quantum probability, each of these created highly similar error messages.

Actions:
1. Will create new post here about adding base boot-code to ISO-build.
2. Post created in forum "dCore Imported Extensions".
3. Will follow thread "xenial: xorg problems".

So this thread is closed AFAI am concerned.