Announcement

Collapse
No announcement yet.

The Most Common, Annoying Issue When Benchmarking Ubuntu On Many Systems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by phoronix View Post
    If any other Phoronix readers have tips for avoiding interactions with the boot-loader, feel free to comment on this article.
    It may sound trivial, but approaching GRUB developers (or even Canonical) and issuing a feature request should work.

    Comment


    • #12
      Originally posted by Michael View Post
      I do use Arch, including a few systems in this farm, but for Clang/kernel builds it's awfully convenient having a pre-built binary publicly available I can simply point at that can answer most questions..... i.e. responses of "you must have configured something wrong" or "what config file did you use?" etc.... That routinely come up over the years. With having a publicly available build, it makes most of these questions answerable without my manual intervention and allows others to reproduce the tests exactly.
      [mesa-git]
      Server = http://pkgbuild.com/~lcarlier/$repo/$arch

      it have mesa git and llvm/clang

      Comment


      • #13
        After the third upgrade on ubuntu and ubuntu fucking up the initrd again I just removed it and replaced it with debian jessie. Not because it was better, well it is, but not for a gamers point of view.
        But on each upgrade the initrd got replaced with an image that complains about a raidset that was in crititical state for years, that has never ever been part of my filesystem set, but that it deems so important to ask me the question if I still want to continue booting with the unused raid in degraded mode long before loading the usb+keyboard drivers to actually be able to give an answer.

        Grub2 is also always a big problem. On debian too. So I always install grub1 as it is self-contained. Serial console works as advertised. But the best thing is to have a serverboard with serial console support embedded in the linux based motherboard controller. Most motherboard controllers will allow you to ssh to the serial console and in extreme cases (intel desktop only) allow you to use a fucked up proprietary java jar with an embedded linux jni for intel only platform that can communicate like a virtual keyboard/monitor over ip. The most fucked up part of it is that it is just a minor proprietary change to the real vnc protocol.
        Anyway, these days you can just put the servers in the rack, hook them up to the network, and start installing from your workstation. Just as long as you have a helper/proxy in the same network as the server.

        Comment


        • #14
          Looks like (X)ubuntu 15.04 lacks this problem?

          I gave a try to Xubuntu 15.04 and I can admit it seems to lack this problem. Once crash happens, GRUB would appear at boot, sure. However, if nothing happens, it would timeout in something like 10 seconds and choose default Ubuntu boot, which brings user to usual OS (as long as it still could boot).

          Comment


          • #15
            Debian == ancient software, unfortunately.

            Originally posted by Ardje View Post
            After the third upgrade on ubuntu and ubuntu fucking up the initrd again I just removed it and replaced it with debian jessie. Not because it was better, well it is, but not for a gamers point of view.
            They have really antique kernel, MESA and nearly all programs. So it is outdated even before it released. This makes Debian hard to use with more or less recent hardware or if you want more or less recent software. And if one is about to go for Testing or Unstable... it could be far worse than Ubuntu. So I think ubuntu actually got best policy for desktop. Though their updater sucks very hard for sure as it fails to update system half of time (but what one can expect from silly Python script?!). However, update as such is: switch repos, do apt-get "update" and then "dist-upgrate". Their python shit sometimes does some mics. actions but these are usually really optional or even sometimes could be unwanted. Most notable useful thing is removal of obsolete packages. Yet, this python shit can take about 10 minutes to compute what to remove on weak hardware and then it sometimes miscalculates and removes really wrong things, he-he. Not to mention it fails to start with 50% probability due to wrong python version, and even if it started, there is 50% chance it would fail to find more recent ubuntu version, even if I can see it with my browser/wget. So most of times I prefer to switch repos manually. In this mode Ubuntu can last for a while and actually not too much different from Debian

            Comment


            • #16
              Originally posted by Michael View Post
              Yes, and there are Fedora and openSUSE systems in the farm.... The Ubuntu systems are largely for having reliable daily Clang and Linux kernel packages that I've always had good success with, they're kept around for a few days if others want to reproduce something off them, etc. Any other distribution with splendid daily kernel and Clang mainline/vanilla builds?
              I don't know about Clang, but https://build.opensuse.org/package/s...kernel-vanilla seems to be a daily kernel build. I can't comment as to how good it is though.

              Comment


              • #17
                Did you try
                Code:
                /usr/bin/grub-editenv /boot/grub/grubenv unset recordfail
                I think it would have to run upon every startup

                Comment


                • #18
                  You could a repository with a modified grub2 with different preset. Could be used to update pts as well. Should not be that hard.

                  Comment


                  • #19
                    Originally posted by SystemCrasher View Post
                    They have really antique kernel, MESA and nearly all programs. So it is outdated even before it released. This makes Debian hard to use with more or less recent hardware or if you want more or less recent software. And if one is about to go for Testing or Unstable... it could be far worse than Ubuntu. So I think ubuntu actually got best policy for desktop. Though their updater sucks very hard for sure as it fails to update system half of time (but what one can expect from silly Python script?!). However, update as such is: switch repos, do apt-get "update" and then "dist-upgrate". Their python shit sometimes does some mics. actions but these are usually really optional or even sometimes could be unwanted. Most notable useful thing is removal of obsolete packages. Yet, this python shit can take about 10 minutes to compute what to remove on weak hardware and then it sometimes miscalculates and removes really wrong things, he-he. Not to mention it fails to start with 50% probability due to wrong python version, and even if it started, there is 50% chance it would fail to find more recent ubuntu version, even if I can see it with my browser/wget. So most of times I prefer to switch repos manually. In this mode Ubuntu can last for a while and actually not too much different from Debian
                    I've found it safer to do apt-get updat, upgrade, possible reboot, then dist-upgrage and then definitely a reboot

                    Comment


                    • #20
                      Originally posted by Michael View Post
                      Yes, and there are Fedora and openSUSE systems in the farm.... The Ubuntu systems are largely for having reliable daily Clang and Linux kernel packages that I've always had good success with, they're kept around for a few days if others want to reproduce something off them, etc. Any other distribution with splendid daily kernel and Clang mainline/vanilla builds?
                      Off to the WIKI docs I go, and I find:

                      OIBAF equivalent:

                      [mesa-git]
                      SigLevel = PackageOptional
                      Server = http://pkgbuild.com/~lcarlier/$repo/$arch

                      I can't find a repo for mainline kernel, as most of us build is using the AUR, which of course can a consume bit of time. You can however script it to include patches during build, which has it's own advantage.

                      There're good lists of unofficial repos here:



                      There is also a kde-git repo, a gnome-git repo, a pfkernel repo (not sure if it is up to date, as most people are kind of over it I think)

                      TLDR: there is no arch repo for mainline, although you can easily automate the mainline kernel build, it will need to compile it. Most other requirements have common repos.
                      Last edited by jaxxed; 27 March 2015, 03:30 AM. Reason: english, and kernel patch comment added

                      Comment

                      Working...
                      X