Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


BTRFS on OVH Dedicated, is it possible?
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.

BTRFS on OVH Dedicated, is it possible?

Hey guys,

In the OVH images provided, I'm not able to select BTRFS as a partition type.

If I try to use my custom image, it asks for a cloud ready image.

Is there no option to install from ISO and connect over VNC and configure it to use BTRFS? I have a server on naranja.tech and their panel allowed me to do that. Does OVH not allow this?

Is there another method? Or do I need to learn to make a custom cloud image in qcow2 with btrfs setup and upload that? How would I go about that?

Additional information on why I like BTRFS, snapshots, copy on write, can send full snapshots to other places for a total backup with snapshots including original data, subvolumes, few other features.

Thank you.

«1

Comments

  • ralfralf Member
    edited November 2022

    You can always boot to the rescue image and format the disk however you like.

    You will need to know exactly what you're doing as you'll probably end up having to use debootstrap to install debian on it, for example.

    I did exactly that last year (but not with btrfs) because I wanted a custom LVM setup with some partitions striped and others mirrored.

    Thanked by 1stoned
  • So I can partition it how I want using rescue mode, then grab debootstrap and do a low level full install? That's fine. Just a bit more work, but that's fine.

    Is there any way to do any ISO install? Or partition how you want and then use an image to install on top of that?

  • darkimmortaldarkimmortal Member
    edited November 2022

    If this is a Kimsufi without ipmi, you can do a custom install using qemu in rescue mode with the physical disks attached directly, lots of guides out there

    Thanked by 1AXYZE
  • Why not to use KVM? Just mount ISO and install whatever you wish.

  • @stoned said:
    So I can partition it how I want using rescue mode, then grab debootstrap and do a low level full install? That's fine. Just a bit more work, but that's fine.

    Is there any way to do any ISO install? Or partition how you want and then use an image to install on top of that?

    No, not an image. debootstrap is how you install debian on a new partition - it's the tool that the installers use themselves. You should google how it works, before deciding if this is a good idea for you, as it's a bit of a learning curve if you've not done it before.

    What I did last year is just install a very minimal system in the root partition, and then run multiple virtual machines on it. I guess if you really want to do a ISO install, that's probably your easiest route to that.

  • @ralf said:

    @stoned said:
    So I can partition it how I want using rescue mode, then grab debootstrap and do a low level full install? That's fine. Just a bit more work, but that's fine.

    Is there any way to do any ISO install? Or partition how you want and then use an image to install on top of that?

    No, not an image. debootstrap is how you install debian on a new partition - it's the tool that the installers use themselves. You should google how it works, before deciding if this is a good idea for you, as it's a bit of a learning curve if you've not done it before.

    What I did last year is just install a very minimal system in the root partition, and then run multiple virtual machines on it. I guess if you really want to do a ISO install, that's probably your easiest route to that.

    I'm familiar with debootstrap. I was just curious if I could partition it myself and use an image on top to automate the os install, but if that's not possible I can do debootstrap a new system, I've done it a few times. Just never on a server, but it should be the same.

  • @darkimmortal said:
    If this is a Kimsufi without ipmi, you can do a custom install using qemu in rescue mode with the physical disks attached directly, lots of guides out there

    This is the one, yes. KS-LE-1 and says no IPMI present.

    So go into rescure mode, partition how I want, then and use qemu and install an image no top?

    Please verify if I understood correctly. I'm also new to a lot of this dedicated server stuff. My apologies if I don't understand yet, I'm still learning.

    Thanks :)

  • @CalmDown said:
    Why not to use KVM? Just mount ISO and install whatever you wish.

    I'm not sure I follow, what do you mean? Without IPMI in KS-LE-1 how may I do this? Is this through rescure mode or via their panel somehow?

  • @stoned said:

    @darkimmortal said:
    If this is a Kimsufi without ipmi, you can do a custom install using qemu in rescue mode with the physical disks attached directly, lots of guides out there

    This is the one, yes. KS-LE-1 and says no IPMI present.

    So go into rescure mode, partition how I want, then and use qemu and install an image no top?

    Please verify if I understood correctly. I'm also new to a lot of this dedicated server stuff. My apologies if I don't understand yet, I'm still learning.

    Thanks :)

    https://nicolas.busseneau.fr/en/blog/2021/07/ovh-soyoustart-install-iso-image

    Thanked by 2stoned ralf
  • https://lowendtalk.com/discussion/118255/install-windows-on-dedibox-xc-ssd-2016-with-qemu

    You can follow this guide, it will work (... of course you'll have to adjust various parameters for your specific server). However, because crap models like the KS1 lack Virtualization capabilities, it will take looooooong hours to install stuff that way.

  • I guess I can just debootstrap a minimal system myself, would be good practice too. That way I can customize it how I want. Debian install is I think just shell scripts to facilitate debootstrap. One can do all those tasks manually.

  • @Shot2 said:
    https://lowendtalk.com/discussion/118255/install-windows-on-dedibox-xc-ssd-2016-with-qemu

    You can follow this guide, it will work (... of course you'll have to adjust various parameters for your specific server). However, because crap models like the KS1 lack Virtualization capabilities, it will take looooooong hours to install stuff that way.

    Oh ok, I'll peek it over. Thanks

  • Oh, didn't know you could mount an ISO, although thinking about it, one other thing you can do is boot into rescue, format the partitions and stick the ISO somewhere on the disk. Then you could mount it using -o loop and install from it that way.

  • rm_rm_ IPv6 Advocate, Veteran

    @ralf said: Oh, didn't know you could mount an ISO, although thinking about it, one other thing you can do is boot into rescue, format the partitions and stick the ISO somewhere on the disk. Then you could mount it using -o loop and install from it that way.

    That's not quite how this works. You run a virtual machine on the server, which has the ISO inserted as its CD-ROM, and then has both of the actual drives as its HDDs. As such, "somewhere on disk" is no go, disks are all under the VM's control. So it's just stored in tmpfs (RAM disk). And no actual ISO mounting occurs on the host.

    And yeah, installing that way should be much less involved than debootstrap. Don't have to take care about the bootloader manually, and such. One thing to look for, is that network interfaces inside the install VM may (and likely will) have different names and MAC addresses, than in the final installed system when that boots on the actual machine itself.

    Thanked by 1stoned
  • stonedstoned Member
    edited November 2022

    @rm_ said:

    @ralf said: Oh, didn't know you could mount an ISO, although thinking about it, one other thing you can do is boot into rescue, format the partitions and stick the ISO somewhere on the disk. Then you could mount it using -o loop and install from it that way.

    That's not quite how this works. You run a virtual machine on the server, which has the ISO inserted as its CD-ROM, and then has both of the actual drives as its HDDs. As such, "somewhere on disk" is no go, disks are all under the VM's control. So it's just stored in tmpfs (RAM disk). And no actual ISO mounting occurs on the host.

    And yeah, installing that way should be much less involved than debootstrap. Don't have to take care about the bootloader manually, and such. One thing to look for, is that network interfaces inside the install VM may (and likely will) have different names and MAC addresses, than in the final installed system when that boots on the actual machine itself.

    Nice thanks. I just read it and realized how it works. Essentially it's a V2P configuration.

    You install virtualization, mount both drives in it, get an ISO, load ISO in your virt (kvm/qemu), and install on the drives you passed through to the VM, install your OS, and then basically boot that on the physical hardware, it should be like normal, and you're saying take care about the NIC as that would install it on a virtual NIC or just with diff identifiers?

    Any idea how one might solve the differenly MAC'd and Named NIC in this install method?

    So when you reboot, networking may not work due to diff NIC name/config. So how would you get into the server? So for that, any solution to this?

    Sorry for noob questions.

  • How does one go about making a qcow image with custom partition schema? So we can just use a custom image option and upload the image and done.

  • darkimmortaldarkimmortal Member
    edited November 2022

    @stoned said:

    @rm_ said:

    @ralf said: Oh, didn't know you could mount an ISO, although thinking about it, one other thing you can do is boot into rescue, format the partitions and stick the ISO somewhere on the disk. Then you could mount it using -o loop and install from it that way.

    That's not quite how this works. You run a virtual machine on the server, which has the ISO inserted as its CD-ROM, and then has both of the actual drives as its HDDs. As such, "somewhere on disk" is no go, disks are all under the VM's control. So it's just stored in tmpfs (RAM disk). And no actual ISO mounting occurs on the host.

    And yeah, installing that way should be much less involved than debootstrap. Don't have to take care about the bootloader manually, and such. One thing to look for, is that network interfaces inside the install VM may (and likely will) have different names and MAC addresses, than in the final installed system when that boots on the actual machine itself.

    Nice thanks. I just read it and realized how it works. Essentially it's a V2P configuration.

    You install virtualization, mount both drives in it, get an ISO, load ISO in your virt (kvm/qemu), and install on the drives you passed through to the VM, install your OS, and then basically boot that on the physical hardware, it should be like normal, and you're saying take care about the NIC as that would install it on a virtual NIC or just with diff identifiers?

    Any idea how one might solve the differenly MAC'd and Named NIC in this install method?

    So when you reboot, networking may not work due to diff NIC name/config. So how would you get into the server? So for that, any solution to this?

    Sorry for noob questions.

    I keep net.ifnames=0 biosdevname=0 in my boot command line on Kimsufi for exactly this reason

    Thanked by 3ralf rm_ Maounique
  • @stoned said:

    Sorry for noob questions.

    1. Boot your Kimsufi in rescue mode (e.g. old Ubuntu)
    2. Once in rescue mode, take note somehow of the real interface name (e.g. enp2s5)
    3. Perform the Qemu/ISO install from within the rescue mode
    4. Once the Qemu/ISO install completes, let it (virtually) reboot into the fresh OS
    5. Edit the config file, replace the (virtual) interface name with the real one (e.g. enp2s5)
    6. Shutdown the OS: it stops Qemu. Exit the rescue mode. Reboot the Kimsufi.
  • stonedstoned Member
    edited November 2022

    @Shot2 said:

    @stoned said:

    Sorry for noob questions.

    1. Boot your Kimsufi in rescue mode (e.g. old Ubuntu)
    2. Once in rescue mode, take note somehow of the real interface name (e.g. enp2s5)
    3. Perform the Qemu/ISO install from within the rescue mode
    4. Once the Qemu/ISO install completes, let it (virtually) reboot into the fresh OS
    5. Edit the config file, replace the (virtual) interface name with the real one (e.g. enp2s5)
    6. Shutdown the OS: it stops Qemu. Exit the rescue mode. Reboot the Kimsufi.

    Thank you. The nic reported by ip a is just eth0 in rescue-mode. Usually they are named like enp7s0 etc. etc. but this is just called eth0.

    That look right?

    Linux rescue ovh.net 5.15.55-mod-std SMP Thu Sep 29 07:59:14 UTC 2022 x86_64 GNU/Linux

  • @Shot2 said:

    @stoned said:

    Sorry for noob questions.

    1. Boot your Kimsufi in rescue mode (e.g. old Ubuntu)
    2. Once in rescue mode, take note somehow of the real interface name (e.g. enp2s5)
    3. Perform the Qemu/ISO install from within the rescue mode
    4. Once the Qemu/ISO install completes, let it (virtually) reboot into the fresh OS
    5. Edit the config file, replace the (virtual) interface name with the real one (e.g. enp2s5)
    6. Shutdown the OS: it stops Qemu. Exit the rescue mode. Reboot the Kimsufi.

    This is one of the sources of the problem.

    The NIC appears with a different device name under rescue compared to a normal boot.

    @darkimmortal said:
    I keep net.ifnames=0 biosdevname=0 in my boot command line on Kimsufi for exactly this reason

    I wish I'd known this last year, would have saved me a bit of head scratching!

  • With some OSes, you may (?) also find the "real" interface name in the boot logs (syslog and the such). Be creative.

  • SaahibSaahib Host Rep, Veteran

    @ralf
    Try following to get predictable network name :

    udevadm info --path=/sys/class/net/eth0 | grep ID_NET_NAME_PATH
    
    Thanked by 1ralf
  • @Saahib said:
    @ralf
    Try following to get predictable network name :

    udevadm info --path=/sys/class/net/eth0 | grep ID_NET_NAME_PATH
    

    Looks useful in that it's mapping eth0 to something else, but on my KS-LE-1, I don't have eth0 I have eno1, but when I boot the rescue image, then I do have eth0.

    But there might be something in it, but for now I've just learned to accept that this machine is different to all my others...

  • when you install a modern ISO on your KS1, edit the interface config and use eno1 then.

    Their rescue system is always outdated, it uses old ethX names.

  • @Shot2 said:
    when you install a modern ISO on your KS1, edit the interface config and use eno1 then.

    Their rescue system is always outdated, it uses old ethX names.

    Even if you will change the interface config manually it won't fix the problem, it won't boot up.

  • @CalmDown said:

    @Shot2 said:
    when you install a modern ISO on your KS1, edit the interface config and use eno1 then.

    Their rescue system is always outdated, it uses old ethX names.

    Even if you will change the interface config manually it won't fix the problem, it won't boot up.

    So even if you get the correct iface name it still won't boot up?

  • @stoned said:

    @CalmDown said:

    @Shot2 said:
    when you install a modern ISO on your KS1, edit the interface config and use eno1 then.

    Their rescue system is always outdated, it uses old ethX names.

    Even if you will change the interface config manually it won't fix the problem, it won't boot up.

    So even if you get the correct iface name it still won't boot up?

    Exactly.

  • Shot2Shot2 Member
    edited November 2022

    @CalmDown said:

    @Shot2 said:
    when you install a modern ISO on your KS1, edit the interface config and use eno1 then.

    Their rescue system is always outdated, it uses old ethX names.

    Even if you will change the interface config manually it won't fix the problem, it won't boot up.

    Of course it will. Tested on Dedibox crap Avotons, as well as on good ol' Atom KS...

  • CalmDownCalmDown Member
    edited November 2022

    @Shot2 said:

    @CalmDown said:

    @Shot2 said:
    when you install a modern ISO on your KS1, edit the interface config and use eno1 then.

    Their rescue system is always outdated, it uses old ethX names.

    Even if you will change the interface config manually it won't fix the problem, it won't boot up.

    Of course it will. Tested on Dedibox crap Avotons, as well as on good ol' Atom KS...

    I just test on Kimsufi. Don't work, tried DHCP / static configuration and was using eno1 / enp0s25 as interface.

  • Shot2Shot2 Member
    edited November 2022

    @CalmDown said:

    @Shot2 said:

    @CalmDown said:

    @Shot2 said:
    when you install a modern ISO on your KS1, edit the interface config and use eno1 then.

    Their rescue system is always outdated, it uses old ethX names.

    Even if you will change the interface config manually it won't fix the problem, it won't boot up.

    Of course it will. Tested on Dedibox crap Avotons, as well as on good ol' Atom KS...

    I just test on Kimsufi. Don't work, tried DHCP and static configuration and was using eno1 / enp0s25 and interface.

    "I screwed something up" does not equate "it don't work" ;)

    Tested by myself on both KS and Dediboxes, many more times than I can count, to install Debian 9/10/11 through qemu. It's painfully slow on the N2800 Atoms (20+ hours... thank Gawd for 'screen'), but it definitely works :sweat_smile:

    edit: oh and in case of screwup (or if you hastily forgot to edit the net config), it's easy to correct afterwards; just repeat the operation from rescue, booting from disk - or even from the ISO then launching a shell - then check the boot logs and fix stuff accordingly.

Sign In or Register to comment.