You are not logged in.
I think it's just a matter of setting up multiarch because steam seems to be 32bit only:
dpkg --add-architecture i386
apt-get update
apt-get install steamYou obviously need to have non-free sources enabled as steam isn't exactly open source. In case you are wondering where your steam client ends up: It's at /usr/games/steam. Run this from GUI and it'll install it's files to your home directory. You need to you have OpenGL support available for it to work though (which i guess you have if you plan to use steam).
Tiny update: I cleaned the script up a bit and setup a repo at https://chiselapp.com/user/du/repository/voodoo-install. Current tarball is available at https://chiselapp.com/user/du/repositor … all.tar.gz.
The script now doesn't need to be uploaded to the server anymore. It's simply run on the client and does it's job using the provided IP and SSH credentials. Only drawback is it now needs netcat to be installed on both the client and the target (not entirely sure how common that is). Usage is as follows:
./install.sh [SERVER-IP] [SSH-PORT] [USERNAME]In my tests it was quite reliable in working against a Debian Jessie VM (still didn't try anything else though). I am kinda excited to see if this will actually work in the wild too ![]()
I agree with golinux. Aside from updates there is little to do and even upgrading to new releases can be postponed for quite a long time (even Wheezy just reached EOL a couple days ago). So usually as long as you regularly run apt-get update and apt-get upgrade (or rather apt-get dist-upgrade these days) you should be fine.
As far as first steps go i don't think those can be generalized beyond updating the system. For example i usually install systems by deselecting everything (even standard system utilities) in the installer which is unlikely to be a very common choice and my first step (after updating) of installing Midnight Commander might not be everyone's cup of tea either.
There is a couple things that could be called good practice but these usually only apply to special use cases like installing localepurge, deleting apt's package cache or even setting up dpkg configs to avoid installing certain files on systems with little disk space but then how many people are installing to a 256MB CF card and even if they do it's unlikely to happen using the official installer in the first place.
Nice, finally! Glad to hear that ![]()
I'm back again, no it didn't blow up but nothing happened ...
Sad but it wasn't a big chance. Might try
yesinstead of auth_self if you aren't bored with it yet but i don't have all that much hope.
*About my previous commentary ... this time i got to read the whole line at the screen when restarted the system:
couldn't mount ext3 due to future incompatibilities
This is very likely unrelated. As shown by the blkid you posted on the last page your MXLinux partition uses ext4.
Yeah, at least i don't think that'll make anything blow up.
No, i ment to change auth_admin and auth_admin_keep to either
auth_self(according to docs that should ask for authenticaten - root password?) or
yes(which should just do it without further questions).
I am really stabbing in the dark here but i guess it's worth a try.
It's below all the descriptions but above the </action>. Those configuration files are truely a mess i know ![]()
OK, i'll take a shot at this. My best guess is this related to missing polkit permissions for udisks2 so maybe you could try the following:
Open /usr/share/polkit-1/actions/org.freedesktop.udisks2.policy (yes, it's ugly as fuck - lennartware...).
Look for
<action id="org.freedesktop.udisks2.filesystem-mount-system">Below it find the tags auth_any, auth_active and auth_inactive.
Change their values to either yes or auth_self (i seriously don't know which one makes more sense).
Reboot (as i have zero idea what what lennarts polkit crapware needs to reread it's settings).
Hope for the best.
Word of caution: I don't have the slightest experience with this but it that's really the cause waiting for Debian and thereby Devuan to change the defaults is likely to need eternal patience.
Glad to hear you figured it out. I was almost about to ask if a FAT formated thumb drive might have played a role but iirc files stored on those end up with 0755 permissions so i ruled that out. Still kinda strange that aptitude choked on this. Sure the execute bits are silly but i don't see why they should yield a fatal error.
Well, i am as surprised as you are. According to apt-file there are no packages containing /etc/apt/sources.list and i have checked the (imo) most likely packages to have something to do with apt (base-files, tasksel, tasksel-data) for postinst scripts changing permissions on sources.list but found nothing obvious.
OK, before i call it a day here is a bit of something. It's quite raw i know and i have little hope in the overall stability but at least it's a start. Couple of things: It assumes there is systemd running (kinda ironic isn't it?) as for now i've tested it using Debian Jessie. Adjusting for SysV is probably quite easy but i don't think it would run as is on an old kernel like the one CentOS 6.9 uses so that'll take a bit of work. Also the script needs to be exec'd to work and i don't really know why so this needs some investigation i guess. Anyways here is the abomination:
#!/bin/sh
_err() {
echo "ERROR: $1." >&2
exit 1
}
_try() {
"$@" || _err "$* failed"
}
_cleanup() {
mountpoint -q /mnt || return
cd /mnt || return
for MNT in tmp proc sys dev /sbin/init; do
mountpoint -q $MNT && umount -lf $MNT
done
cd ..
umount -lf mnt
}
trap _cleanup EXIT
_try mount -t tmpfs tmpfs /mnt
_try cd /mnt
_try mkdir -p bin sbin usr/bin usr/sbin dev sys proc tmp etc old
_try wget -O bin/busybox \
https://busybox.net/downloads/binaries/1.28.1-defconfig-multiarch/busybox-x86_64
_try chmod +x bin/busybox
for CMD in $( bin/busybox --list-long ); do
_try ln -s /bin/busybox "$CMD"
done
_try mount -t tmpfs tmpfs tmp
_try mount -t proc proc proc
_try mount -t sysfs sysfs sys
_try mount -t devtmpfs devtmpfs dev
_try mount -t devpts devpts dev/pts
_try ln -s /proc/mounts etc/mtab
_try wget https://boot.netboot.xyz/ipxe/netboot.xyz.iso
TTY="/dev/tty8"
cat > init <<___
#!/mnt/bin/busybox sh
cd /mnt
exec < ".$TTY" > ".$TTY" 2> ".$TTY"
mount --make-rprivate /
pivot_root . old
exec bin/busybox chroot . bin/busybox sh install
___
_try chmod +x init
_try mount --bind init /sbin/init
cat > install <<___
_boot() {
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger
}
_err() {
echo "ERROR: \$1." >&2
echo 'waiting 60 seconds until reboot...'
sleep 60
_boot
}
_try() {
"\$@" || _err "\$* failed"
}
for PID in \$( ps ax -o pid= ); do
[ \$PID = 1 ] && continue
kill -9 \$PID
done
for FD in /proc/1/fd/*; do
readlink -f \$FD | grep -q ^/dev/tty || eval "exec \$( basename \$FD )> /dev/null"
done
_try umount -lf /old/dev
for MNT in \$( sed 's/^[^ ]* \\([^ ]*\\) .*/\\1/' /proc/mounts | grep ^/old | sort -r ); do
_try umount \$MNT
done
_try dd if=netboot.xyz.iso of=/dev/sda bs=1M
echo SUCCESS!
echo 'waiting 30 seconds until reboot...'
sleep 30
_boot
___
echo "switching to $TTY..."
exec < ".$TTY" > ".$TTY" 2> ".$TTY"
systemctl daemon-reexecsave as dinst.sh then
chmod +x dinst.sh
exec ./dinst.shand switch to KVM (or just do the whole thing over KVM, didn't try doing it over SSH yet).
Good luck. I am planning to debug and improve it a bit further (including directly installing Devuan without going trough netboot and maybe also qemu based install for servers without KVM) but for today i've seen enough kernel panics ![]()
next thing I'm (or somebody else? (*)) should do, is disable as many daemons as possible on this new VPS instance as possible (to reduce the number of disk writes during copying), then dd|scp the complete thing somewhere home to try it on an old PC, where one at least sees where the smoke is coming out.
Should this work, the actual conversion to devuan could be performed (fine tuned, aren't I hopeful?) on this PC, with ample documentation to allow remote re-runs.
Everything else is both too error prone and, due to the time a remote re-installation takes, too slow.
(*) "or somebody else": I'm willing to order the VPS and hand the credentials to someone else for the surgery, as long as the outcome is made available to anybody who needs it. Maybe other kind souls could do the same for VPSs [or dedicated servers] at other providers?
The usual approaches aren't that bad or time consuming actually once you get used to it even if they aren't anything i'd call overly user friendly. The real problem is without a rescue system to act as a live CD you are screwed. Anyways, no need to buy anything. This whole thing got me curious. I've already spun up a test VM. Also searching around suggests that this is very well possible and actually being done. I'll report back once i have something worth trying.
I am not much help here but from your signature i guess your file manager in Devuan is Thunar. Searching around a bit it seems Thunar uses udisks2 (not sure if that's always the case) for mounting stuff which in turn relies on policykit for permissions (See: http://forums.debian.net/viewtopic.php?p=505400). Not that i can really help you here but i am curious if you can mount anything at all. Like does mounting USB devices work?
I just had another look at the options available from this provider. "Rescue mode" is basically reinstalling the OS from a list of systems, of which only centos 6.9 is systemd-free.
That's sadly not going to be much help but i guess you knew that already. What i ment by "rescue mode" is kind of a live system often available at providers where you have access to your disk (usually to mount it and fix errors but nothing stopping you from dd'ing stuff to it).
The best I can have is a simulated KVM (in the browser).
That's what i ment by VNC. Sorry for the confusion (terminology...). That's good to have as it opens up the possibility of running a real installer without having to resort to qemu.
he problem I see is that I can't access any media other than what's on offer. The only way I can envisage some sort of progress is to reinstall the OS, this time via "KVM", which would then allow me to partition the "disk", boot the new OS, and then upload an iso image into one of the partitions. But how do you then boot from the uploaded iso on the partition?
Yeah, that's pretty much the problem. You usually do it by overwriting the disk (or at least the start of it) with whatever you want to boot and simply dd'ing an iso to /dev/sdX actually works but just dd'ing some installer iso to the disk is not going end well since you are going to overwrite the disk during install therby destroying your installer. The solution here is either using the iso from http://netboot.xyz or the hd-media image (with the actual interaller iso in a partition at the end of the disk that could by used as swap once the installation is finished) which both operate from ram.
And I can't see how to dd an image to the VPS disk when I'm sitting miles away from the server
A bare minimum install is actually very small (at least after being gzipped) and it's not like you have to use a huge disk image. Just enough to fit the minimal install. You can enlarge the partition once it's on the target system. Also if upload speed is still a problem you could prepare the image on another server (with a fat pipe) using qemu.
and have only the remote instance booted off the VPS disk. I've dd'd disks across the network via ssh many times. But in every case the system reading or writing raw data to or from disk was booted from a dvd (or another disk) with the paired system reading or writing the raw data to or from an ordinary file on a mounted disk.
True. That's exactly why a "rescue system" being available is so important for all these approaches. It takes the place of the live DVD to boot off. Without it it's at the very least going to be really tricky.
I've never tried to overwrite the disk a system was actually booted from and i am not convinced it'll work either but i think there might be a way. It's actually a fascinating idea. In theory all it should take is getting the system in a state where unmounting / becomes possible. A simple chroot to a ramdrive might not cut it since there is still tons of stuff accessing / but if that can be taken care of somehow what would stop one from actually unmounting the disk and writing to it? No promises but i am really tempted to try it. Would be quite balls if that worked ![]()
Edit time again: I vaguely remember grub being able to boot iso images. I am not familiar with that but if that works may have a chance to boot your iso from a partition. I'd just abuse swap for that. As in turn off swap, format the former swap partition to ext or whatever grub likes and put your iso there. Boot from KVM and instruct grub to go for the image. Might be an idea at least if what i remember reading about grub is accurate.
Interesting. Didn't know about youtube-viewer. I'll try it out. Thank you!
If you have some kind of rescue mode one way would be to install Devuan in qemu to a raw image backed disk, compress that with your compression tool of choice and just dd it to the VPS disk in rescue mode. Qemu install could also be done on another server and/or piped to dd through ssh if the rescue system doesn't have enough disk/ram available to actually store the compressed disk image. Unless you have VNC access to your VPS make sure to have usable network settings in your image otherwise you'll have a system that boots but can't be reached.
Then there is the https://www.netboot.xyz/ approach where you dd the netboot iso (likely from rescue mode but some voodoo to be able to write to the disk from normal operation could be possible i think) to your VPS disk, reboot and install the OS of your choice. Only works if you have some kind of VNC access and last time i tried it Devuan install was broken though.
Edit: Forgot one method. Qemu in rescue mode: Either install qemu in the rescue system or if not possible download a statically linked qemu. Download a Devuan iso and run qemu with hard disk going straight to /dev/sdX (whatever your VPS harddisk is named in the rescue system), CDRom pointed to the Devuan iso, booting from CD and qemu's VNC server enabled (also KVM if it's available and you don't want the isntall to be stupidly slow). Connect with your favorite VNC client and install. When done you'll need to fix network settings as those of qemu surely don't match the ones used on your VPS. Word of caution about the VNC server: It's unencrypted so better bind to localhost and connect through a ssh tunnel if you value your security. If you are interested in this i guess could dig up a working qemu commandline but for now i am to lazy.
A final method which i haven't done in a long time (sorry if this isn't entirely correct) is to dd the ungzipped version of http://ftp.debian.org/debian/dists/stab … oot.img.gz to your VPS disk and then setup partitions so you have a partition large enough to hold a Devuan iso. Download a Devuan iso to said partition and boot. Again only works if you have VNC access.
Having said that i've also been successful with upgrading KVM and OpenVZ based VPS from Wheezy to Devuan Jessie. No idea about VMWare but i don't see why it wouldn't work there.
Also are you sure the system didn't boot at all? I am not sure if Debian Jessie uses the strange new naming scheme for network devices but if it does it might be that just the network config got screwed up but the system was still OK.
Even more edit: Thinking about this i wonder how feasible it would really be to actually overwrite an active disk with an image (or even debootstrap/qemu install to it). Like chroot to static busybox based root on ram disk, unmount disk, overwrite with image, mount disk, fix networking, reboot? This could be a brilliant script to get Devuan out to the hosting world for people that don't want to go through above mentioned methods.
In case someone is interested in trying something different Fossil makes self hosted repositories stupidly easy. I am using it for a couple personal projects and i am quite satisfied by the simplicity.
apt-get install youtube-dl?
I also have a crappy script that mostly fixes the titles and converts to mp3 if you are interested.
It is working now!. i don't know what i did wrong before maybe because i did't log out as you said, but because i restarted the system?.
Likely. Groups are only applied at login which i am quite sure you did after the reboot.
devuser wrote:I am a bit unsure about ascii-updates and ascii-proposed (probably still better to avoid unless you know you need them) but mixing in experimental is not a good idea unless you know exactly what you are doing. What is the reason for adding it and do you have any pinning in place to keep it in check?
Well I added them because I like to always have the most recent updates of packages available, just like I did when I was in the ArchLinux world. Should I remove them from sources-list?
Btw, I solved my problem by installing the packages through aptitude
I see. You'd be better off to just run testing or unstable if you really want some kind of rolling release. I am happy to hear you managed to fix your problems using aptitude but if i were you i'd try to get to a non mixed release as soon as possible. Dependency problems should seriously never occur on a healthy system. Seems ascii and future releases are still largely compatible but at some point they won't be any longer and then a simple apt-get upgrade is almost guarantied to put your system in a state where reinstall is the only sane solution (even if experimental is a bit of a special case here by not being a complete distribution).
TL;DR: Either run ascii, testing or unstable but not some mixup. Experimental is for development only and not something you should run just to be on the edge.
Edit: Removed some false statements about testing being ahead of unstable. Sorry, not exactly my strong side as i wouldn't run either because i like stable and boring systems.
I've only used dpkg to install the kernel I built with make deb-pkg and to install ungoogled-chromium I've also built.
That doesn't seem to bad. This on the other hand
cat /etc/apt/sources.list:
# deb cdrom:[devuan_ascii_2.0.0-rc_amd64_netinst]/ ascii main non-free #deb cdrom:[devuan_ascii_2.0.0-rc_amd64_netinst]/ ascii main non-free deb [url]http://br.deb.devuan.org/merged[/url] ascii main non-free contrib deb-src [url]http://br.deb.devuan.org/merged[/url] ascii main non-free contrib deb [url]http://br.deb.devuan.org/merged[/url] ascii-updates main non-free contrib deb-src [url]http://br.deb.devuan.org/merged[/url] ascii-updates main non-free contrib deb [url]http://br.deb.devuan.org/merged[/url] ascii-security main non-free contrib deb-src [url]http://br.deb.devuan.org/merged[/url] ascii-security main non-free contrib deb [url]http://br.deb.devuan.org/devuan[/url] ascii-proposed main deb-src [url]http://br.deb.devuan.org/devuan[/url] ascii-proposed main deb [url]http://br.deb.devuan.org/merged[/url] ascii-backports main deb-src [url]http://br.deb.devuan.org/merged[/url] ascii-backports main deb [url]http://br.deb.devuan.org/devuan[/url] experimental main deb-src [url]http://br.deb.devuan.org/devuan[/url] experimental main #------------------------------------------------------------------------------# # UNOFFICIAL REPOS #------------------------------------------------------------------------------# ###### 3rd Party Binary Repos ###Virtualbox deb [arch=i386,amd64] [url]http://download.virtualbox.org/virtualbox/debian[/url] stretch contrib
might very well be the source of your troubles. I am a bit unsure about ascii-updates and ascii-proposed (probably still better to avoid unless you know you need them) but mixing in experimental is not a good idea unless you know exactly what you are doing. What is the reason for adding it and do you have any pinning in place to keep it in check?
Well, you might get away with
apt-get install -fbut imo it's more important to understand how you arrived in that situation. Have you installed any non official packages or used
dpkg -iat some point? What do your apt sources look like?
I think golinux just ment that you should add an fstab entry for the foreign partitions preferably using UUID instead of device name. If you are expecting to be able to mount these partitions as a regular user i don't think that'll really work out. It's sure possible but it's not a good idea to have users mount random partitions besides you'd likely still run into permission problems unless your user ids in the running system match those of the mounted partition.
If you really want to do it i'd recommend you to take a look at udevil and it's ability to use a mount wrapper. The way i handle foreign filesystems on removable media is to mount them as root and then stick a bindfs on top of it that makes all files appear as belonging to the user that requested to mount the device while setting the ownership of all written files to root which is not ideal but at least somewhat sane. I could post the scripts if you are interested.
Thanks for the tips. Sadly nothing i can improvise right now. Might clean it up a bit but i have little hope it'll make much of a difference. The oil approach seemed interesting until i read i'd need an extra fan. Besides i have no idea how the Huawei E870 card would like having it's antenna covered in oil.
Having spent most of yesterday trying to find a better spot i think i can say it's either stupidly high and hot or a connection that breaks down every 5 minutes. If there is any connection at all. Interestingly a couple spots give better reception than ones that actually connect. I guess that hints at the transmission power of the Huawei card actually being the limiting factor here.
Maybe i'll try to get an external antenna and see if this improves things but i am not sure if it's worth it to invest in this kind of setup (the USB 2.0 bus supplied by a second PCMCIA card is also a bit flaky which sometimes causes the TP-Link 722N dongle that powers the AP to disappear) and not just get something at least a little better. Building anything that isn't based on a laptop is sadly somewhat hard when you don't even have an external monitor available though.