Found out what had disabled my beep in terminals and other programs such as nedit.

I used to set up every desktop here to start in runlevel 3 (or manual mode), followed by a startx. Always worked. As long as I can remember.

Now with Devuan 5 (because Debian) there are some changes, some of which I probably haven't tripped over yet. One of them is the retched beep which is somehow disabled if you run a window manager, such as fluxbox, openbox or blackbox, without a display manager. That's the key.

The differences are subtle, but they annoyed the hell out of not just me here (no audible feedback when backspacing or deleting into the void, no feedback on tab completion etc).

Finally got everything working by using lightdm, which is compact enough and very light on dependencies. Even corrected the misaligned positioning of the hostname that someone reported about four years ago and which was fixed last month, but hadn't filtered through to debian and then devuan.

Disadvantage: because ssh-agent wants to be started before windows are opened for business - and I don't like the many dependencies that come with all the alternatives - I opted for ssh-askpass, which, as a pure X11 app, is uglier than ..., let's just say pretty it's not.

But that's something for another day.

The 3rd example at wiki.qemu.org under User Networking did the trick. What I've been reading earlier was all very elaborate and more confusing than explaining. This wiki example is shorter than what I've been using, so it wins already. It also has the benefit of doing exactly what I wanted.

This is what I wound up with:

	qemu-system-x86_64 -enable-kvm -m 3G -hda win7.qcow2	-netdev user,id=net0	-device e1000,netdev=net0

thanks

ks

PS: forgot about error messages. All it said was that vlan was deprecated, logfiles didn't have any entries.

# Readline is set to produce an audible bell?

Well, in /etc/inputrc (which I hadn't checked) was
  # set bell-style none
which I changed to
  set bell-style audible
and it made. Made no difference.

Strange that /usr/bin/beep and the script you posted both beep.
beep writes to /dev/input/by-path/platform-pcspkr-event-spkr, unfortunately strace doesn't show anything beep or io related when I try anything other than the beep command.

But from a list of 15 things to sort out post installation I'm down to five, two of which I still don't know how to do. But not today.

Ok, I didn't know that ping doesn't work under user mode networking. So I tried ssh from the guest to the host it's running on, which gives me a weird result. I seems to connect, but then leaves me in my current directory in the client, which is explained by the correct ip's returned by host "$hostname": 192.168.0.4 and 127.0.0.1

The 192 address can't be reached from 10.0.2.225 (obviously), but the 127 one it's happy to connect to - not what I wanted, because it connects to itself (guest) instead of the actual host qemu is running on. Useless for scp'ing files to and from.

I then tried a different host on the network (192.168.0.64) and there I was able to log in using ssh. Still leaves me unable to talk to the host.

klaus

Just had a look at Hetzner's pages, and their FAQ, because the pretty pages don't really say much. Immediately tripped over:

How can I access the server I rebuilt? ... a new root-password for server1 will be generated and mailed to you. It will be set on first boot using the cloud-init mechanism.

That's that then ;(

Well, that didn't go as planned. The hoster I'm using for this project uses cloud-it http://cloudinit.readthedocs.io/en/latest/ to setup and manage VPS instances. Cloud-it occupies many config files, scripts and four inits and, when running debian, depends on systemd (which is gone after the migration).

I was really hopeful that once ssh is reinstalled after the migration from debian to devuan that was all that would be required - shows you how blue-eyed I can be.

Switching to the KVM at least enables you to watch the VPS in a reboot loop, no chance of entering anything there.

As I have a VPS running centos 6.9 (pre-systemd) at this particular hoster I could pull off the "cloud-ed" files from there and make them available to someone, so one could - with lots of luck - replace the systemd base cloud-it files for those from centos, although I'm not sure that would be easy or even stable long term.

Not sure how to get VPS hosters to add devuan to their list of OSs provided. Maybe the only solution is to use dedicated servers that have un-poettering'ed OS support and run, if needed, multiple web sites on such a server although I prefer to separate things if they're not totally under my control. Ah, well...

OMG you're fast. I'll try very hard to set up a debian jessie system on Saturday and run your script on that. Fingers crossed

I totally agree that something is desperately needed to get devuan into the hosting world, because apart from Centos 6.9 --- which will only get security fixes for another year or two --- there's nothing without systemd that I know of. Once that's no longer available, we're stuffed.

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. The best I can have is a simulated KVM (in the browser).

The 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?

And I can't see how to dd an image to the VPS disk when I'm sitting miles away from the server 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.

Can't get my head around this at the moment.

Ok, I just played around with it again, and I remembered that when I originally became somewhat frustrated with it at first it worked for a while, but if I switch between wired and wireless more than once it loses the ability to connect to the wired eth0. Even if I switch OFF wireless it can no longer do wired. So in the end I just reinstalled my zero size wired-settings.conf to have wicd ignore the wired netcard (Don't know if it has anything to do with it but I often can see up to a dozen accesspoints, some of them open [no passwd required]).

Here's the wired-settings.conf that worked temporarily:

[wired-default]
afterscript = None
dhcphostname = is.work-lanname
postdisconnectscript = None
dns_domain = workplace.tld
gateway = 192.168.0.64
use_global_dns = False
lastused = True
encryption_enabled = False
beforescript = None
ip = 192.168.0.8
broadcast = None
netmask = 255.255.255.0
usedhcphostname = 0
predisconnectscript = None
enctype = None
default = 1
dns2 = 192.168.0.64
search_domain = None
use_static_dns = True
dns3 = None
profilename = wired-default
dns1 = 192.168.0.63

Here's my manager-settings.conf:

[Settings]
backend = external
wireless_interface = eth1
wired_interface = eth0
wpa_driver = wext
always_show_wired_interface = False
use_global_dns = False
global_dns_1 = None
global_dns_2 = None
global_dns_3 = None
global_dns_dom = None
global_search_dom = None
auto_reconnect = True
debug_mode = 0
wired_connect_mode = 1
signal_display_type = 0
should_verify_ap = 1
dhcp_client = 0
link_detect_tool = 0
flush_tool = 0
sudo_app = 0
prefer_wired = False
show_never_connect = True

Maybe you see something in there, if not, I'll keep my current setup with the 0-size wired-settings.conf