New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Anyone else getting random timeouts?
Just received 4 emails alerting me of server defect due their ping monitoring system timing out, but shortly followup emails saying no longer need to intervene because server is responding back.
By the way, I just tested loading up any template and then replacing the contents in /boot with anything but a recognized kernel will result in netboot of 4.5.2. You can actually watch it netboot if you try this, remove/replace kernel and reboot and start ping, you will get 2-3 pings, then it will stop and then it will resume after it netboots. Once you reboot, regardless of what kernel you had before, you will have booted 4.5.2. So for those who already have images built and didn't want to have to switch, you don't have to... just remove the kernel in /boot and reboot.
My guess is 4.5.2 was the original kernel provided to them by Marvell which was built correctly and all the others were builds they tried them selves. Also why I think they provide the modules deb for 4.5.2 and no other version.
Update: haven't figure it out yet but seems this kernel with the older Wheezy openmediavault version seems to cause some kernel panics.. testing more.
Update 2: seems to be related to trying to open my LUKS volume made with the other kernel version, doesn't seem to like it for some reason. Opens just fine on 4.9.2. Anyways, other than that runs okay on 4.5.2.
Cheers!
In case you haven't read my responses through this thread, I would suggest again that the system they are using (likely a specialized U-boot) is looking for one of a handful of expected kernels in /boot on the first ext3 volume OR if not found it is straight up netbooting off their pxe boot server onto 4.5.2. This would also mean that by dding anything to the volume it will not boot. ARM servers are not like x86, where they have a UEFI bios or something to tell it what to boot, instead it relies on a boot loader known as U-Boot and a compatible kernel being loaded by it.
TL;DR: You can only use their templates and if you want you can remove the template kernel and the result is kernel 4.5.2 from netboot, which seems to be the overall best kernel to use at this time. Trying to boot other operating systems such as live CDs or x86 based OSes will not work here.
*if you are familiar with building your own buildroot system you may be able to do this and drop it in place of their poorly created templates but it would likely take a good bit of work and you are still restricted to the provided kernels.
Cheers!
So if they upgrade their netboot to 4.9, we (you) are all fucked once again but this time with no way out?
this!
I tried to compile a kernel several times (takes about one hour each) including the uImage and stuff and replace the provided 4.9.58 with those. I tried to make use of any hints and info I could find (CFLAGS, LOADADDRESS ...) but while the compiling went through easily, the server did not boot with any other (own) version.
I tried with 4.9.109 and even recompiling 4.9.58 from the official sources didn't cut it. without VNC it's hard to diagnose further and I now lost interest in spending any more time on it.
TL;DR; I agree, the use of the default 4.5.2 kernel probably is the easiest and best solution thus far.
PS: the latter should work OOB if you don't tick the 'use distro kernel' box during install as mentioned above - hence no need to purge any stuff afterwards as suggested before.
I would like to find some backup storage in Europe and the ARM-2T for 4.99 EUR looks tempting. But given the download speed issues, is it worth the effort or is better to try to find a kimsufi with 2TB for 7.99 EUR?
The last 50 messages here describe a workaround for the speed issues...
True, thanks! Just having a hard time deciding if it's worth the effort. But I guess I could as well give it a try and see how it works.
Well, SoYouStart's 250 Mbps with 2.5Gbps uplink is potentially better than Kimsufi's 100Mbps if it works right
https://ibb.co/h6n6fJ
that's exactly what I think.
Especially if you have several dedis and uses the ARM server as NFS backup storage.
eh I should have ordered another one. What's the best site for checking / notifying on stock for the SYS arm?
https://checkservers.ovh
Copy (and backup) the 4.5.2 kernel into /boot, and hope that it is still an "allowed" kernel, even after it is potentially removed as a netboot kernel?
That's what I'm worried about...I would feel much better about it if we could boot whatever kernel we want.
how secure is it to do an NFS share to a dedi in the same DC?
should i only do this behind a VPN tunnel?
tested some stuff in rtorrent. fastest speeds i got was 30mbyte/s down (same with 4 small or 1 large torrent; private tracker so it cant be the seeds). cpu was maxed out 100%. good enough for long term seeding. i'd advise to buy multiple small 2tb ones instead of one large 6tb one because the cpu is as powerfull as the old online.net kidechire via nano cpu.
I tried with 4.9.109 and even recompiling 4.9.58 from the official sources didn't cut it. without VNC it's hard to diagnose further and I now lost interest in spending any more time on it.
Try renaming the kernel you build to match the names of the kernel(s) which are expected and see if it works? I am not sure if it is checking the version or just if the filename is present in /boot. However, I can state for a fact that if you place a kernel that it expects in /boot regardless of toggling 'use distribution kernel' or not, it will boot that kernel. I tested removing the kernel and then placing a different version it would recognize and it booted with it.
These really are meant to be more of a long term storage box than a service actively used for torrents, so for most storage use cases the low amount of CPU shouldn't be a big deal. I actually use several ESPRESSOBins here locally (Marvell based arm board with SATA and 3x1GB nic, which is similar to what is in use in this service) and I use them to run raid5s of 5x2TB without any issue (using an additional PCIe SATA Adapter). As a storage device it performs just great, if you start adding services on it though, you end up in the same place, as it also only has 2 x 1Ghz cores as well. Though to note, the ESPRESSOBins only have 1GB of ram, while these services have 2GB so you do have a little more room to breath on this service than what the ESPRESSOBin provides. They have uptimes of over 6 months on my home storage platform and have no issue getting 100M/sec throughput using NFS/SAMBA on local network.
TL;DR;
For simple storage this service will be perfect but if you are expecting to run a bunch of services on it, you won't be so impressed as the CPU here isn't really made for handling such.
my 2 cents.
Cheers!
yeah I tried that. essentially during startup it looks for /boot/uImage , which itself is linked to whatever kernel-uImage-file you want to boot. I figured the loadaddress and entry point with mkimage from the 4.9.58 version OVH provides and used the same and of course the name when creating the uImage from the zImage of my self-compiled kernel, still no luck. I put the system.map and config-file into /boot too and so on, but it always got stuck on boot.
obviously it tried to boot from that uImage, but got whatever issues with it and without VNC or logging I can't see nothing at all, so have no clue whats missing.
I have to admit I am not that much experienced with building own kernels esp. on arm and with uImage and all that, so also don't know how to trace better or what to look for.
if you say you replaced the uImage with another version, where did you get that other version from? as said that's not my usual daywork but willing to learn ;-)
Set a firewall (example: iptables)
(a). allows specific IP to NFS ports
or
(b). drop IP not equivalent specific IP to NFS ports
(a) or (b) is based on your default policy is DROP or ACCEPT.
One of the first things I did was boot each template and make a back-up of /boot and /lib/modules and kept them aside. In my test I was simply restoring the kernels/modules from these templates in place. Using any kernel they provided in /boot seems to work. I did try once to compile my own kernel, however, I believe I ended up in the same spot as you -- missing some special sauce that is needed and instead the kernel panics during boot time or the network interface doesn't come up. It could be with how the new kernel enumerates the network (as in its being assigned ens1 or some random interface and it isn't being assigned an IP at boot) or how it identifies the SATA devices (meaning the root volume it expects at /dev/sda isn't there for some reason). Without having their U-boot or kernel source though, it will be hard to guess.
I may bug a few of my buddies who work with ARM devices and kernels (for a living) later and see if they have any thoughts about it, but I am not holding my breathe as it doesn't seem OVH wishes to disclose that information or allow us to build kernels -- My request for kernel source got sent to the OS team and after that I have never heard back -- doubt I ever will.
Cheers!
wow. even $80 servers arenot available ? do these boxes come with vanilla icecream ? :P
no they didn't went live with the new servers yet, they were not available at all so far.
What happened with the cheaper SYS servers that were supposed to be released?
Oles said last week "keep calm".
I just saw the "new" now appearing on sys, give it a few days to see the cheap ones.
I have two ARM servers: one in BHS and one in GRA, both modified to reach 250MBps upload (to online.net). But rsync'ing between the two servers (either direction) is not exceeding 20-30 Mbps ?
RSyncing between a KS in BHS and the ARM in GRA is reaching 100 Mbps (easily), the same goes for KS (BHS) <-> SYS (BHS).
Anyone having the same experience of relative slow speed between ARM's ? Tx
rsyncing involves ssh and therefore uses compression, which might turn the weak cpu into the bottleneck here. try turning compression off ( -e "ssh -T -o Compression=no" ).
depending on what you are transferring you might gain a better overall performance from a speedier network than what you could spare on transfer with compression at all.
Good idea ! Did not think about that option. However, turned it of with the instruction you stated, but it made no difference.
UPDATE: ok, but I used the -z switch with rsync ... removed it... that solved it !
that's odd, you could install iperf and have it running on one server via iperf -s , then connect to it for a speed test with iperf -c from the other one to see if the connection between those two is the issue.
Your post crossed my update :-)