You are not logged in.
I have a strange problem.
I added a second monitor and configured it to have a second monitor that works as a separate desktop and not mirroring on latest Devuan.
I noticed the following curious behavior.
1) If I change desktop backgrounds and I move the config window from the one window to the other, then the available backgrounds completely changes to other options. Really weird.
2) Also, when I want to choose a background and browse the folders in /usr/share they are all blacked out and I dont have permission to access any directories from the second monitor, but if I move the selection windowit back top the first monitor then everything in /usr/share is visible and browsable.
Anyone know what this is about.
Really weird.
# ls -l /mnt/lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 32 Jan 14 2018 /mnt/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.24.so
# ls -l /mnt/lib/x86_64-linux-gnu/libtinfo.so.5
ls: cannot access '/mnt/lib/x86_64-linux-gnu/libtinfo.so.5': No such file or directory
# ls -l /mnt/lib/x86_64-linux-gnu/libdl.so.2
ls: cannot access '/mnt/lib/x86_64-linux-gnu/libdl.so.2': No such file or directory
# ls -l /mnt/lib/x86_64-linux-gnu/libc.so.6
ls: cannot access '/mnt/lib/x86_64-linux-gnu/libc.so.6': No such file or directory
# ls -l /mnt/bin/bash
-rwxr-xr-x 1 root root 1099016 May 15 2017 /mnt/bin/bash
Doesnt look right. Dont know why they are missing. I guess I will have to find them and link them back or something.
You can be rude, sometimes good and clever people make stupid mistakes, but so far I didnt.
# ls -lL /mnt/lib64/ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 153288 Feb 6 2019 /mnt/lib64/ld-linux-x86-64.so.2
Maybe I should just reinstall. Maybe that installation has been hit by a god-particle.
# chroot /mnt ls
chroot: failed to run command ‘ls’: No such file or directory
but I can cd into /mnt and do an ls and it works, so it must be a problem with chroot itself.
Again" Remember, these are Vanilla installs. The only thing that has been done after install is apt update & apt upgrade.
That is it.
I want to use Devuan on my rackservers and is currently testing it. I like it very much as I got rid of all the enormous systemD related problems by using it, but chroot is unfortunately crucial to work.
Does it actually work on anyone elses latest Devuan install ? I did list my distro details in an earlier post for reference
I already confirmed that # /mnt/bin/bash executes without returning an error in my previous posts.
# ldd /mnt/bin/bash
linux-vdso.so.1 (0x00007ffc7798e000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fda49c9b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fda49a97000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda496f8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fda49ec5000)
For the record remember these are vanilla installations of Devuan.
No alterations. Both are identical
# cat /etc/*lease*
PRETTY_NAME="Devuan GNU/Linux ascii"
NAME="Devuan GNU/Linux"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"
# cat /proc/version
Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1+deb9u4 (2019-07-19)
Nope the file system is intact and it has an executable /bin/bash
/dev/sdb6 11468016 2111548 8754204 20% /mnt
root@blinc:~# ls -l /mnt/bin/bash
-rwxr-xr-x 1 root root 1099016 May 15 2017 /mnt/bin/bash
I can even execute /mnt/bin/bash
and it complees without error.
Perfectly working.
This pc dont have efi enabled bios, it is legacy..
Yes you guessed right, I have to run grub on that partition.
BTW, that error message about /bin/bash must be a bug with chroot. /bin/bash clearly exists.
It is a bug misreporting an error now for years and they never fix it.
In my case system is /dev/sdb3 and target to chroot to is /dev/sdb6
root@blinc:~# mount /dev/sdb6 /mnt
root@blinc:~# mkdir -p /mnt/boot/efi
root@blinc:~# mount /dev/sdb3 /mnt/boot/efi
root@blinc:~# mount --bind /dev /mnt/dev
root@blinc:~# mount --bind /proc /mnt/proc
root@ginc:~# mount --bind /sys /mnt/sys
root@blinc:~# chroot /mnt
chroot: failed to run command ‘/bin/bash’: No such file or directory
Note: These are fresh unaltered Devuan installs.
also, if you dont give the command field to chroot then it assumes that bash is in /bin/bash you give the command argument if bash is somewhere else than that.
In this case bash IS in /bin/bash. so both our chroot commands are basically the same.
Hi thanks.
This doesnt work at all sorry, .mount -t proc none proc can never work
'Yes I copied it double.from my terminal
/bin/bash is command to be executed in target installation.
Used to work flawlessly.
And..
# ls /bin/chroot
ls: cannot access '/bin/chroot': No such file or directory
# whereis chroot
chroot: /usr/sbin/chroot /usr/share/man/man8/chroot.8.gz
So the commands you posted are for a completely different system than Devuan.
Somehow my usual chroot tricks dont work on Devuan.
I have two Devuan installations on the same disk.
One on /dev/sdb3 and another on /dev/sdb6
I want to chroot devuan on /dev/sdb6 while I am in devuan on /dev/sdb3
While I am root user in Devuan on /dev/sdb3 I do.
mount /dev/sdb6 /sdb6
mount -t proc none /sbd6/proc
mount -t proc none /sdb6/proc
mount --rbind /sys /sdb6/sys
mount --rbind /dev /sdb6/dev
chroot /sdb6 /bin/bash
I now get
chroot: failed to run command ‘/bin/bash’: No such file or directory
Why doesnt this work in Devuan ?
It worked on Debian
L want to use Devuan on my rackservers as it has syv init unlike the horrid debian/redhat route of using the bug infested systemd that caused me so much trouble on my servers.
I am very glad to have found Devuan and will support it as far as I can.
My test system before dep-loyment is a pc with externa USB to sata converter with 1TB sata3 drive.
For debug purposes it is crucial that an OS must be able to boot from an externa USB stata drive. It is needed in my protocols. No ifs or buts even though all the rackservers is hotswap.
Question
USB drive has 15 operating systems in partitions on it for testing.
1) Debian, MX18, Fedora, Ubuntu,puppy,slack as an example all install to and boots from the drive. All were installed on the MBR of the disk /dev/sdb
2) There is somehow no way Devuan can be installed on an external drive such as this. Since Devuan is a fork of debian I cannot see why this should happen as Debian boots no problem.
After installation I just get the error message as in this image
"http://tinypic.com/r/9u0pkl/9"
Anyone has an idea why this happens to only Devuan ?
If I cant sorth this out, I will have to use second best systemd free distro MXLinux which works like a charm, but I really want to use Devuan.
This will be helpful to test on some of the servers I want to migrate.
Would be interesting to see what life after dbus looks like. Will be a great experiment.
kdbus slows everything down considerably. It does the opposite of what it was set out to do.
As if dbus is not bad enough.
My biggest bottlenecks through the years were
selinux
dbus
and now systemd.
Wasted probably the equivalent of years of time dealing with these three abominations.
Thank god we still have the option to fork.
But that would probably not showing "empathy" for the branch you are forking from, so the ethics police will eventually attack that too.
I am really soooo done with debian/redhat/fedora/ubuntu. They lost me forever.
Anyway, thanks for the fast response, I will start using it soon.
Thank you both, browsing through the links I have all I need. I will try one migration on a server. Easy to back up system as it has hot swp drives.
I read there is also the option of no-dbus devuan
That is even greater news. I must yet start an application using dbus that doesnt throw a slew of errors in the logs.
I wonder who thought up that horrible system.
Dbus has been a pain in my side for many years. It behaves like a headless nick.
You are definitely going the right direction.
I was not aware of the systemd trojan horse as a debian user until recent.
Recently I started getting horrible compatibility problems and it took me 6 months to figure out what the cause was.
I didnt notice that sysv was silently replaced with systemd and that sysv was seemingly emulated within systemd as systemd-sysv.
Really sneaky and absolute subterfuge to any sysadmin.
I had so many things on Debian that stopped working correctly . Samba,sshfs,some cron calls and many other user side software packages. The chaos created with Cron was the most annoying as systemd had no regard for cron and just installed anacron and started it alongside cron without any knowledge that it is actually running and competing with cron if you queried it through apt and dpkg. After enormous cron problems I traced the issue back to anacron and eventually systemd which installed it in parallel. Uninstalling all the bogus competitive daemons systemd performed I had cron back up working as it should with my extensive scripts.
So I am parting ways hard with systemd and Debian/redhat/Ubuntu and my company and I personally will follow the fork and go a different way with Devuan and or the other Sysv distros. I understand that the forks will create some stability issues initially, but rather that than the absolute dictatorial fascist systemd arrogance I experienced from their evangelists on line. It seems to me as if the systemd movement is paid for by a powerful rich invisible hand. I really smell a rat reading the way these systemd people behave. I have seen this before.
After the introduction:
One question.
Is there a way to for example migrate a Debian Stretch system to Devuan.
All it should take as first step is to remove systemd and replace it with sysv-core, but I ask if such migration maybe exist as I have several servers I need to migrate. Clean new install is probably the best option, but I thought I ask anyway.