Here is the story. About 1 year ago i bought a VPS to ovh.net (ovh.net, ovh.com , ovh.pt, ovh.pt, etc etc they are all the same).

I first installed debian and for 1 year the vps was ok. Limited but ok. Last year i renewed the service for 2 more years and recently i tried to update the system. BIG mistake. Very regrettable.

To make a long story very short OVH debian broke; Their iscsi system was malfunctioning so bad that even most recovery options were not even working. Outdated kernels; udev problems ... this went to the point if seriously incompetent support service, technical service and customer service. All they care is if the machine responds to pings. I had email replies that not even a 15 year old that started to learn how to use linux will use to justify something.

In time they recognized their problem. Removed debian from the available install options and selections. Said they would compensate me for my downtimes. I had given up on using the service which almost caused me 2 years of data loss. (I will never EVER use OVH in my life and will not risk my work there again) but the box is paid for 2 more years. Although it wont be hosting my work i thought about putting it at the service to help other projects in regards of bandwidth and storage and decided to install gentoo in there. (available version from 2007)

Gentoo also faces the same problems as debian. In fact OVH as admitted that my service is now obsolete and no longer supported. They refuse to reimburse me or provide working solutions (ovh.pt) at no economic cost.

I am now stuck with a service that uses their own kernel which to what i was told i am stuck with. Uses their own portage ebuild system and custom packages which besides outdated and broken i was able to change. Any attempt of system or world update with their portage results in endless amount of fail installs/compile logs that i never seen in 7 years of gentoo.
With their install i am unable to use updated or even install a basic software package either because of dependencies or lack of dependencies. this counts for manually compile too.

Gentlemen... this company even provides 2.4 kernels and prevents clients to use their own kernel. Their solution is to upgrade to a better service which means pay for a new server package.

I have been trying to fix gentoo and at every fail i have to reinstall it and start from zero. I have lost my patience with their lousy and terrible customer/tech service which is unacceptable at all levels.

python-updater results in a endless amount of lines like the following:

Code:

/usr/sbin/python-updater: line 65: /etc/init.d/functions.sh: No such file or directory
Traceback (most recent call last):
File "<string>", line 22, in <module>
AttributeError: 'portdbapi' object has no attribute 'repositories'
/usr/sbin/python-updater: line 621: einfo: command not found
/usr/sbin/python-updater: line 622: einfo: command not found
/usr/sbin/python-updater: line 623: einfo: command not found
/usr/sbin/python-updater: line 624: einfo: command not found
/usr/sbin/python-updater: line 625: einfo: command not found
/usr/sbin/python-updater: line 626: eindent: command not found
/usr/sbin/python-updater: line 630: eoutdent: command not found
/usr/sbin/python-updater: line 860: eindent: command not found
/usr/sbin/python-updater: line 861: einfo: command not found
/usr/sbin/python-updater: line 862: eindent: command not found
/usr/sbin/python-updater: line 864: eoutdent: command not found

Portage requires a minimum of python-2.6. The only package manager you'll get to work on that is pkgcore which can still operate on python-2.5.

But there are many newer pkgs that rely on newer kernels, so for that reason you are likely to run into other upgrade troubles._________________Brian
Porthole, the Portage GUI frontend irc@freenode: #gentoo-guis, #porthole, Blog
layman, gentoolkit, CoreBuilder, esearch...

Edit:I was able to get portage fixed by manually install python (despite the errors) and then do the same for portage.
I also had to install a few other packages manuall such as libtool.
Portage is now updating itself was well as python 3*
Once i fix gcc and glibc i will post the what i did to get it all fixed.

Very slowly i have been able to install one package here one package there from source playing eith their versions and using older versions while slowly upgrading them untill they fail and until i ran out of options.
Then i moved to use binhost from http://tinderbox.dev.gentoo.org which allowed me to continue with the same results; one package here one package there doing the same has before....

Right now at least gcc is at 4.5* but

Code:

# gcc -v
/usr/bin/gcc-config: line 19: /etc/init.d/functions.sh: No such file or directory
gcc-config: Could not source /etc/init.d/functions.sh!
gcc-config error: Could not get compiler binary path: No such file or directory

Python at 2.7 but strangely some applications ask for 2.6.
Portage at 2.1.10.57 and i hit another wall.

Almost all packages now fail to install or compile due to the following 4 errors:

When i almost got it fixed it broke. I have reinstalled the system and retried many times.
The tinderbox solution fails if i replace all 3 packages right away.
The gentoo handbook portage upgrade seems the most functional method and from there trying to install and upgrade packages slowly by old versions; one by one until they get to current date or closer.
I also created my own binhost using a almost the same machine environment but without success.

Right now i have created bin packages for all packages installed in that machine as a backup method and am stuck with upgrading portage since it needs bash 4. Bash 4 fails to compile.

* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.

('ebuild', '/', 'app-shells/bash-4.2_p20', 'merge') pulled in by
bash

I have been trying to look for older bash versions to slowly upgrade them until some stage is able to meet dependencies requirements but without success . Does anyone knows where or still have ebuils or and or packages prior to 4.0 but higher than 3.2_p17 ?
I cannot use the tinderbox method as it will break it.

After a few more retries where trial and error was the only option, i was able to update the system.
This took full time dedication. Had to upgrade packages slowly by using older versions and upgrading as fit and possible.
Sometimes using my own binary packages, other times downgrading and upgrading to be able to avoid circular dependencies and in the middle of all some "IT voodoo"also happened.

In the end there was udev, the kernel and openrc/baselayout. Once i changed baselayout i lost connectivity and had to boot the machine froma live recovery system where i am currently stuck.
The udev update; kernel sources and openrc were selected to match the running kernel and not higher versions.

Boot image: /boot/bzImage-2.6.32.2-xxxx-grs-ipv4-64
Mapping RAM disk /initrd-iscsi.img
Warning: The initial RAM disk is too big to fit between the kernel and
the 15M-16M memory hole. It will be loaded in the highest memory as
though the configuration file specified "large-memory" and it will
be assumed that the BIOS supports memory moves above 16M.
Added linux ? *

How does iSCSI come into the picture for your setup? Do you even need it to boot? Everything I see points to /dev/sda being a simple virtual disk device that you set up a bootloader on with lilo. If that's the case, I suggest removing their initrd; it seems to be set up for a setup where you have the root filesystem on iSCSI and it doesn't seem to be working right for that case (note how udhcpd doesn't only fail to get an IP, it fails at seeing the interface entirely). Just booting with a simple root=/dev/sda1 commandline and no initrd should at least get vKVM working and it's much easier to debug any remaining issues from there on out.

The error you get in the screenshot makes only a little sense to me. It could be something similar to last year's stage3 issues, but at the same time, it doesn't seem to be mounting anything and pivot_root should never fail with something like that. Having the initrd's init script would help a lot in debugging the initrd if you can't remove it.

It could be something similar to last year's stage3 issues, but at the
same time, it doesn't seem to be mounting anything and pivot_root should never fail with something like that. Having the initrd's init script would help a lot in debugging the initrd if you can't remove it.

I checked that link and proceeded with appropriate action. Here goes some info:

I never used initrd-iscsi.img or related scripts. What exactly should i be looking for ?

I am also having another problem compiling some dependencies which they all some to lead to one package. dev-libs/glib which i cannot install from source of binary due to:

Code:

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.16... /usr/bin/pkg-config: error while loading shared libraries: libglib-2.0.so.0: cannot open shared object file: No such file or directory
no
checking for gawk... (cached) gawk
checking for perl5... no
checking for perl... perl
checking for indent... no
checking for perl... /usr/local/bin/perl
checking for iconv_open... yes
checking whether to cache iconv descriptors... no
checking for ZLIB... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for inflate in -lz... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for LIBFFI... no
configure: error: in `/var/tmp/portage/dev-libs/glib-2.30.3/work/glib-2.30.3':
configure: error: The pkg-config script could not be found or is too old. Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

Alternatively, you may set the environment variables LIBFFI_CFLAGS
and LIBFFI_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

To get pkg-config, see <http://pkg-config.freedesktop.org/>.
See `config.log' for more details

I have the whole install upgraded after doing emerge -e world and -e system while i keep udev compatible with the kernel and openrc.
ovh.net supplies their own flavour of useless custom kernels which i have not been able to to make work so far no matter what i download to the box and add to the bootloader i never see that kernel active for boot options.
I do however see other kernels on those boot options that do not exist in the box anywhere. (how is the company staying in business is beyond human understanding)

Their vKVMV options none works. Some present me a kernel that is not anywhere. Others boot a 32 bit kernel for a 64 bit install; Another boots the kernel if the hard drive is hda1 and not sda1 but fails to work with it.. and so on. vKVM option seems useless.
Their also have a boot from HD option that does nothing when active but their documentation says it works. (it does not. at max it allows to ping the box - nothing else happens from that boot option - no sshd, no access, nothing).

This now takes me to the initrd situation and maybe i am being a bit radical about what i am going to say but in all these years i have custom built many gentoos i never had the need of using that miserable option; specially on a server.

Suppose your root partition resides on some SCSI device and driver for this SCSI devices is compiled as a kernel module. Of course this module is required at boot time to have access to the root partion — but it is not in the kernel. Thus the need for an initrd image.
Additionally after udev subsystem become common, somebody has to start udev to create device nodes. This is initrd's duty too.

I confess that i don't know much about this initrd useless method but i always used my SCSI drivers built-in and everything always worked. Why complicate things on a server ? To get fisted ? Stupidity on boring setups ?

Anyway ... i really need help with this one as i confess my ignorant status regarding pre historic setups and mentalities.

I did try to boot once without initrd=/initrd-iscsi.img and the result was the same as always.
If i cannot extract it how can i create a new one ?_________________443640, Questioning, Unsolved, BinHost

Basically, remove the initrd and set the root option to boot from local disk. Remember to re-run lilo every time you change the config file; lilo isn't quite as modern as grub and the config file is read at install time, not at runtime.

If you actually need iscsi (I'm still not sure how that fits into your setup), worry about that later; get something bootable first.

As for extracting the initrd, just run `file initrd-iscsi.img` and see what it really is. It's probably compressed with bzip2 instead of gzip, but it might also be uncompressed. But you REALLY shouldn't extract it in your root directory; copy it somewhere else and extract it there. You might end up overwriting parts of your install with some broken crap from their initrd and that's never a good thing.

I tried changing those details before with debian and i had no luck.
I now ditched lilo and went for grub which gave me better news after a few fails but at least initrd misery is gone.

I can confirm over vKVM crap that grub gets loaded and boots the machine.
I was told by OVH tiny microsoft mind support that i could not use my kernel and that they supply the kernel but i did a couple tests.

First test downloaded vanilla sources and just made a kernel to see if it actually was used. I renamed it to look like the crap they provide and it turns out it was loaded but with lots of errors.

For the second try; i used one of their kernels and the error i got helps understanding lilo's error too.

CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFS_USE_NEW_IDMAPPER is not set
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y

Why is this needed like this by default ? Anyone has an acceptable answer?

Now i am going to try to recompile a kernel without this and see if i can actually use my own kernel or not.

If there is any bootloader parameter that prevents the attempt of mounting root fs over the network, it would be great to use it to see if the problem gets solved.

So here it goes... kimmie...
I got to land; killed the cannibals ... and got girl.

But before that

I tried a fast compiled generic kernel compiled: failed
I tried one their 2.6 kernels and booted it with grub: failed
Tried to recompile that kernel without NFS support: failed
Fetched one of their 3.2 kernels, renamed to a 2.6 kernel that they allow me to boot from (select menu) the machine menu "name" options.

Then i basically fell asleep on the keyboard, woke up, fast forward a crappy movie went on irc and saw that an eggdrop that i had left on the box ready to connect to irc in case the box was up; WAS UP.

The install is up and running, i was able to connect by telnet (backup login) since sshd was down. Now i am going for the gold.

Persistency; consistency and in this case 2 middle fingers to ovh.net for giving their clients 2007 operating systems installations in 2012. (now that is service excellency!!)

NOOO, don't kill the cannibals, they're SO CUTE... anyway, sounds like you didn't really kill them, you just updated their asses into 2012. Congrats! I never would have persisted with that update... once I got stuck in Xen hell with a VPS provider who couldn't understand why my domU kernel needed to be able to see domU kernel modules in the domU filesystem; I just gave up and found me a new girl.

HeXiLeD, I admire your patience and determination, really. Your reward is probably to now be able to open and maintain yourself a global hosting service and yet provide a much better support than these ass-holes.

I have just noticed one question about the need for an initrd in all of these years of Gentoo and that you weren't feeling comfortable with it. In fact I'd say the only one case Gentoo needs an initrd (on a headless server, basically) is when the root file system doesn't reside on a partition on the local disk, e.g. on LVM, on NFS or iSCSI. I haven't experimented the latter two however, only LVM.

Reading your posts I also learnt how to boot from NFS. So you might find this explanation interesting. As far as I have understood, booting from NFS is not automatic unless there's a kernel option, nfsroot along with root=/dev/nfs. But maybe these command line options are built into the kernel for I know it's possible with recent kernels.

Well I guess it's a bit late but I just wanted to add my 0.5¢ in case you still want to know._________________Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
GNU/Linux user #369763
“Wow! I feel root”

Just thought about updating this topic with the latest that OVH has done to me.
After everything that is described above and finally being able to make the server working; they closed my service 2 weeks ago.

But not only the service was closed.

- I cannot access my account as my user and password are now invalid.
- The service was paid until December 2013. (5 more months)
- They emailed me a receipt that is under another name/user and the account identification is not mine
- They have not reimbursed me for the remaining 5 months