Results 1 to 4 of 4

Thread: openSUSE 13.2 - initial experiences

  1. #1

    Default openSUSE 13.2 - initial experiences

    For openSUSE 13.2, I thought I would try installing it on three very different computers before posting my experiences
    to the forum:

    1. Laptop - upgrade from 13.1 using DVD.
    2. Desktop - new install from DVD.
    3. Workstation - new install from DVD.

    LAPTOP

    Hardware: Intel Core i7-4500U with Intel HD integrated graphics.
    Software: openSUSE_13.2_x86_64_KDE dual-boot (alongside Win8)

    Probably, one of the main strengths of openSUSE is the seemless procedure for incremental upgrades. I believe this
    really sets openSUSE well above the many *buntu-based distributions that offer no such facility. The installer detected
    the UEFI boot and /etc/fstab entries flawlessly and the upgrade went without a hitch. It appears the GRUB screen for
    UEFI boots from DVD looks different compared to BIOS boots. I wondered why. I suspect it's something to do with GRUB-EFI
    vs ISOLINUX.

    There were only a couple of minor issues for me. The first was simply a number of gcc libraries that went awol after the
    upgrade that caused gcc to complain when compiling a couple of my C++/C/IAx86_64 programs. However this was easily
    resolved by reinstalling them using zypper. The second issue was the use of Wicked to connect to wireless networks. I
    could connect to wireless networks after being assigned an IP address, but the connection refused to allow TCP/IP
    traffic (I couldn't even ping). This was resolved was resorting to KDE's Network Manager.

    Although openSUSE 13.2 comes with gcc 4.8, it's reassuring that 4.9 is a straightfoward option for the future. I'm sure
    the under-the-hood improvements to YaST and Btrfs support are all good, but in all honesty they have little impact on my
    day-to-day activities on this computer. Similarly the KDE improvements are probably a little wasted on me because I
    spend most of my time in consoles. I prefered the darker styling of openSUSE 12.3 and 13.1 compared to 13.2, but this is
    of course just a matter of personal taste. The contour desktop wallpaper looked reasonable, but I preferred to switch
    back to a plain black desktop (although I kept the default wallpaper for openSUSE 12.3 an 13.1). Overall, however, it
    was a very smooth upgrade.

    DESKTOP

    Hardware: Intel Core i7-975 with AMD Radeon graphics card (dual GPU).
    Software: openSUSE_13.2_x86_64_KDE quad-boot (alongside Win7, Linux Mint 17, and Gentoo)

    I was concerned about this particular installation because whatever I did in openSUSE 13.1, the proprietary AMD graphics
    driver (fglrx) failed spectacularly. Although there were a lot of helpful suggestions from the forum in sorting it out,
    it never worked and finally I was advised by a forum moderator to report the problem to the kernel developers or AMD.
    However, I knew it wasn't a driver or kernel issue because the proprietary drivers worked perfectly well in other
    distributions running identical kernel versions, and so the cause must having been openSUSE patching. I was tempted to
    bugzilla it, except I didn't want to distract the openSUSE developers with a problem that didn't seem to affect other
    AMD users and was downstream from a closed-source blob. However, rather than upgrading from 13.1, I decided to perform a
    fresh install and hope for the best.

    In the light of previous experience, I first checked that the BIOS had disabled the floppy disk controller and I booted
    the DVD. The installer started well until it came to the `Suggested partitioning'. As if a punch in the face, the
    installer `suggested' XFS for /home and Btrfs, and then a multitude of Btrfs subvolumes for /opt/, /srv/, /tmp/,
    /usr/local/. and _loads_ for /var/*? Was the openSUSE installer programmer on drugs? And does openSUSE _ever_ want to
    appeal to GNU/Linux newcomers? I guess not. If you want *really* put someone off GNU/Linux forever, then this is a
    perfect way to start.

    There's not even a `help' button to inform the newcomer, who might understand nothing more from this then `please
    completely rape my hard drive'. Honestly, the `suggested partitioning' tool should _preceded_ by a dialogue box with a
    drop-down for which hard drive to use and checkboxes for `use Btrfs with/without subvolumes for /tmp/ directory and
    /var/ subdirectories' and `use separate ext4/XFS/Btrfs home partition'. I realise that you can `Edit Proposal Settings'
    but this should be done _before_ the suggested partitioning.

    So if you decide to do something `simple' you all of a sudden must click `Expert Partitioner' or clicking on `Custom
    Partitioning (for experts)'. Sorry, but common sense - this is not! In the days of the `Suggested partitioning' from
    S.u.S.E. comprising nothing more than a root volume and swap (+/- separate home), fair enough. But the Btrfs default
    with multitudinuous subvolumes is infinitely more `expert' than the custom partitioning - why the hell might I want a
    separate subvolume for /var/lib/pgsql anyway??? I know that Chris Fisher from the Linux Action Show was impressed by
    this nonsense but I, and more importantly potential GNU/Linux newcomers, would not be impressed. Come on openSUSE
    developers! Try not to scare people!

    Not to feel too outdone by the `suggested partitioning', I deviated from my usual simple 4 partition setup (/boot/, /,
    /swap/, /home/), and opted for a 6 partition arrangement (/boot/, /, /swap/, /tmp/, /var/, /home/), with the last 4 as
    logical volumes within a single extended partition. Again the installer attempted to confuse, asking (for no obvious
    reason) whether the `Role' of each new partition was for `Operating System', `Data and ISV Applications', `Swap', or
    `Raw Volume (unformatted)'. If I truly am an `expert' partitioner, why the hell should I tell _anyone_ the intended
    role? Again, common sense distinctly absent. To rebel against the installer, I decided to format / with XFS and /home/
    with Btrfs! My /home/ only comprises of symlinks to ntfs_3g partitions so I don't particularly care if it breaks. Still
    whenever I run `mkfs.btrfs', I am warned `btrfs' is `experimental', and I therefore think it irresponsible therefore to
    adopt it as a default filing system for anything meaningful. I'll start to take Btrfs for / seriously once SLES proposes
    it by default.

    The rest of the installation programme is virtually identical to S.u.S.E./SuSE/SUSE/openSUSE installers for the last 15
    years: functional but uninspiring. At least the openSUSE developers should take notice of modern installers which ask
    for things like the locale regionalisation, NTP configuration, and default user and root passwords _while_ deploying the
    kernel images and installing the packages onto the hard drive. This isn't rocket science. And upon rebooting, the first
    thing I see on console after GRUB2 is `vga???? is deprecated', which doesn't exactly inspire confidence in a newly
    released operating system.

    So upon logging into openSUSE_13.2_KDE, and changing the desktop to plain black, I remain disappointed that Kate isn't
    installed by default since it is much better than Kwrite or Kedit. The network was running perfectly, which suggested
    that although the Wicked Service might not replace KDE's Network Manager adequately, it seems a promising successor to
    ifup. The inevitable `zypper up' downloaded only 157 MB after a week from release, and mostly for GTK and KDE updates. I
    then rebooted.

    In attempt to get rid of the `vga???? is deprecated' message, I opened YaST's bootloader configuration only for it to hang
    when I clicked on the `Kernel Parameters' tab. A second reboot corrected this and I was able to change `VGA mode' to
    `Unspecified' to remove the `deprecated' warning. The third reboot confirmed success in my attempt. I then proceeded to
    edit my repository add script "%s/13.1/13.2/gc", with only the pacman `Essentials' and `Multimedia' URLs not found.
    Installation of my usual suspects (e.g. vim-enhanced, gcc-c++, make, kernel-devel, cgdb, mutt, slrn, irssi, lynx, sc,
    mpd, ncmpcpp, etc...) went perfectly, except for the now normal but nevertheless stupid >1000 packages for texlive...

    And with baited breath I went into YaST's software manager to install the fglrx64_amdcccle_SUSE132 package. I rebooted
    and I was absolutely delighted to see that `fglrxinfo' resulted in no error. Good riddance 13.1!

    WORKSTATION

    Hardware: Intel Xeon E5-2640-v3 X2 with Nvidia Quadro graphics card
    Software: openSUSE_13.2_x86_64_KDE treble-boot (alongside Win7 and Gentoo)

    OK. Not the right place for Windows. However, I have a Win7 partition in case the motherboard manufactorer (Asus)
    releases BIOS updates only as Win64 executables (sadly Supermicro still haven't heard of M.2 SSDs...). Also, I agree
    openSUSE is not the ideal distribution for this hardware or indeed any binary GNU/Linux distribution, but I wanted to
    have a standby in case I broke my primary distribution, Gentoo (easily done!). However, the saga of my frustrating
    experience of getting openSUSE 13.2 onto this machine I think distils all the worst things about the openSUSE installer
    (perhaps with the exception of the `Suggested partioning' algorithm!).

    Win7 and Gentoo were perfectly happy with UEFI boot so I booted the openSUSE install DVD in UEFI mode. The screen went
    blank with a hard crash upon leaving the UEFI boot menu, with no option to change the kernel parameters (which I
    understand is not straightforward in UEFI mode). There was not even a `safe-boot' or `recovery-boot' option. Pressing
    `e' achieved nothing. So unless I'm missing something obvious, there's no way for me to install openSUSE 13.2 directly
    with UEFI boot without performing some sort of hack (which I had to do for Gentoo, but hacking in Gentoo is the expected
    norm!).

    So I booted the DVD in standard BIOS mode accepting I had no choice but a non-UEFI install of openSUSE 13.2.
    Fortunately, GPT partitioning in openSUSE does not depend on UEFI. Of course, the standard BIOS DVD boot still resulted
    in a hard crash. After disabling local APIC, I saw the console output, but again this proceeded to another hard crash
    when the installer attempted to load X. So disabling local APIC _and_ setting the kernel parameter `nomodeset' finally
    allowed me to load the openSUSE installer. Apart from the same Btrfs subvolume nonsense I described the above, the rest
    of the installation proceeded perfectly well. Again, there were only modest updates on the first `zypper up' and softare
    installed just fine (still no pacman repo). Curiously removing the kernel parameter `nolapic' still resulted in a
    crash-free boot from hard-drive.

    The proprietary Nvidia graphics driver blob installed flawlessly and it combined with openSUSE's KDE rendered a
    beautiful desktop. Of course, it's not very different to Gentoo's KDE on this box, apart from the default wallpaper and
    Geeko icon on taskbar. Overall, I'm relieved that I was able to install openSUSE 13.2 as a fallback OS on this machine,
    even if I had to do so without UEFI boot.

    OVERALL_IMPRESSIONS

    There's no question the openSUSE remains a strong and fantastic distribution. I have to admit that from my heart, I have
    a squidgely soft spot for openSUSE since S.u.S.E. was my first ever GNU/Linux distribution back in the late 1990s. But
    the release of 13.2 confirms my suspicions beyond doubt: it is not, and has never has been for GNU/Linux newcomers. It's
    also not particularly designed for console hackers (a la Arch) or source compilers (a la Gentoo). It's a midway
    desktop-multivalent open source distribution that offers Enterprise-level control at the click of the button (through
    YaST) - a cutting-edge testing bed for SLED/SLES. While, tbere's a lot to commend this approach, it comes with a number
    of costs.

    1. Complexity: the Btrfs subvolume nonsense must stop or at least not remain a default option. I've used GNU/Linux for
    many years; admittedly, I only made the transition from GRUB Legacy to GRUB2 at the time openSUSE 12.3, and still remain
    suspicious of Btrfs. One day I might even switch from Python 2.X to Python 3.X! But I'm sure most would agree that I'm
    not being too conservative to suggest that the many Btrfs subvolume arrangement is wholly inappropriate default
    `suggested partition' proposal with at least some help/documentation/explanation for the poor installer!

    2. Precariousness: while it's fine to assume a reasonably experienced GNU/Linux user will know to do things like disable
    floppy controllers, disable UEFI boot, set no local APIC, and set nomodeset - if there are problems, it is without
    question unreasonable to expect this of a GNU/Linux newcomer. There can be no greater demotivater or confidence-killer
    than an OS installer DVD that crashes whenever it boots. I'm pleased to see that that the installer no longer tries to
    boot from kexec after installation since this always hard-crashed for me and instead it wisely reboots. Since the kernel
    is reloading anyway, there's absolutely no need for the DVD kernel image to load with all bells and whistles. If the DVD
    kernel image can't load safely on every x86 GNU/Linux capable system, then set the default parameters so that it does!

    3. Lassitude: if openSUSE is trying to be everything to everyone occuping the mid-ground between `newbie' and `guru', it
    may end up not being particularly attractive to anyone. With version 13.2, openSUSE's installer is rubbish to GNU/Linux
    newcomers while being patronising to `experts' at the same time. Upon booting KDE, there's little indication that you're
    inside openSUSE beyond the wallpaper and Geeko icon on the taskbar, not to mention the long-standing omission of kate.
    Beyond a Ruby recode, YaST hasn't particularly changed for the last dozen years, and there's still no YaST utility to
    browse packages listed within http://software.opensuse.org - which would be a clear no-brainer to appeal to those
    unfamiliar with openSUSE repositories. While the switch to systemd and Btrfs does show a progessive ethos among the
    developers, the positive effects remain largely confined to realm of `geekdom' rather than the real world. If this is
    all the developers want, then they're doing well. But I suspect their aspirations are a somewhat loftier, and they
    should consider releasing an ISO with a DVD that reliably boots at the very least. But if the developers continue to
    exercise lethargy in such `basics', then openSUSE could only ever appeal to a niche and therefore somewhat limited
    population.

    But I'd like to finish on the positives:

    1. Seemless upgrading: although non-Tumbleweed versions cannot be regarded as rolling releases, my faith in incremental
    version upgrades in openSUSE remains as strong as it ever was.

    2. Graphics support: proprietary drivers for AMD and Nvidia worked from repositories on first attempt without having to
    resort to any `hard way' (i.e. direct blob installation). This is the first time I've experienced this on an openSUSE
    release.

    3. GNU/Linux versions: I've had very good experiences with kernel 3.16.X and gcc 4.8.X, and was therefore very pleased
    to see their inclusion in openSUSE 13.2.

    4. Post-install zypper updates: these were minimal, particularly when compared to openSUSE 12.3.

    5. Wicked appears to be a worthy successor for ifup (albeit maybe not for wireless connections from a laptop).

    The only real question is whether the developers have a focussed future for openSUSE, and if so, where? But overall, a
    wonderful job: well done!


  2. #2
    Join Date
    Jun 2008
    Location
    UK
    Posts
    5,500

    Default Re: openSUSE 13.2 - initial experiences

    Quote Originally Posted by flymail View Post
    Probably, one of the main strengths of openSUSE is the seemless procedure for incremental upgrades. I believe this
    really sets openSUSE well above the many *buntu-based distributions that offer no such facility.
    I agree that flexibility wrt installation methods is one of its strengths, and AFAICT sets openSUSE apart from many alternative distributions. I've never needed to incrementally upgrade using the DVD method. It's doubtful to me whether the "*buntu-based" users would be crying out for it anyway, they have an online dist-upgrade (c.f. easier than zypper dup), but you may have particular reasons for using the DVD method?

    ...installer `suggested' XFS for /home and Btrfs, and then a multitude of Btrfs subvolumes for /opt/, /srv/, /tmp/,
    /usr/local/. and _loads_ for /var/*? Was the openSUSE installer programmer on drugs? And does openSUSE _ever_ want to
    appeal to GNU/Linux newcomers? I guess not. If you want *really* put someone off GNU/Linux forever, then this is a
    perfect way to start..
    Up front, I'm one of those who believe that it's probably too soon for Btrfs to be the default. Why use it right now if snapshots are not required, and why are snapshots required for a stable distribution offering reliable updates?

    It's easy to understand why SUSE [Linux Enterprise] include Btrfs and their commendable homegrown Snapper in recent offerings. Presumably it's relevant to their customers, and gives them a [temporary] competitive edge. I'm guessing they also have resources to polish the product and support their customers' upgrades. Could openSUSE really not include Btrfs and Snapper now? Not realistically, but perhaps not as the " default" option, without comprehensive "help" in the installer. They already have had arguably good documentation, since 12.3, in the official Reference Manual.

    I'm guessing the majority of users no longer separate the root partition's directories, other than /home or their own data. The default subvolume is root "/", including all its sub-directories. The snapshots are taken by subvolume non-recursively. opemSUSE pre-defines those subvolumes to avoid including them in snapshots of the system. Who would want a massively growing snapshot that included /tmp, or /var, or even an included /home containing large quantities of static data?

    ...It's a midway
    desktop-multivalent open source distribution that offers Enterprise-level control at the click of the button (through
    YaST) - a cutting-edge testing bed for SLED/SLES. While, tbere's a lot to commend this approach, it comes with a number
    of costs...
    It is what it is, and the costs will always depend on the needs of the few or many it fails to satisfy. In terms of target users, nothing has changed since the project stated its preference for "newcomers" (your word) that are prepared to research, and learn how to make it work for their own particular situation.
    Leap 42.3 (ext4, KDE Plasma 5.8.7) ~ stable
    Manjaro (ext4, Xfce) ~ rolling updates
    Tumbleweed (ext4, KDE Plasma5) ~ managed updates via "Tumbleweed Snapshots" service.

  3. #3

    Default Re: openSUSE 13.2 - initial experiences

    Quote Originally Posted by consused View Post
    I agree that flexibility wrt installation methods is one of its strengths, and AFAICT sets openSUSE apart from many alternative distributions. I've never needed to incrementally upgrade using the DVD method. It's doubtful to me whether the "*buntu-based" users would be crying out for it anyway, they have an online dist-upgrade (c.f. easier than zypper dup), but you may have particular reasons for using the DVD method?
    For me, there are three good reasons to upgrade using the DVD method:

    1. I like to boot into the new OS before upgrading to detect problems.
    2. For me upgrading with the openSUSE DVD has _never_ failed.
    3. I trust an md5 checksum+media check more than a stable internet connection for an OS installation.

    I agree the first two reasons are pretty much weaker than the last though.

    Quote Originally Posted by consused View Post
    Up front, I'm one of those who believe that it's probably too soon for Btrfs to be the default. Why use it right now if snapshots are not required, and why are snapshots required for a stable distribution offering reliable updates?

    It's easy to understand why SUSE [Linux Enterprise] include Btrfs and their commendable homegrown Snapper in recent offerings. Presumably it's relevant to their customers, and gives them a [temporary] competitive edge. I'm guessing they also have resources to polish the product and support their customers' upgrades. Could openSUSE really not include Btrfs and Snapper now? Not realistically, but perhaps not as the " default" option, without comprehensive "help" in the installer. They already have had arguably good documentation, since 12.3, in the official Reference Manual.
    I have no problem with openSUSE including Btrfs and Snapper. I just question the wisdom of defaulting the installation file system to Btrfs. IIRC SLES defaults to XFS - and so do I.

    Quote Originally Posted by consused View Post
    I'm guessing the majority of users no longer separate the root partition's directories, other than /home or their own data. The default subvolume is root "/", including all its sub-directories. The snapshots are taken by subvolume non-recursively. opemSUSE pre-defines those subvolumes to avoid including them in snapshots of the system. Who would want a massively growing snapshot that included /tmp, or /var, or even an included /home containing large quantities of static data?
    Perhaps these are good reasons to put /var/ and /tmp/ into separate non-Btrfs partitions.

    Quote Originally Posted by consused View Post
    It is what it is, and the costs will always depend on the needs of the few or many it fails to satisfy. In terms of target users, nothing has changed since the project stated its preference for "newcomers" (your word) that are prepared to research, and learn how to make it work for their own particular situation.
    Well... yes and no. If you really think it's fair enough expect a GNU/Linux newcomer to work out he/she must change boot mode from UEFI to BIOS, disable the local APIC, and add `nomodeset' to the kernel parameters just in order to get the openSUSE installation DVD to boot, then I propose that by this stage they are probably no longer a newcomer! I am merely suggesting that an installation DVD that can not boot otherwise might not give much confidence to a GNU/Linux newcomer, who might therefore prefer to install an operating system with an installation DVD that can. I don't think this assertion is completely unreasonable...

  4. #4
    Join Date
    Jun 2008
    Location
    UK
    Posts
    5,500

    Default Re: openSUSE 13.2 - initial experiences

    Quote Originally Posted by flymail View Post
    For me, there are three good reasons to upgrade using the DVD method:

    1. I like to boot into the new OS before upgrading to detect problems.
    2. For me upgrading with the openSUSE DVD has _never_ failed.
    3. I trust an md5 checksum+media check more than a stable internet connection for an OS installation.

    I agree the first two reasons are pretty much weaker than the last though.
    Yeah for (1) the liveCD has in the past provided me with a pre-installation check. Since running a Tumbleweed partition, I more or less know what to expect wrt to the new release.

    For (2) I install the standard release either by Network CD or zypper dup. Only one failure, in early days of the latter when it hung on a broken package, where my introduction to chroot provided the remedy to then restart where it left off. So I do (3) at least the md5 check for burning the Network CD.

    Perhaps these are good reasons to put /var/ and /tmp/ into separate non-Btrfs partitions.
    For the majority, why bother when Btrfs already has the feature to separate, and in our case it comes pre-configured? It's not complicated, even if the current installer presents it in that way. If so, the presentation needs addressing.

    Well... yes and no. If you really think it's fair enough expect a GNU/Linux newcomer to work out he/she must change boot mode from UEFI to BIOS, disable the local APIC, and add `nomodeset' to the kernel parameters just in order to get the openSUSE installation DVD to boot, then I propose that by this stage they are probably no longer a newcomer! I am merely suggesting that an installation DVD that can not boot otherwise might not give much confidence to a GNU/Linux newcomer, who might therefore prefer to install an operating system with an installation DVD that can. I don't think this assertion is completely unreasonable...
    I think it's unfortunate rather than unfair, as long as the openSUSE project is always honest and up-front about its product positioning and support. Saying "it is what it is" more or less agreed with your asserted and unfortunate outcome.
    Leap 42.3 (ext4, KDE Plasma 5.8.7) ~ stable
    Manjaro (ext4, Xfce) ~ rolling updates
    Tumbleweed (ext4, KDE Plasma5) ~ managed updates via "Tumbleweed Snapshots" service.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •