Announcement

Collapse
No announcement yet.

what is the Installed OS size and which version should i choose

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

    what is the Installed OS size and which version should i choose

    I need to migrate the old WinXP to a dual boot system.

    Before i do that i need to make sure the GPU will work well. It's an nvidia GT730. drivers are available but i could not get it to work on the 14.04 on another PC. a very similar and possibly the very same issue was discovered by another Ubuntu forums member. it would appear the nvidia drivers recognise the GPU wrongly and the end result it blinking cursor on boot.

    anyway, before compromising the working OS i plan to do a full install to an external USB drive. in the past i know that 8 Gb was enough for OS install (especially if you made swap 1 Gb or less). but OS images have grown since then. while i have a USB drive which has around 7,5 Gb capacity. or something like that

    1. how much disk space do i need to do a full install and to be able to add proprietary drivers to it? just that, no other software... i believe at this point /swap is not needed or it can be reduced, since the PC has 4 GB ram.

    2. just asking for opinion here: should i go with 16.04 or 17.10 and then upgrade to 18.04 for its lifetime? i do not have experience with nvidia and i don't know how fast they will drop support for this card. another thing that is making me think, is the "bad press" going around about 17.10 release, which is supposedly not as good as 17.04 was.

    i am still rocking the 14.04 LTS on the other two PC's and that has worked fine, but i am thinking since this one is a clean start maybe it deserves the latest. the PC is otherwise very old (single core AMD) that was upgraded through time. i think only 2 sticks of RAM, CPU and the frame box itself are the only things that were originally there. it's just that it works perfect for all the needs. just the WinXP OS is hard to maintain security wise (i use antivirus, firewall and up to date browses with various script blockers). so my plan (for some time now) is to move online activities to Linux and keep the games on XP along with a few very particular online stuff that maybe still needs windows support.

    #2
    My opinions;

    Re #1: I believe the installer will require 8GB of available space. I don't know if there's a way around that. Of my latest virtual installs, 18.04 used 5.3GB and KDEneon User Edition used 4.5GB.

    Re #2: If you want a reliable experience, install 16.04 and wait until 18.04 matures for several months. You'll notice most of the problems reported here are with 17.10. In my experience, this is obvious and typical - the first 3-4 months of a new release are the most buggy. If you think you want 18.04 soon, I's still wait until June or July before installing it for daily use.

    Putting it all together, assuming you only use 8GB for the install, you won't have much room for anything else including personal data so I'm assuming this is more of a learning adventure than a daily machine to use. I mentioned KDEneon User Edition above because it's a good compromise between 17.10 and having the latest KDE/Plasma 5 software - more reliable because it uses a 16.04 core, but KDE is as up-to-date as 17.10. It also install with almost no extra software - you're expected to add anything you need yourself - so it starts out smaller.

    As far as nVidia goes: their drivers are getting worse as the years go by but Nouveau has been getting better. I'd go without the nVidia driver if possible.

    Please Read Me

    Comment


      #3
      thank you. i guess i will try to borrow a 16 Gb USB drive or get get new one. i need it just to test compatibility.

      i will look into Neon. I am not sure i desperately need the latest, but would sure like to have a descent version that won't give me too much trouble to start with. also just in case latest nvidia drivers work better with new kernel and such.

      Nouveau works for basic stuff (tried it in live session), but i plan to later add some wine "applications" for the kids, so i was hoping nvidia drivers would work at least descent for a few old games.

      AMD was in this PC before but died, and new ones for some reason didn't want to work with this PCIe socket, so i ended up with nvidia. i need it to just run a couple more years until i can get enough money to get them a new or a descent used laptop.plus i hate to throw away things that work just fine.

      i already have a server, and an old motherboard that could also be used for server.

      Comment


        #4
        what is the Installed OS size and which version should i choose

        I’m running Neon User Edition on Btrfs (a MUST) using nvidia-378 to drive my GT650M secondary GPU.

        I’d recommend 16.04 until four months after the 21.04 final is released.
        https://wiki.ubuntu.com/Releases
        Then I’d do a fresh install, not an upgrade. Using Btrfs a bkup is trivial and restoring your data takes only minutes.


        Sent from my iPhone using Tapatalk
        Last edited by GreyGeek; Nov 27, 2017, 12:17 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
          thanks. i think btrfs will be on the new PC i am collecting money for. this one will be a mix of ext4 & NTFS. "only" 500 GB will be set aside for linux OS and linux data. the other data drive is 1 TB NTFS and ofcourse the windows side of the OS drive is also NTFS on 3 partitions.

          i went scavenging around drawers and managed to find 2 old 16 GB USB drives. one of them can be used to install and test the OS & drivers. if all goes well i will do the install. otherwise i will use some light linux with browser in virtualbox for browsing in winXP. slower option but kind of safe.

          yes i think it will be best to start with 16.04.3. the point release (.3) has "latest" kernel that get's upgraded, then see how it goes with drivers and such.

          if there is much snow outside (as in the forecast) then this weekend will be the time to test it otherwise it will have to wait until the holidays, but at least i got a couple of good ideas on how to go about this.

          Comment


            #6
            To GG's comment about btrfs...You hear about failed updates and upgrades all the time. Why risk it by using an outdated filesystem like EXT? With BTRFS, you need only take a snapshot before updating or doing a version upgrade and if it breaks your install - roll back to your previous state. Something to consider.

            Please Read Me

            Comment


              #7
              It's not that I think BTRFS is unworthy, but I really believe the supposed instability of EXT is somewhat exaggerated. In my case I've been using EXT variants for over 15 years and except for an actual hardware failure (which wouldn't have been completely mitigated by BTRFS) I've not had any catastrophic problems with Linux updates or upgrades.

              I don't rely on any "automatic" backup procedures - those inevitably result in excessive system administration time or failure of process. I don't like BTRFS, personally, because it takes up valuable space on the live environment - the snapshots still require care and feeding and monitoring, there is no backup system that doesn't. In the case of hardware failure, it doesn't matter what filesystem is in use at the time of failure, data is just as gone.

              I backup my data routinely using (now) a rotating system of three external harddrives, it was two drives but I found another. In fairness, I don't have a tremendous amount of data - just under 75GB - which doesn't require much time to backup, and I DO NOT venture into the bleeding edge of anyone's software and that includes non-current kernels, alphas, betas, and non LTS versions. On top of that, I don't use an LTS until the first bug release (i.e., 16.04.1). So, yes, in that respect, I'm exceptionally "conservative" and I don't contribute to testing, either. On the other hand, I've had no unstable Linux platforms and unrecoverable updates/upgrades, with the exception of actual hardware failures, in a very long time.

              If you choose to use BTRFS, that would be your choice, but make sure you still have a way to recover from hardware failure to the extent that you value your data and don't rely solely on snapshots stored on your active drive. Please note, I am not disrespecting anyone's choices, just be aware of potential concerns and plan accordingly.
              The next brick house on the left
              Intel i7 11th Gen | 16GB | 1TB | KDE Plasma 5.27.11​| Kubuntu 24.04 | 6.8.0-31-generic



              Comment


                #8
                Originally posted by jglen490 View Post
                ...but I really believe the supposed instability of EXT is somewhat exaggerated...
                I myself, nor anyone else I've encountered, has referred to EXT4 as unstable that I am aware of. However, there were discussion in 2003-2006 about desired changes to EXT3 that might led to instability, so EXT4 was forked instead - with backward capability. I simply commented that EXT4 was outdated - and I'm not the only one who thinks so - from Wiki (emphasis added):
                In 2008, the principal developer of the ext3 and ext4 file systems, Theodore Ts'o, stated that although ext4 has improved features, it is not a major advance, it uses old technology, and is a stop-gap.
                Mr. Ts'o goes on to say:
                Ts'o believes that Btrfs is the better direction because "it offers improvements in scalability, reliability, and ease of management". Btrfs also has "a number of the same design ideas that reiser3/4 had".
                This was in 2008. I simply restated what the developer and maintainer of EXT3/4 has said.

                Also, to be correct, I also did not refer at all to making backups. I referred to "snapshot" capability, something that does not exist in any iteration of EXT or almost any other file system. I did so to reference the concern the OP stated regarding potential problems associated with choosing or moving from 17.10 to 18.04. With BTRFS, in a few seconds, one can make a snapshot prior to any activity the user fears may be hazardous. If the fear becomes a reality, one than can revert to the snapshot in no more than a few seconds and a reboot. My experience has been like yours - I've rarely encountered (at least in the last 10 years) major problems associated with upgrades (I do not do release-upgrades at all, I prefer to install a new release along side). However, as one can easily tell by reading this forum, not all users experience trouble-free upgrading. With BTRFS, the concern is 100% removed. I snapshot prior to any upgrade so I can always revert. When it is clear all is well, I simply delete the snapshot. No one using EXT4 has that option. I totally agree that potential hardware failure requires a backup to protect your data, but I did not claim that snapshots constituted actual backups - just roll-back capability. I have no problem pointing out the numerous ways making backups with BTRFS is easier, quicker, safer, and more painless than with EXT4, but that really wasn't in the initial discussion.

                Furthermore, I cannot think of anything EXT4 does better than BTRFS or any real reason to use it on a fixed drive (no need for BTRFS or EXT4 features on a thumb drive - I use EXT2 or VFAT for them) with a single exception: dynamical sized files. Dynamically sized files like VMware or Vbox virtual hard drives or swap files are not usable on any COW filesystem that I'm aware of. For that, you must use a swap partition and either put VM drives on a suitable filesystem, use fixed-size virtual drives, or apply NODATACOW to the file system containing the dynamic files.

                You could argue that EXT4 performs slightly better in specific circumstances, but in real world terms at the user level, IME that's hardly noticeable if at all.

                I can think of several reasons not to use EXT4: using multiple devices with LVM and RAID are a PITA to create and manage, the EXT4 file system does not honor "secure deletion", which overwrites deleted files, but sensitive data can remain in the file system journal, and simply the lack of features that modern file systems like BTRFS and ZFS have.

                Please Read Me

                Comment


                  #9
                  Originally posted by GreyGeek View Post
                  I’m running Neon User Edition on Btrfs (a MUST) using nvidia-378 to drive my GT650M secondary GPU.

                  I’d recommend 16.04 until four months after the 21.04 final is released.
                  Five years on 16.04? That's harsh

                  Comment


                    #10
                    how much extra disk space does btrfs require ? in this case i work with 500 GB (second half of a 1 TB drive). i read ext4 should have some disk space empty to work well. but btrfs and zfs take up space for snapshots and such. i will definitelly put BTRFS on new PC (which will probably have larger drive size available) but in this case i think ext4 makes sense.

                    as for the old tech, i believe latest space probes utilised the PII processors - rigorously tested. while we don't have to go back in time so much, i don't have a problem using old tech if it works well. i used FAT32 on winXp for a very long time. unti they made descent recovery tools. and i was even saved by its use when partition got damaged by faulty drive cable.

                    my backups are manual (data on two different PC) as well as automated - using Areca to send versioned backups to family server. the server has RAID1 setup with mdadm, but i think i might have made a mistake unecessarilly added a complexity. i could have just send data to both disks. RAID is perhaps unnecessary and could not help the backups much. bad backup on one drive will just get mirrored on the other. it does protect against server drive failure a bit.
                    while various OS got imaged every once in a while and before doing an upgrade.

                    @mr_raider - i am still on 14.04 and plan to likely remain on it on at least one PC until early 2019. it has the original kernel and is there to give descent performance (power management and GPU performance) to the laptop which has an AMD Radeon card. My father was also kept on 14.04. works well for him.

                    another PC i have with 14.04, might do good with 16.04, so this one might get moved soon. but first i need to check if all drivers and such work. i had and still have troubles with sound on this motherboard. but they are not as big as they used to be in 13.10 and earlier.

                    Comment


                      #11
                      Originally posted by mastablasta View Post
                      how much extra disk space does btrfs require ? in this case i work with 500 GB (second half of a 1 TB drive). i read ext4 should have some disk space empty to work well. but btrfs and zfs take up space for snapshots and such. i will definitelly put BTRFS on new PC (which will probably have larger drive size available) but in this case i think ext4 makes sense
                      I found this question interesting and a little confusing. Why would you assume btrfs takes more space?

                      Snapshots may consume space eventually (as you makes changes to the original subvolume) but take none initially, and snapshots aren't a mandatory action - you're not required to use them, but the functionality is available if you wish to use it. Of course, you're always able to delete a snapshot when you wish as well. The fact that EXT4 does not have snapshot capability doesn't mean it's somehow more efficient than BTRFS, it just has less functionality and features.

                      Just for informational purposes, I took a 30GB partition on one of my drives and formatted it with EXT4 and with BTRFS. Without a lot of detail, here's the available initial space report:
                      Code:
                      Format  Device          Size  Used  Free  %  Mount
                      EXT4:  /dev/sda3        30G   44M   28G   1% /mnt/test2
                      BTRFS: /dev/sda3        30G   17M   28G   1% /mnt/test2
                      So EXT4 takes more space initially.

                      Also, did you know that by default EXT4 also reserves 5% of drive space? So your 500GB drive is going to have 475GB available. This can be changed, but most people aren't even aware it happens. Bottom line though, if we're talking using this drive for a Kubuntu installation, you only need about 12-16GB worth of space. The file system overhead isn't really an issue with a drive that large.

                      BTW, rather coincidentally, I had to roll-back to a snapshot in order to boot this morning. I had rebooted last night, but gone to bed before checking to see if my system booted to the log in screen. When I went into my office, all I saw was a screen of text that ended in "kernel panic" - something I have not seen in a very long time. Apparently, something went wrong over the last two days with one of the updates - I haven't had time to try and figure out what.

                      Lucky for me, my system automatically takes a daily snapshot every day and keeps the last three snapshots but deletes older ones. Along with that, I have 5 other installs on my system - which all are on the same btrfs file system, no partitioning required - so I booted into Manjaro and rolled back my KDEneon install to Tuedays, but it wouldn't boot either. Tried Monday, but also no-go. Finally booted to the Sunday snapshot - and I'm typing this reply. Each rollback required a reboot, renaming the install and snapshot subvolumes, and rebooting again - that's it. The whole process to rollback 3 times took less than 10 minutes. Additionally, every Sunday my system makes an automatic backup to another drive that is also bootable, but I didn't need to go that far this time. I keep two weekly backups and older one are automatically deleted.

                      The point to telling you this is: None of this - snapshots, 6 installs to the same partition, automated bootable backups - is possible with EXT4. Of course, it's your system, so do what you want.
                      Last edited by oshunluvr; Nov 29, 2017, 09:27 AM.

                      Please Read Me

                      Comment


                        #12
                        Originally posted by oshunluvr View Post
                        Lucky for me, my system automatically takes a daily snapshot every day and keeps the last three snapshots but deletes older ones. Along with that, I have 5 other installs on my system - which all are on the same btrfs file system, no partitioning required - so I booted into Manjaro and rolled back my KDEneon install to Tuedays, but it wouldn't boot either. Tried Monday, but also no-go. Finally booted to the Sunday snapshot - and I'm typing this reply.
                        This highlights (pun not intended) the importance of verifying system backups are bootable. Having a system backup that you can’t boot from is as useful as not having one when yours goes TU. So you had to resort to a system backup that was four days old. How much user data might have been lost?
                        Windows no longer obstructs my view.
                        Using Kubuntu Linux since March 23, 2007.
                        "It is a capital mistake to theorize before one has data." - Sherlock Holmes

                        Comment


                          #13
                          Originally posted by Snowhog View Post
                          This highlights (pun not intended) the importance of verifying system backups are bootable. Having a system backup that you can’t boot from is as useful as not having one when yours goes TU. So you had to resort to a system backup that was four days old. How much user data might have been lost?
                          Absolutely correct. I realized if I had gone one more day without rebooting, I would have been restoring from a backup - luck prevailed in this instance. I've already started another thread to discuss this realization and a way to prevent this from happening again.

                          https://www.kubuntuforums.net/showth...napshot-script

                          However, no user data was at risk since the default BTRFS installation uses separate subvolumes for home vs. root, I reverted to a three-day old OS but still have today's home folders. Besides, even if home resided within the root subvolume, the data wasn't corrupted so I could have manually copied data files out of the still available but not-bootable subvolumes. I believe the boot is is kernel/nvidia driver related. The subvolume that eventually booted was prior to the last kernel and nvidia update. I'm going to clean up my snapshots and - AFTER making a fresh bootable snapshot - redo the full-upgrade and see if it was an anomaly or if something is actually broken in the update. I'll probably upgrade everything BUT the kernel and nvidia driver, then reboot. If all is well, snapshot again, and do the kernel and nvidia driver upgrades separately to see if either of them cause the problem to return. If not, I'll assume it was a fluke.
                          Last edited by oshunluvr; Nov 29, 2017, 10:37 AM.

                          Please Read Me

                          Comment


                            #14
                            BTW I should have added to this thread - since the discussion involved disk space usage - My BTRFS file system, with SIX Linux installs, many snapshots, and HOME folders (in a separate subvolume) is consuming 194GB of a 460GB file system. This, my main BTRFS file system consists of two 250GB SSD's both of which have separate partitions for GRUB and SWAP. The remaining 230GB of each are joined as a single file system in RAID0 without need of another RAID tool like MDADM - something else you cannot do with EXT4.

                            Code:
                            [FONT=monospace][COLOR=#54FF54][B]stuart@office[/B][/COLOR][COLOR=#000000]:[/COLOR][COLOR=#5454FF][B]/subvol[/B][/COLOR][COLOR=#000000]$ sudo btrfs fi sh[/COLOR]
                            [sudo] password for stuart:  
                            Label: 'ssd840pro'  uuid: 8f0c1661-4e84-4512-b875-23bcfd5be1d8
                                    Total devices 2 FS bytes used 193.95GiB
                                    devid    4 size 229.97GiB used 197.03GiB path /dev/sdc3
                                    devid    5 size 229.97GiB used 197.03GiB path /dev/sdd3
                            
                            [/FONT]

                            Please Read Me

                            Comment


                              #15
                              Things you can do with btrfs
                              Code:
                              mr_raider@ThinkPad-11e ~ $ sudo btrfs subv list /
                              [sudo] password for mr_raider: 
                              ID 257 gen 26492 top level 5 path @xfce
                              ID 258 gen 26492 top level 5 path @xfcehome
                              ID 266 gen 29616 top level 5 path @
                              ID 267 gen 29618 top level 5 path @home
                              ID 286 gen 24746 top level 5 path timeshift-btrfs/snapshots/2017-11-26_09-37-17/@
                              Note that the program timeshift makes btrfs snapshots idiot proof.

                              Comment

                              Working...
                              X