Be Wily and Enjoy the Progress of Kubuntu 15.10

[markc]

@NoWorries re btrfs, it probably is a bit slower and not quite as robust under all circumstances but the flexibility of btrfs is amazing. In your case of having separate root and home partitions (I used to always create 3 or 4 small boot partitions for different OS's with a single large home partition) but with btrfs this strategy is no longer needed. For instance I've been using wily for a couple of months and 3 times something has completely locked up my laptop to the point of having to do a hard reset and a subsequent reboot gets past grub but something after the kernel loads does not complete. Not sure if it's systemd or btrfs related. Anyway, I simply reboot onto a live wily USB stick, start konsole, sudo -i and "mount /dev/sda1 /mnt" and "mv /mnt/@ /mnt/@20150707; mv /mnt/@home /mnt/@home20150707" (or whatever the date is) and then proceed with installing wily again via the manual partition option making sure NOT to select the format drive option for /dev/sda1. Once I reboot to the new installation I "mount /dev/sda1 /mnt" again and "mv /mnt/@home /mnt/@home2; mv /mnt/@home20150707 /mnt/@home"... reboot again and I have my /home subvolume back the way it was. A bit of updating and copying of some config files from /mnt/@20150707/etc/** and I'm back up and running on a pretty well pristine install with all my personal /home files intact. I'm so comfortable doing this now I don't even bother doing a backup first.

[xennex81]

This is not simpler or more powerful than regular fs (referring to markc). You only move the subvolume to a new location such that the install doesn't overwrite it. I would think BTRFS was used for more powerful features. I can install on a default /home, delete it, and remount /home (from the alternate volume) and achieve the same. The only difference is that it requires updating fstab and rebooting (if required or desired). The only pain I encounter in the regular system is that dismounting /home (or whatever) is a real pain when a user is logged in, similarly operating on the rootfs is difficult without single user mode, and single user mode is hard in Ubuntu (I don't know how to do it). But I don't think that is solved with another filesystem. Unmounting stuff is hard anyway because terminals or processes started from a terminal have working directories that cannot be changed and that prevent unmounts even when it is nothing more than a handle on the directory. These are issues I would like to see solved first.

[markc]

@xennex81 it is simpler. I used to mess around with ext4 partitions for years and now using subvolumes instead of hard wired partitions is definitely easier to achieve this particular root fs twiddle. This is only a single example of where btrfs has made my life a little easier. Having one large single btrfs fs to play with and be able to carve it up dynamically anytime with subvolumes and snapshots is just wonderful. There are many more use cases for btrfs like RAID with other drives of different sizes, efficient backups using send/receive and the most flexible backing store for lxd containers etc.

And btw one of the reasons btrfs can be slower than ext4 is it needs to be balanced every week or month to keep it in shape. Something not everyone does and they wonder why their btrfs is slowing down.

[xennex81]

I think the fact that you are taking your volumes out of a single pool with no issues posed by real physical segmentation is certainly and advantage, but if BTRFS ever became corrupted, it is certainly a disadvantage. The disadvantage of physical volumes is somewhat mitigated with LVM although it is not perfect and you can't shrink the rootfs while it's online. And resizing partitions is a bitch especially shrinking because the tools are inadequate (I mean real physical partitions, not logical volumes).

So I just don't like one big glob of database driven file dispersal just like I don't like Git's storage model (which is basically the same).

I was reading up today on Subversion but the Wikipedia article was really chaotic and it seems severely flawed. By contrast CVS was a bliss to read. But limited. Git is at least sound in internal design. I just don't like it's working model where there are no Real Copies. You are constantly manipulating a single working tree that changes by the minute and that runs the risk of destroying everything with the wrong command (backups! backups! a remote Git repository is not a backup!).

[NoWorries]

@NoWorries re btrfs, it probably is a bit slower and not quite as robust under all circumstances but the flexibility of btrfs is amazing. In your case of having separate root and home partitions (I used to always create 3 or 4 small boot partitions for different OS's with a single large home partition) but with btrfs this strategy is no longer needed.

As I understand what you are saying, you use the same home partition for different OS's. In my case I always have a different home partition for each OS. I do this because of the hidden files in the home partition which are specific to the versions of the installed software. For example, I found that with Plasma 5, System Settings is invoked by systemsettings5 whereas for Vivid it is systemsettings. I am also sure that other applications have different versions and may therefore have slightly altered configuration files.

The main exception to my rule of having different home partitions comes when dealing with Kontact. The only way I have been able to have my Calendar, Notes etc to work on different distributions is to get the ~/.config, ~/.kde and ~/.local files from the OS with Kontact working and use them to replace the ones on the new system. When I do this, I normally have to do some reconfiguration of my desktop. but at least I have Kontact working.

[xennex81]

As I understand what you are saying, you use the same home partition for different OS's. In my case I always have a different home partition for each OS. I do this because of the hidden files in the home partition which are specific to the versions of the installed software.

I've been thinking about this as well. How can you safely combine? It seems not possible. You can create distinct /homes and then symlink (or even hardlink?) the directories you want to be the same. OR you can create an aufs where /home (on the rootfs) is the lower dir, .config/ and .kde/ and .cache/ are on the lower dir, and everything else is on the upper dir and gets written there. The upper dir then comes from your dedicated shared volume. Each root filesystem thus contains the most 'volatile' materials, while the more 'stable' stuff is on your shared home.

Does it work? Still risky.

(aufs is different from OverlayFS which is in the kernel. In aufs you can achieve very easily that directories on one share are also updated on that share, while completely new files (subdirectories) end up on the 'primary' share).

[NoWorries]

I must confess, that with the way I use my system, I have no need to create any symlink's or create mounts for directories using autofs. By taking this approach, I have not had the troubles that others have reported with Vivid and Wily.

I must confess that when I copied some of the /home hidden files from a previous Kubuntu release to the /home of a new one, the new system seems to be doing a lot of "knitting" when I start it up. This settles down once I have tidied up loose ends in the configuration. I also keep the same hostname, username and password for the systems in this process.

[xennex81]

There are just some files like Firefox bookmarks and the like that I like to share or to have shared. I mostly choose to have a consistent configuration across distributions. Some of that is in /home and some of it is hidden files. I favour symlinks over aufs due to the added complexity of the latter. But I still don't know what to do. I might install OpenSUSE and Kubuntu Wily on the new laptop I'm getting (hopefully). But really I don't need more than one OS. Unless it's for active development. Why all the confusion. Still, experimenting is advancement. I'm a developer of solutions (or models). Maybe I'll come up with something that works really well. But there are mainly issues with the safety of aufs (overlays). Its difficulty. And the random or arbitrary inclusion or exclusion of files into the shared mount. And I don't know anything about .kde/.config/.local/.cache. It would be helpful if most apps kept working with the same config files etc. Maybe I'll just .kde as a nonshared thing and leave it at that.

[NoWorries]

Oops, I forgot about the fact that I always copy the ~/.mozilla, ~/.Skype and ~/.thunderbird from the home directory of my old distribution to the home directory of the new distribution. I have Wily on a USB 3 Flash Drive and from this I can see all the files on my Utopic system. So it is very easy to copy the essential hidden files onto Wily. I can also use Dolphin to easily access the home directory files that do not fit onto the Flash Drive.

[NoWorries]

I am beginning to wonder why the Daily Build site is not giving daily builds as the current one is dated 02-July, ie

wily-desktop-amd64.iso 02-Jul-2015 06:20

Is there some other site that has daily builds?

[NoWorries]

The main reason why I was wanting a really current build was that I had decided to upgrade my "Sacrificial Desktop" with more RAM (2GiB to 8GiB) and replace my disk with an SSD. This latter change involved a new installation which required me to be Wily.

I had assumed that I still required a partition for UEFI. When I was doing the manual partition, I could not find a UEFI option. I still created the partition based on the previous disc parameters. After doing the installation, I was greeted with the Grub prompt. I tried several more installation attempts but all of these resulted in the Grub prompt. I retreated defeated and decided to do an installation using the entire disc - which worked. After this I then did another installation with partitions as I want, ie separate root and home partitions. This then worked and I was back in business.

I installed with the option to update packages while installing, BUT when I did the good old dist-upgrade, I got the following:

335 to upgrade, 31 to newly install, 0 to remove and 0 not to upgrade.
Need to get 238 MB/256 MB of archives.
After this operation, 318 MB of additional disk space will be used.

I now find that I no longer have a UEFI partition as shown in the following graphic.



Since doing this installation, updates still keep coming at a great and pleasing rate. The latest is the 4.1 kernel as shown in the graphic below.



If you are in any doubt about the excellent progress for Wily. I hope the above gives you encouragement to try it out.

[claydoh]

I can't remember why, but there were problems with the builds not booting , it looks like that hasn't been resolved yet, though updates are still going on.

It also seems to be vacation and conference season the past few weeks.

Sent from my LG G4

[NoWorries]

There are certainly many updates still coming down the pipe. Since the Alpha 2 release is due next Thursday, we should see some sign of life on the Daily Build site soon.

Regarding some builds not booting, I found the Installation iso booted OK. My surprise was in sorting out the installation on a new disc, in that it did not require a UEFI partition for a system that has UEFI. I therefore assume that this is now resolved in the 4.1 kernel. Please correct me if I am wrong.

[claydoh]

They pulled the non booting iso image, iirc. Keeping the last booting image.

Sent from my LG G4

[NoWorries]

They pulled the non booting iso image, iirc. Keeping the last booting image.

Sent from my LG G4

Time to celebrate as the Daily Build Site is now giving daily builds. I just noticed that the date has jumped from 2-July to 28-July. So if you want to enjoy a Wily experience you can now give it a go and not be faced with a massive download after installation.

You will only have to deal with 1-30+ per day and enjoy the progress being made by the developers.