Announcement

Collapse
No announcement yet.

Focal Testing of Kubuntu 20.04 LTS

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

    #16
    At the moment, the focal archive is still in a pre-release freeze for 'general development'. Currently the release team and core developers are carrying out major transitions of perl and python versions, and doing other preliminary changes to get things into a workable state to proceed. So please do not expect any stability quite yet.
    On #kubuntu-devel & #kubuntu on libera.chat - IRC Nick: RikMills - Launchpad ID: click

    Comment


      #17
      I fully understand. One problem that I have is that I have a VERY HIGH REGARD for the developers ability. From past experience they do an excellent job and a 1 or 2 day glitch does not bother me.

      I also understand that you prefer forum members to not use pre-release options. So because I do this as well I am taking a double risk. Since Focal is on my testing Laptop, it does not matter if Focal goes US for a short time.

      Comment


        #18
        Originally posted by GreyGeek View Post
        Booting up I discovered that unlike the release on the 22nd, the release today, the 24th, runs like molasses. Calling it slow is a compliment.

        I may play with it a couple more days and then wait until January or February before I pick it up again.

        Sometimes It takes 20 seconds or longer for the DE to respond to mouse clicks or typing ... For all practical purposes the app being used appears to be hung, so one has to be patient.
        $ systemd-analyze
        Startup finished in 1min 13.776s (kernel) + 2min 48.120s (userspace) = 4min 1.897s
        graphical.target reached after 2min 48.110s in userspace
        [/console]
        When I highlighted that output to copy it into this post it took the left mouse popup 20 seconds to appear.
        Because of the problems you have had, I decided to try installing Focal on a 64GB Sandisk that I have. I downloaded the 10-25 version and defined the btrfs file system for it. I also copied all my hidden files (over 100,000 files) from the Laptop SSD Focal system.

        The final stage of the Focal install included the Nvidia driver and I also get the message on login about the touchpad being disabled.

        I have updated the system and it still responds well for a usb disk. My systemd-analyze gives:
        Code:
        :~$ systemd-analyze
        Startup finished in 2.882s (firmware) + 9.407s (loader) + 4.842s (kernel) + 4.272s (userspace) = 21.404s 
        graphical.target reached after 4.263s in userspace
        As you can see this is only slightly slower than my Laptop system.

        I am not sure what I did differently to you in the installation for it to work so well for me.

        Comment


          #19
          For the installation USB I use the KDE startup disk creator. I find that this will allow the installation of Focal on a btrfs file system. My installed system had both the @ and @home areas. Just to check that the startup disk creator would allow an update of the system, I tried another test install and found that if I could select the previous installation.

          I am not sure if GG's use of mkusb for the installation usb provides useful options. However his use of mkusb did lead to problems with his installed system. I did install it and was overwhelmed by all the options which made no sense to me, so I decided to stay with the KDE approach.

          One feature that I have noticed with btrfs, is the need to copy all files in the @home onto a suitable external storage before installing a new system.

          I have now done two separate installations of a Focal system. The first was with btrfs and this installation was then replaced by one with ext4 on my 64GB sandisk. The systemd-analyze command for the Focal btrfs system gave the following:
          Code:
          Startup finished in 3.829s (firmware) + 9.544s (loader) + 2.946s (kernel) + 13.913s (userspace) = 30.233s 
          graphical.target reached after 10.340s in userspace
          For the Focal system with ext4 I get:
          Code:
          Startup finished in 3.346s (firmware) + 11.210s (loader) + 3.981s (kernel) + 11.130s (userspace) = 29.669s 
          graphical.target reached after 11.122s in userspace
          From this test, the btrfs is overall faster. My impression is that the login-in is faster with the ext4 system.

          I feel that it is up to the Focal installer to decide what file system to use. All I can say is that ext4 gives acceptable performance.
          Last edited by NoWorries; Oct 28, 2019, 02:57 AM. Reason: Removed error that ext4 did not journal

          Comment


            #20
            Originally posted by NoWorries View Post
            All I can say is that for a non-journal file system, ext4
            That's confusing; ext4 is a journaling file system.
            Regards, John Little

            Comment


              #21
              BTW, IMO using utilities like startup disk creator, mkusb, or the like are a huge, fraught, waste of time and effort, if you're doing multiple installs on the same machine. Just download and boot into the iso using the applicable grub incantation. It can be faster, too, if you download onto an SSD, their being faster than USB media. Writing to a USB is only necessary if the install is to a another machine that has no OS. and even then I usually prefer to just copy the iso to a trusty bootable USB (that has grub installed), using dolphin.
              Regards, John Little

              Comment


                #22
                Thanks for the correction. I have removed the reference that ext4 did not journal.

                Comment


                  #23
                  Originally posted by jlittle View Post
                  BTW, IMO using utilities like startup disk creator, mkusb, or the like are a huge, fraught, waste of time and effort, if you're doing multiple installs on the same machine.
                  The only reason I was taking the approach that I did was because GG was having trouble with Focal on his 64GB usb using mksub for a btrfs file system. His problem was reported #12 on this forum.

                  Comment


                    #24
                    Originally posted by jlittle View Post
                    BTW, IMO using utilities like startup disk creator, mkusb, or the like are a huge, fraught, waste of time and effort, if you're doing multiple installs on the same machine. Just download and boot into the iso using the applicable grub incantation. It can be faster, too, if you download onto an SSD, their being faster than USB media. Writing to a USB is only necessary if the install is to a another machine that has no OS. and even then I usually prefer to just copy the iso to a trusty bootable USB (that has grub installed), using dolphin.

                    Would you elaborate: "boot into an iso using the applicable grub incantation." Using grub on a live system to boot into an ISO residing on that live system? Or, are you referring to using the mount command with the -loop parameter?
                    Never mind.
                    https://help.ubuntu.com/community/Gr...ER%20or%20F10.

                    In 20 years of using Linux that is something I never did or even knew of.
                    Last edited by GreyGeek; Oct 28, 2019, 02:47 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


                      #25
                      This absurd fixation of developers on using live media for everything will end... eventually.

                      Comment


                        #26
                        Originally posted by Don B. Cilly View Post
                        This absurd fixation of developers on using live media for everything will end... eventually.
                        That's pretty much what jlittle was talking about when he referred to grub incantations. Following his lead I found an Ubuntu web page discussing how to do that, which I linked above. I saved the focal iso to /mnt/iso and I then modified an example entry for 40_custom under /etc/grub.d as follows:

                        Code:
                        menuentry "focal-desktop-amd64 iso - live-only" {
                           set isofile="/@/mnt/iso/focal-desktop-amd64.iso"
                           loopback loop (hd0,1)$isofile
                           linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noprompt noeject
                           initrd (loop)/casper/initrd
                        }
                        
                        
                        menuentry "focal-desktop-amd64 iso - persistent" {
                           set isofile="/@/mnt/iso/focal-desktop-amd64.iso"
                           loopback loop (hd0,1)$isofile
                           linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile persistent noprompt noeject
                           initrd (loop)/casper/initrd
                        }
                        Then I ran "sudo update-grub".

                        When I tried to fire the "live-only" menu entry it gave me:
                        Click image for larger version

Name:	loop_error.jpg
Views:	1
Size:	111.0 KB
ID:	644362

                        When I added "/@/dev/" to the loop reference, "/@/dev/loop", it reported that it couldn't find the kernel.
                        I can't connect "/@" to initramfs in the menuentry.
                        I'm at a catch-22.
                        Last edited by GreyGeek; Oct 28, 2019, 05:30 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


                          #27
                          Well, if you've read the thread I referred to, you might agree that incantations like grub or debootstrap are absolutely unnecessary.
                          All it would take would be one developer who knows a little about how *buntus are actually installed, and an appimage/bin/exe would be there in a whiff.
                          Because if you uncompress a *buntu iso and unsquash the squashfs. you'll see that to modify the installer (calamares would be a good start) just enough, it would be a whiff to write. For Mac, Windows, and Linux.

                          Comment


                            #28
                            I've been testing various prefixes to the iso file so that the system can find them from the menuetry setup. All have failed.

                            So, I read about the grml-rescueboot option:

                            To use the grml-rescueboot option:
                            1. [*=left]Install grml-rescueboot

                              sudo apt-get install grml-rescueboot

                              [*=left]Place bootable ISO files in the /boot/grml folder.
                              • [*=left]Since this is a system folder, the operation must be conducted as "root". For example, if the ISO is located in the user's Downloads folder, the command would be:
                                [*=left]sudo mv ~/Downloads/<filename.iso> /boot/grml/


                              [*=left]Update GRUB
                              [*=left]sudo update-grub


                            It, too, failed, with the same type of error as the previous attempts. Even the system generated boot process can't find what it needs to successfully boot the iso and bring up the desktop.
                            Click image for larger version

Name:	loop_error2.jpg
Views:	1
Size:	34.0 KB
ID:	644363

                            The problem is in the requirement to use "/@" as the path prefix. You can do that inside 40_custom, as shown above, but the path prefix doesn't stick when the boot process tries to find the loop devices, which should be /@/dev/loop0", since the only way the grub menu can find the iso is with
                            "
                            set isofile="/@/mnt/iso/focal-desktop-amd64.iso"

                            Changing any or all of the "loop" references, regardless of which ones or which order, to "/@/dev/loop0", or similar prefixes, and I tried every prefix I could thing of, does not work.

                            BTW, the iso check sum was verified and I have a live USB stick made from it that boots successfully.
                            Last edited by GreyGeek; Oct 28, 2019, 07:24 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


                              #29
                              I'm sorry, I should have checked out what I was suggesting, before I suggested it. Problems with iso booting in the testing phase seem common; in that the eoan daily isos could not iso boot, due to a casper script mismatch, for a long time.

                              For the focal iso, I stumbled onto a workaround:
                              1. When one gets the "can't get info on device" busybox error, press control-d.
                              2. One then gets a different busybox error.
                              3. Run the command "mount -o loop /cdrom/casper/filesystem.squashfs /filesystem.squashfs"
                              4. Press control-d.

                              I don't understand what goes wrong at all. Possibly there's an improved grub incantation for focal to sort the loop device error, but it's a mystery to me.
                              Regards, John Little

                              Comment


                                #30
                                From a wider focal fossa testing perspective, I'd like to report the iso boot problem, and the workaround, somewhere, somehow, and I've wasted far too much time searching launchpad to find the right way to create a bug. Launchpad seems very oriented around packages, and I don't know what package is involved.

                                Can anyone tell me the best way to report a problem with the 20.04 iso?
                                Regards, John Little

                                Comment

                                Working...
                                X