dCore Import Debian Packages to Mountable SCE extensions > dCore X86

dCore-xenial missing libraries

(1/2) > >>

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: ---tce=UUID="cb6f8b98-91fd-4c96-b115-3d2bb9cb3e57"/tce-7.x

--- End code ---

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.

Navigation

[0] Message Index

[#] Next page