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.
Announcement
Collapse
No announcement yet.
Focal Testing of Kubuntu 20.04 LTS
Collapse
This topic is closed.
X
X
-
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.
- Top
- Bottom
Comment
-
Originally posted by GreyGeek View PostBooting 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.
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
I am not sure what I did differently to you in the installation for it to work so well for me.
- Top
- Bottom
Comment
-
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
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
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.
- Top
- Bottom
Comment
-
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
- Top
- Bottom
Comment
-
Originally posted by jlittle View PostBTW, 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.
- Top
- Bottom
Comment
-
Originally posted by jlittle View PostBTW, 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.
- Top
- Bottom
Comment
-
Originally posted by Don B. Cilly View PostThis absurd fixation of developers on using live media for everything will end... eventually.
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 }
When I tried to fire the "live-only" menu entry it gave me:
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.
- Top
- Bottom
Comment
-
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.
- Top
- Bottom
Comment
-
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:
- [*=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 - [*=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:
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.
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.
- Top
- Bottom
Comment
- [*=left]Install grml-rescueboot
-
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:- When one gets the "can't get info on device" busybox error, press control-d.
- One then gets a different busybox error.
- Run the command "mount -o loop /cdrom/casper/filesystem.squashfs /filesystem.squashfs"
- 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
- Top
- Bottom
Comment
-
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
- Top
- Bottom
Comment
Comment