Announcement

Collapse
No announcement yet.

BTRFS again: This time? Let's upgrade!

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    BTRFS again: This time? Let's upgrade!

    Search btrfs on this forum and my name will come up - a lot! Here's my latest entry into the btrfs catalog of tools;

    Defensive upgrading using btrfs subvolume snapshots

    As I have noted before: I usually don't upgrade, rather, I do a full install of the new version of Kubuntu in parallel (along side) my current install. In my view, this prevents me from leaving my computer un-bootable in case of a total failure of the upgrade and it ensures I don't drag some old edits or settings along that are improper for the newest version. I have also often complained about the continual failure of Ubiquity (our installer) in many situations. Often, on my older desktop (circa 2006) and complicated setup (4 hard drives and an SSD) Ubiquity just can't get the job done.

    Enter btrfs and subvolume snapshots:

    I am currently running 13.04 from a 212GB btrfs filesystem. The same filesystem also holds my older 12.10 install, a Neptune 3.1 install, a dedicated install to manage grub for me, and two homes - one for 12.10 and another for 13.04. These "separate" locations are not partitions, rather they are subvolumes. I will be speaking about subvolumes throughout this text and may leave off the word subvolume in most instances for brevity, so don't let that confuse you.

    Here's my current subvolume list:

    Code:
    root@office:/mnt/sda# btrfs subvolume list /mnt/sda
    ID 258 gen 654214 top level 5 path @grub
    ID 261 gen 658686 top level 5 path @Kubuntu_12_10_home
    ID 262 gen 640640 top level 5 path @Kubuntu_12_10
    ID 306 gen 658923 top level 5 path @Kubuntu_13_04
    ID 307 gen 658923 top level 5 path @Kubuntu_13_04_home
    ID 400 gen 640465 top level 5 path @Neptune_31_home
    ID 401 gen 640465 top level 5 path @Neptune_31
    I have played a bit with snapshots in the past, but not used them to their full extent. Snapshots are like frozen moments in time for a filesystem. Snapshots are not backups in the true sense of the word: if a file that exists in the source filesystem gets corrupted or damaged, it will also be corrupted or damaged in the snapshot. A btrfs snapshot begins life with no data of it's own - it not a duplicate of the source. However, as you amend your filesystem (add, amend and subtract files) the snapshot grows. Each deleted file is not actually deleted, rather it's location pointer is removed from the source subvolume but left in the snapshot. So deleting a file doesn't actually delete it at all - it's just changes from the source subvolume to the target (snapshot) subvolume. Eventually, if you changed or deleted every file in a subvolume, the snapshot would grow to the size of the original source subvolume.

    What's the point of this?

    Well, you can use this in several ways. The most common way might be to "rollback." Say you want to try out a new program that requires many new libraries and compiling, but you aren't sure it's going to be safe. So you make a snapshot before installing it. Then, after installing and testing you decide it's OK: Simply delete the snapshot. If it's not OK: Delete the source, rename the snapshot to the sources name, reboot, and you're right back where you began. Also it's great for protection from oneself. You could have a cron job that makes a daily snapshot of your home and deletes snapshots more than a week old. Then you'd have a whole week to go back and recover a file you may have deleted and changed your mind about. Neat!

    Enter the impending death of support for my current install!

    OK, so the above title is a little over-dramatic. Support for 13.04 ends soon so I must upgrade or face the end of updates and the like. No time to do it like the present. Upgrading, rather than my usual new install, also avoids the potential Ubiquity messes. The only question is do I trust the upgrade? No need to worry: Let the snapshotting begin! PLEASE NOTE: btrfs commands, like any filesystem command, require root privileges. Rather than typing "sudo" a ba-zillion times, I opted to use "sudo -i" so I could just be root for awhile.

    First, I make snapshots of my home and root directories. The btrfs filesystem I'm working on is on /dev/sda2. The "Top Level" holds all the subvolumes in the filesystem. To make things a bit easier, I mounted the "Top Level" to /mnt/sda and cd'd into it to do the snapshotting. I want the snapshots to have useful names, so I added the date and time to the name of the original subvolume in this format: yymmddhhmmss. Today is Jan. 20th, 2014 and it's 10:56 am.

    Code:
    root@office:/mnt/sda# btrfs subvolume snapshot /mnt/sda/@Kubuntu_13_04_home/ /mnt/sda/@Kubuntu_13_04_home_140120105600
    Create a snapshot of '/mnt/sda/@Kubuntu_13_04_home/' in '/mnt/sda/@Kubuntu_13_04_home_140120105600'
    
    root@office:/mnt/sda# btrfs subvolume snapshot /mnt/sda/@Kubuntu_13_04/ /mnt/sda/@Kubuntu_13_04_140120105600
    Create a snapshot of '/mnt/sda/@Kubuntu_13_04/' in '/mnt/sda/@Kubuntu_13_04_140120105600'
    and now my list of subvolumes looks like this:

    Code:
    root@office:/mnt/sda# btrfs subvolume list /mnt/sda
    ID 258 gen 654214 top level 5 path @grub
    ID 261 gen 658686 top level 5 path @Kubuntu_12_10_home
    ID 262 gen 640640 top level 5 path @Kubuntu_12_10
    ID 306 gen 658923 top level 5 path @Kubuntu_13_04
    ID 307 gen 658923 top level 5 path @Kubuntu_13_04_home
    ID 400 gen 640465 top level 5 path @Neptune_31_home
    ID 401 gen 640465 top level 5 path @Neptune_31
    ID 484 gen 658922 top level 5 path @Kubuntu_13_04_home_140120105600
    ID 485 gen 658923 top level 5 path @Kubuntu_13_04_140120105600
    A check of total space used confims very little additional space was used when creating the snapshots:

    Before snapshots:
    Code:
    root@office:~# btrfs filesystem df /mnt/sda
    Data: total=212.45GB, used=162.51GB
    System, DUP: total=8.00MB, used=28.00KB
    System: total=4.00MB, used=0.00
    Metadata, DUP: total=5.00GB, used=1.86GB
    Metadata: total=8.00MB, used=0.00
    After snapshots:
    Code:
    root@office:/mnt/sda# btrfs filesystem df /mnt/sda/
    Data: total=212.45GB, used=162.56GB
    System, DUP: total=8.00MB, used=28.00KB
    System: total=4.00MB, used=0.00
    Metadata, DUP: total=5.00GB, used=1.87GB
    Metadata: total=8.00MB, used=0.00
    and to verify my version:
    Code:
    stuart@office:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 13.04
    Release:        13.04
    Codename:       raring
    Now, on to the upgrade!

    added at 4:58 pm
    UPGRADE UP AND RUNNING.


    I'm going to test 13.10 for awhile before I commit. The next step in this adventure will be booting back into 12.10 using only the snapshot. Here's the new df report:
    Code:
    root@office:~# btrfs filesystem df /mnt/sda
    Data: total=212.45GB, used=169.76GB
    System, DUP: total=8.00MB, used=28.00KB
    System: total=4.00MB, used=0.00
    Metadata, DUP: total=5.00GB, used=2.33GB
    Metadata: total=8.00MB, used=0.00
    So you can see about 7GB has been added by the release-upgrade. Obviously, the subvolume is still named 13_04 but my OCD can put up with that for a bit longer.

    OK - A few days later...

    01/23 at 4:50pm
    The version upgrade has gone well.
    Code:
    root@office:~# lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 13.10
    Release:        13.10
    Codename:       saucy
    I've run several updates and installed a couple things so my drive space now looks like:
    Code:
    root@office:~# btrfs filesystem df /mnt/sda
    Data: total=212.45GB, used=173.97GB
    System, DUP: total=8.00MB, used=28.00KB
    System: total=4.00MB, used=0.00
    Metadata, DUP: total=5.00GB, used=2.38GB
    Metadata: total=8.00MB, used=0.00
    Time to test, so this afternoon I added the snapshot to my grub menu and booted to it.

    It booted up fine without problems! The only thing I noticed immediately was it did not load the nvidia driver. It didn't take me long to surmise that when I did the update, the process removed the nvidia driver from the kernel in use and does not install dkms or the driver during the upgrade. When the upgrade was finished, it left me the old 3.8 kernel from 13.04 and the new 3.11 kernel from 13.10. Apparently, the snapshot function does not protect the presence of the nvidia taint in the kernel within the snapshot. This is not a deal breaker, but it is worth noting. I've kept the snapshot for now for further testing. I may attempt re-installing the nvidia driver from within the snapshot just to see if anything breaks.
    Last edited by oshunluvr; Jan 23, 2014, 07:15 PM.

    Please Read Me

    #2
    I've been watching the btrfs like a bird watches a fat, juicy night crawler! This is a big one!

    I've been planning on testing and installing the 14.04 release, if its ath9k driver drives my AR9462 Wireless Network Adapter and its i915 driver syncs my video at 60fps. If it does I want to try out the btrfs.

    I look forward to your next post!
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    Comment


      #3
      I'm using ext4 on both laptops. I have no RAID. I make clone backups to external USB HDD for both laptops. Is there any reason I should not move to btrfs? Would there be any real benefit for me; any downside if I did move to btrfs?
      Using Kubuntu Linux since March 23, 2007
      "It is a capital mistake to theorize before one has data." - Sherlock Holmes

      Comment


        #4
        I used wget to download and noticed something I don't recall ever seeing before ... the use of IPv6 for download of Kubuntu isos.

        :~/Downloads$ wget http://cdimage.ubuntu.com/kubuntu/da...ktop-amd64.iso
        --2014-01-20 17:07:23-- http://cdimage.ubuntu.com/kubuntu/da...ktop-amd64.iso
        Resolving cdimage.ubuntu.com (cdimage.ubuntu.com)... 2001:67c:1360:8c01::1f, 2001:67c:1360:8c01::20, 2001:67c:1360:8c01::21, ...
        Connecting to cdimage.ubuntu.com (cdimage.ubuntu.com)|2001:67c:1360:8c01::1f|:80... connected.
        HTTP request sent, awaiting response... 200 OK
        Length: 1077739520 (1.0G) [application/x-iso9660-image]
        Saving to: `trusty-desktop-amd64.iso'
        ...
        Now to see if Trusty Tahr honors my video and wifi chips...

        EDIT: Woooo!!! Tahr drives my video AND my wifi chip very nicely. Now, on to the install.
        Last edited by GreyGeek; Jan 21, 2014, 12:31 PM.
        "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
        – John F. Kennedy, February 26, 1962.

        Comment


          #5
          I've done the upgrade to 13.10 (posting from it now) and doing some testing so far so good. I'll update the OP when I have details to report. I want to test the ability to boot into the old version.

          Snowhog: As far as the good vs. bad for laptop users. My opinion only, of course. Actually this would apply to any single-disk users. Unless you are multi-booting or want the subvolume/snapshot features there's probably not much advantage at this time. btrfs really shines in multi-disk setups but is very useful for cases like this during an upgrade or if you're installing several distros to the same filesystem. Since btrfs does not require drive space segregation (partitioning) all your free space is available to all your subvolumes all the time. I suppose if you had a really small or mostly full disk, this would be a very serious advantage. The latest updates to btrfs are showing performance on-par or exceeding ext4 in some cases but I doubt there's any notable real-world difference.

          Clearly, the biggest advantage is the multi-disk features: Adding and subtracting volumes (drives) on the fly (yes, while mounted and in use!) and the easiest RAID setups in the world. Managing a server disk array is now a total piece of cake.

          One area in which btrfs is current not recommended is swap files or dynamically expanding virtual hard discs. The nature of these files can cause very slow performance or even corruption when using btrfs. Simple enough to have a swap partition and fixed size virtual drives.

          Jerry: I'm sure you know Don (dibl) and I have been full time btrfs users for almost four years now. It's the easiest filesystem to use by far. Really, the biggest hurdle is the installers. AFAIK, only Ubiquity does a decent job with btrfs. It automatically puts your /home into a subvolume named @home. I inquired with the maintainers about letting us input our own subvolume names (perfect for multiple installs) but they weren't interested. I have to manually rename the subvolumes after every install if I'm doing a dual-boot (or more) install.

          Please Read Me

          Comment


            #6
            That's good info to know. I'm going to partition out 100GB of my HD and install Tahr as a third bootable OS. Will I encounter any problems making btrfs the file system of that partition when the other two are NTFS and EXT4?
            "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
            – John F. Kennedy, February 26, 1962.

            Comment


              #7
              Originally posted by GreyGeek View Post
              That's good info to know. I'm going to partition out 100GB of my HD and install Tahr as a third bootable OS. Will I encounter any problems making btrfs the file system of that partition when the other two are NTFS and EXT4?
              No, none at all. My server still has ext4 partitions on two of the drives along side the btrfs partitions and my SSD on my desktop has a swap partition on it.

              I also have btrfs occupying the entire drive on 6 of my drives. It's a little odd feeling to use sudo mkfs.btrfs /dev/sdc rather than sdc1, but that's how you do it. Another oddity is mounting. If you mount the partition directly you'll see all the subvolumes on it. But you normally don't do that. You would mount each subvolume individually so only the subvolume contents are accessable. You use subvol= in the mount command (or in fstab) to mount the subvolume. Subvolumes can only be mounted this way if they are created in the root fs. Nested subvolumes have to be mounted with the ID number via subvolid= instead.

              If you really wanted some data privacy, you could create home subvolumes for each user and mount only their own at log in.

              The first thing you'll notice when you create a btrfs filesystem is it happens almost instantly - no long drawn out block counts. Ubiquity has auto-created the btrfs subvolumes since 12.10. After install you'll have subvolumes named @ and @home. Since I multi-boot, I renamed mine to @Kubuntu_12_10 and @Kubuntu_12_10_home and edited grub.cfg manually so I could boot into it the first time. Subsequently, update-grub detects and uses the correct subvolume labels. After that, I was able to install 13.04 to the same btrfs filesystem (with format UNchecked obviously). With the second install, I renamed the subvolumes as above but with 13_04 and ran update-grub to boot into it. Worked like a charm. If you wanted to install another version or distro in the same filesystem, just re-name the Tahr subvolumes and run update-grub first.

              The only road block I've come across using btrfs is I could not get the filesystem to expand to fill a partition that I enlarged. In other words, I was able to expand the partition but not the filesystem within it. It seems the documentation says you can, but I couldn't get it to work. I don't know if I did something wrong (like leaving out a step) or what. I eventually gave up and re-created the filesystem from scratch.

              You can have fun exploring the options with subvolume nesting and snapshots. My system needs are rather simple, so I haven't spent time make it too complicated.

              BTW, the folder structure works exactly the same as you're used to. Subvolumes are an added feature that you really don't have to use at all if you don't want to and you can have a subvolume at the same level as a folder - mix and match.
              Last edited by oshunluvr; Jan 21, 2014, 03:01 PM.

              Please Read Me

              Comment


                #8
                Originally posted by oshunluvr View Post
                I'm sure you know Don (dibl) and I have been full time btrfs users for almost four years now. It's the easiest filesystem to use by far.
                My btrfs filesystem, originally installed in 2010, is a single filesystem on a pair of WD1002FAEX SATA drives (6Gb/s). It holds ~950GB of user data -- my music, photos, documents, backups of VMs, etc. I think it was about a year ago that one of the WD drives gave me a couple of errors, which was all it took to spook me into buying another pair of the same model, making the new btrfs filesystem across them, and restoring my latest backup. So for about 12 months it has run drama-free, 24/7. Once in a fairly long while (like 4 months) I run btrfsck on it, but it never finds any issues. Here's what I see from the command line:

                Code:
                root@imerabox:/# btrfs fi df /mnt/DATA
                Data, RAID0: total=986.00GiB, used=945.61GiB
                Data, single: total=8.00MiB, used=6.28MiB
                System, RAID1: total=8.00MiB, used=76.00KiB
                System, single: total=4.00MiB, used=0.00
                Metadata, RAID1: total=3.00GiB, used=1.68GiB
                Metadata, single: total=8.00MiB, used=0.00
                The snapshot capability is not something I have made use of -- I simply grab a spare 1TB drive periodically and dump the entire volume onto it for a backup. For folks who multi-boot OSs, I would love to see a Linux installer that would allow creation of a btrfs filesystem with subvolumes, and allow the user to select a subvolume for installation. It is possible to do this now:

                http://forum.siduction.org/index.php?topic=4191.0

                But it's far from easy or obvious. For me, with a single OS on a SSD, the dual-drive btrfs filesystem is a great solution to a large pile of data that needs a home where I can get to it quickly.
                Last edited by dibl; Jan 22, 2014, 05:08 AM.

                Comment


                  #9
                  "I'm back in the saddle again, back where a friend is a friend ......" (Anyone remember Gene Autry, the "Singing Cowboy"?)
                  "I'm baaaaaaaaaaaaaack!" - The Terminator.

                  Kubuntu 14.04 is now on my Acer V3-771G, with btrfs as the filing system!
                  jerry@jerry-Aspire-V3-771:~$ sudo btrfs fi df /
                  Data, single: total=4.01GiB, used=3.62GiB
                  System, DUP: total=8.00MiB, used=16.00KiB
                  System, single: total=4.00MiB, used=0.00
                  Metadata, DUP: total=1.00GiB, used=149.64MiB
                  Metadata, single: total=8.00MiB, used=0.00
                  jerry@jerry-Aspire-V3-771:~$
                  Looking forward to learning how to maximize the benefits of btrfs!
                  BTW, Kubuntu 14.04 is AWESOME, and so is KDE 12.1

                  The only "nit" I saw during the install was when I was welcomed to "Kubuntu 13.10", while the gray column to the left was titled "Kubuntu 14.04". Other than that the install was perfect and fast.
                  "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                  – John F. Kennedy, February 26, 1962.

                  Comment


                    #10
                    OP updated.

                    Please Read Me

                    Comment


                      #11
                      Originally posted by oshunluvr View Post
                      ......
                      One area in which btrfs is current not recommended is swap files or dynamically expanding virtual hard discs. The nature of these files can cause very slow performance or even corruption when using btrfs. Simple enough to have a swap partition and fixed size virtual drives.
                      I didn't install a swap drive because with 6GB of RAM I haven't seen the swap drive used in several years, even when editing video files.
                      Expanding virtual HDs? Ummm... Now you tell me! While I hadn't used by virtual XP installation for anything in the last two or three years, I decided to install it to see how it runs under 14.04?KDE 4.12.1 and the 3.13 kernel. VirtualBox with dkms & guest additions installed nicely and my guest OS, XP SP3, took right off and ran beautifully. But, you say, IF I add enough to it to cause it to expand btrfs may corrupt the virtual HD? Glad I have a backup!

                      Originally posted by oshunluvr View Post
                      Jerry
                      Originally posted by oshunluvr View Post
                      : I'm sure you know Don (dibl) and I have been full time btrfs users for almost four years now. It's the easiest filesystem to use by far. Really, the biggest hurdle is the installers. AFAIK, only Ubiquity does a decent job with btrfs. It automatically puts your /home into a subvolume named @home. I inquired with the maintainers about letting us input our own subvolume names (perfect for multiple installs) but they weren't interested. I have to manually rename the subvolumes after every install if I'm doing a dual-boot (or more) install.
                      I wasn't aware that btrfs automatcially created @home. (In fact, I wasn't "aware" of anything about btrfs, other than reading generaly descriptions and benchmarks.) I had KWheezy installed in a logical drive. When I installed Kubuntu 14.04 I deleted swap partition in extended partition, deleted KWeezy in the same extended partion and deleted the extended partition. Then I created primary partition 4 and gave it all to Kubuntu 14.04 with btrfs. Here is the result:
                      Code:
                      :~$ sudo btrfs subvolume list /
                      .....
                      ID 257 gen 3580 top level 5 path @
                      ID 258 gen 3582 top level 5 path @home
                      :~$
                      Now, from what you wrote I imagine that I can do something like
                      btrfs subvolume snapshot /@home/ /@home_yyyymmddhhmm
                      and that will create my snapshot, even as I am in /@home

                      EDIT:
                      I found this about virtual disks in btrfs https://btrfs.wiki.kernel.org/index.php/UseCases
                      Can we create virtual block device in BTRFS?

                      No. Btrfs doesn't support the creation of virtual block devices or other non-btrfs filesystems within its managed pool of space.
                      If you use file-backed storage for virtual machines, set those files nocow with `chattr +C`, see FAQ#Can copy-on-write be turned off for data blocks?. Otherwise you will get poor performance and fragmentation
                      So there is a workaround for virtual disks used by VBox, IF I am reading that right? I ask because I used "chattr +C on my three vbox WinXP files but the permission listings show no change.

                      EDIT-EDIT:
                      I answered my own question. "chattr +C somefile" only stops CoW IF it is applied to the file when the file is empty. So, my 14.7GB WinXP file will get corrupted sooner or later.

                      Can copy-on-write be turned off for data blocks?

                      Yes, there are several ways how to do that.
                      Disable it by mounting with nodatacow. This implies nodatasum as well. COW may still happen if a snapshot is taken. However COW will still be maintained for existing files, because the COW status can be modified only for empty or newly created files.
                      For an empty file, add the NOCOW file attribute (use chattr utility with +C), or you create a new file in a directory with the NOCOW attribute set (then the new file will inherit this attribute).
                      Now copy the original data into the pre-created file, delete original and rename back.
                      There is a script you can use to do this [1].
                      Shell commands may look like this:
                      touch vm-image.raw
                      chattr +C vm-image.raw
                      fallocate -l10g vm-image.raw
                      will produce file suitable for a raw VM image -- the blocks will be updated in-place and are preallocated.

                      Last edited by GreyGeek; Jan 23, 2014, 09:34 PM.
                      "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                      – John F. Kennedy, February 26, 1962.

                      Comment


                        #12
                        I believe it's Ubiquity that creates the @ and @home subvolumes when you choose btrfs as the target filesystem - but I'm sure that's what you meant.

                        As far as the snapshot creation: Yes and one of the beauties of btrfs is almost all of the functions we are used to doing only when the filesystem is unmounted can now be done while still using the filesystem! Coincidentally, just this week one of my server btrfs filesystems started kicking a couple errors related to the meta-data (journal). I was able to execute the repair (btrfsck --repair /dev/sdX) while still using the filesystem and without any negative effects. Amazing!

                        Please Read Me

                        Comment


                          #13
                          Originally posted by oshunluvr View Post
                          I believe it's Ubiquity that creates the @ and @home subvolumes when you choose btrfs as the target filesystem - but I'm sure that's what you meant.
                          I don't even know what Ubiquity is or does or, if I knew, I didn't remember. I stopped studying or keeping abreast of Linux changes about the time I retired. Only your reporting of btrfs, and the fact that Kubuntu 14.04 contained the 3.13 kernel, which work with my AR9462 wifi (which stopped working with 12.04) triggered the notiion to replace KWeezy with Kubuntu 14.04.

                          I hadn't used my virtual WinXP guest OS for anything, besides keeping it updated with AV dat and patches, since 2010. I never installed it on KWeezy. VirtualBox and my WinXP guest OS installed beautifully on 14.04, which the exception that the guest extensions didn't allow me to activate the USB 2.0. But, that's all moot anyway since btrfs's CoW can corrupt dynamically expanding virtual HDs. I can create an empty WinXP.-disk1.vmdk file (and WinXP.vbox and WinXP.vbox-prev) using touch, adding the +C attribute to the empty files, but I can't think of a way of "importing" the real files "into" the empty ones. Can you?

                          Originally posted by oshunluvr View Post
                          ]As far as the snapshot creation: Yes and one of the beauties of btrfs is almost all of the functions we are used to doing only when the filesystem is unmounted can now be done while still using the filesystem! Coincidentally, just this week one of my server btrfs filesystems started kicking a couple errors related to the meta-data (journal). I was able to execute the repair (btrfsck --repair /dev/sdX) while still using the filesystem and without any negative effects. Amazing!
                          Being able to work on it and repair it without umount-ing it was what I noticed in your discussion and why I decided to give it a try.
                          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                          – John F. Kennedy, February 26, 1962.

                          Comment


                            #14
                            I don't much about the vmdk's. My solution was to put my .VirtualBox folder on a ext4 partition so the corruption issue was avoided.

                            Ubiquity is the Kubuntu installer. The dev's programmed in the subvolume names but weren't interested in making the fields available for other than the defaults.

                            Please Read Me

                            Comment


                              #15
                              Duh!
                              I forgot that I had cloned a vmdk file before. Tonight I consulted the VBox manual (F1) and ran the following:
                              Code:
                              VBoxManage clonehd /home/jerry/VirtualBox\ VMs/WinXP/WinXP-disk1.vmdk /home/jerry/tmpVM/WinXPfixed.vmdk --format VMDK --variant Fixed
                              It created two files
                              WinXPfixed-flat.vmdk
                              WinXpfixed.vmdk
                              I created a new guest WinXPfixed OS and pointed it to the second file, which is now a fixed 30GB.
                              When I booted it up XP complained that too many of its 10 GID parameters had changed it unless I actived it within 3 days it would refuse to run. I activated it. Don't know if that will keep or not.
                              So, other than that, WinXP is up and running in VBox.

                              Been studying btrfs docs and tutorials. What I'm reading is neat. I've got a new toy to play with for a while!
                              "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
                              – John F. Kennedy, February 26, 1962.

                              Comment

                              Working...
                              X