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
From only a security standpoint, it's surely advisable to use the latest stable kernel. Only providing a crippled default kernel isn't really good, now is it?
I know how to apply patches during kernel builds but without the steps for building, plus the mechanism to create the uImage, it's no help at all, to have the patches.
Unfortunately these SoC things make everything more complicated, not to mention in-house patches and other bug^h^h^h tweaks.
My point here is: you can't really "use" the recent-ish kernels because it destroys networking abilities, but you also can't really "use" the old netboot kernel because anything in need of a locally-installed kernel shrieks.
You'd think a simple diff on the netboot makeconfig against the supplied kernel configs, would quickly show where the crippled network oversight/mistake was made.
I've always liked the 3 disks configuration. 2 disks in RAID 1 and the 3rd used for local backups.
I am monitoring the availability of their arm storage servers, once I get my hands on another one, I am going to try to rebuild the original kernel and if that suceeds to patch a newer one ;-)
@Falzo drop me a DM and I will give you access to one I picked up that is idling for just this use case. If you have the time I am happy to provide you access. Just let me know.
Cheers!
I'd sacrifice my (NextCloud tertiary backup) server to test a build. Got a BF KS4C to do the build on ;-)
(LET is such a bad influence!)
@Falzo @TheLinuxBug thank you both for helping/working on the ARM kernel issues
it's just a game, you know ;-)
If kernel modules are a problem I thought this works: http://last.public.ovh.hdaas.snap.mirrors.ovh.net/ubuntu/pool/main/l/linux-modules-armada375/linux-modules-armada375_4.5.2-4_armhf.deb
That isn't the case anymore?
Just keep watching SYS Storage on CA, it wont appear in France.
Sometimes even the FR API returns unknown in BHS.
I am not about the modules, I'd just like to have a newer kernel that's not restricting network connections to 5Mbit/s ;-)
Removing buggy Marvell optimizations from inside the kernel (leaving it up to optional modules) could help, too.
I can confirm this. 30 minutes ago, I received an e-mail from metaDedi about the availability of am ARM-2T server in BHS, went immediately to the /ca/en page but couldn't order because only Canadian residents are allowed to register there.
Constantly checked the /de page and also tried the direct link but it was always out of stock. A couple of minutes later and the server was gone on the /ca/en page. Damn...
This is not fully true. However, I am from the USA so maybe the restriction is to North America? That said, I had no issues registering and I am not from Canada, so I would double check again cause it doesn't seem like that should be right? I mean I have an EU account also and I am not from the EU, so seems weird they would enforce this the other way around.
@wokenwoll is this actually the case? Are the different portals in any way restricted to who can sign-up? Can EU residents only sign-up in the EU portals?
(Could make sense if you consider VAT, but still seems odd to me).
Cheers!
I'm European (with a FR account usually) but had no issue ordering a CA server by creating a US account.
(what a mess)
Just a note that you can view the U-Boot configurations by installing
u-boot-tools
and using the following/etc/fw_env.config
:The configurations can be viewed with
fw_printenv
, but as others have said, it's very unwise to change them without fully understanding the boot process.Well, my German SYS login details get rejected on the /ca/en page and I am unable to change the country when trying to create a new account on the /ca/en page:
CA is now for Canada only.
The US moved to a separate site.
For the US there is: ovh.us and there is a new site and billing.
Worldwide $ site: https://www.soyoustart.com/us/server-storage/
or Worldwide € site: https://www.soyoustart.com/ie/server-storage/
Will need to create a new account, and potentially re-verify
Just a thought: Maybe we can all chip in a couple of bucks to sponsor someone knowledgeable a day of KVM over IP access. That way he/she will be able to see what's wrong with our self-compiled kernels, and gain more insight into the boot process with the U-Boot prompt.
Oh yea, fuck, my fault then ca is not worldwide, I changed it to us now.
My fault, fixed.
Was about to buy a new server and damn $50 set-up fee, missing the days no set-up fee already, going to Hetzner I guess
I am using Debian but with the VaultMedia software, I tried to follow this but it says:
What could I do to solve this? TBH Did not know about this issue as so far I have not downloaded anything just uploaded
RE: SYS Arm Servers
Just a teaser for those who care -- @Falzo, one of my good buddies and my self have been working on the kernel issue for the past several days and so far I can report we have managed to build and boot a kernel we built. That said, our first attempts have so far shown the same networking issues using their patches. As such, we are still working to find a kernel which actually has a good driver for networking and get it built (and/or we will work to see if we can find the issue in the driver). More information to come as we make progress!
Seeing as OVH has not been a very big help at all, this is a huge step forward even just being able to build and boot out own kernel. So, once we have something solid, we will share our work in more detail.
Cheers!
That's great work! Was it 4.9.116?
Awesome work guys! Thanks for sharing your work when it is done. OVH should hire you guys hint hint.
Kudos @TheLinuxBug & @Falzo !
Keep up the good work. :-)
thanks, but I have to admit I got stuck on trying to compile their kernel from their sources big time. luckily @linuxthebug knows people who are more experienced esp. on ARM ... let's see where this whole thing brings us. I am very curious myself ;-)
When I was doing similar work for the Toshiba Click Mini, the kernel version had a lot of influence on whether I was successful or not, with various hardware drivers. Kernel 4.15 changed things considerably, compared to 4.14, for example.
( http://toshibaclick.info/files/kernel-build/ )