| === diddledan5 is now known as diddledan | ||
| lotuspsychje | good morning | 04:13 |
|---|---|---|
| Haxxa | What is ubuntu-ports? | 04:24 |
| lotuspsychje | !discuss | Haxxa | 04:24 |
| ubottu | Haxxa: Want to talk about Ubuntu, but don't have a support question? /join #ubuntu-discuss for non-support Ubuntu discussion, or try #ubuntu-offtopic for general chat. Thanks! | 04:24 |
| Haxxa | For 20.04 the mirror I am using is http://ports.ubuntu.com/ubuntu-ports in my sources? | 04:24 |
| Haxxa | lotuspsychje, its related to my question about upgrading 20.04 on my raspi | 04:25 |
| Haxxa | I am running Ubuntu 20.04 on my Raspberry Pi | 04:25 |
| Haxxa | and I was wondering if this was the official source and if I can just apt upgrade to official 20.04 on release | 04:25 |
| lotuspsychje | Haxxa: the official daily 20.04 iso's are in the topic here | 04:28 |
| Haxxa | lotuspsychje, this is what I used, are these not official: http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/HEADER.html | 04:30 |
| lotuspsychje | looks legit to me | 04:33 |
| dngray[m] | 20.04 here we come | 04:43 |
| Haxxa | lotuspsychje, sure does just not sure why the repo is ubuntu-ports rather than the normal repo | 04:49 |
| dngray[m] | thinking this fresh machine, i might install with 20.04 (as it probably won't get used for half a month) | 04:55 |
| dngray[m] | and by then it should all be frozen, for my friend who's going to take ownership | 04:56 |
| dngray[m] | enough time for me to make sure everything works | 04:56 |
| dngray[m] | pretty bog standard configuration, AMD 3700X, amdgpu | 04:57 |
| dngray[m] | that way he won't have to upgrade it as soon as getting it 🙂 | 04:57 |
| Haxxa | dngray[m], makes sense | 05:32 |
| dngray[m] | in fact could actually be worthwhile as i think the newer kernel had some amdgpu fixes | 05:33 |
| dngray[m] | for 5700XT navi cards | 05:33 |
| bigfoot- | Hmm. After upgrading to focal, hibernate-disk seems to be broken. https://bugs.launchpad.net/ubuntu/+source/hibernate/+bug/1866984 | 11:07 |
| ubottu | Launchpad bug 1866984 in hibernate (Ubuntu) "hibernate-disk resumes instantly" [Undecided,New] | 11:07 |
| lotuspsychje | bigfoot-: have you tested to reproduce this on a clean daily yet? | 12:18 |
| pragmaticenigma | dngray[m]: Are you still in? If you are... I would not recommend installing 20.04 as the version you will be installing is going to be in dev mode. Meaning that when work starts on 20.10, the machine will start upgrading packages being worked on for the 20.10 release. Always use with the current supported releases like such as 16.04, 18.04, and 19.10. Especially if you plan on giving this machine to someone else | 12:28 |
| dngray[m] | yes i am | 12:29 |
| dngray[m] | <pragmaticenigma "dngray: Are you still in? If you"> ah okay | 12:29 |
| dngray[m] | i'd kinda hoped that wouldn't be the case | 12:29 |
| dngray[m] | in the past with Debian, i had very close to released used testing net install media | 12:29 |
| dngray[m] | which ended up just becoming "stable" | 12:30 |
| dngray[m] | would i have to wait for RC1 for that? | 12:30 |
| dngray[m] | it'd have the focal codename, for the apt repositories, so i'm not sure why things from 20.10 would be pulled in | 12:30 |
| pragmaticenigma | dngray[m]: Because apt would be set to pull from the dev channel | 12:30 |
| dngray[m] | ah | 12:31 |
| dngray[m] | so works a bit differently to how i remember then | 12:31 |
| dngray[m] | might just wait then, until it's released and go and update it | 12:32 |
| pragmaticenigma | dngray[m]: Personally I wait until July or August when 20.04.1 is released. Usually by then any lingering bugs from the initial release have been flushed out and the system is quite stable | 12:33 |
| dngray[m] | well that's true i guess | 12:33 |
| dngray[m] | no rush i guess, the auto updater works pretty awesome from memory | 12:33 |
| dngray[m] | ie to switch from one supported release to another | 12:33 |
| dngray[m] | and nothing should be different in terms of (filesystem, dmcrypt, etc) between those two releases so won't need a fresh install | 12:34 |
| pragmaticenigma | dngray[m]: If you want to avoid the large influx of updates, post install, I'd recommend installing from the mini.iso. That installer pulls packages from the Internet during install. And those are always the most up-to-date | 12:34 |
| dngray[m] | i already did do that | 12:34 |
| dngray[m] | had the system ready to give to friend for 2 months, but couldn't because we were waiting on DoA RAM | 12:35 |
| dngray[m] | and there's been major shortages of samsung ram, due to the power failure in the south korean facility | 12:35 |
| dngray[m] | so i already had installed 19.10 on it | 12:36 |
| pragmaticenigma | cool | 12:36 |
| dngray[m] | (and it sat in its box unused for 2 months) lol. | 12:36 |
| pragmaticenigma | 2 months... far number of updates, but nothing that will take hours at this point | 12:37 |
| dngray[m] | there's a few machines i'm planning on updating to 20.04 for friends/family | 12:37 |
| pragmaticenigma | *fair | 12:37 |
| dngray[m] | i have deb cache anyway on my server | 12:37 |
| dngray[m] | so will take longer to download than install hehe | 12:38 |
| dngray[m] | err install than download | 12:38 |
| bigfoot- | lotuspsychje: No. | 12:46 |
| lotuspsychje | bigfoot-: can you try please, then describe that in the bug ID you found? | 12:46 |
| bigfoot- | lotuspsychje: since this requires a full install on a HDD (hibernate from a live DVD or USB stick doesn't make much sense), I'm not sure whether I can soon spend the time and effort to find a suitable machine and set it up with a daily. | 12:56 |
| bigfoot- | maybe I'll try it in a virtual environment later. | 12:58 |
| Haxxa | "Welcome to Ubuntu Focal Fossa (development branch)" will that become "Welcome to Ubuntu Focal Fossa" upon release? | 13:01 |
| lotuspsychje | !final | Haxxa | 13:01 |
| ubottu | Haxxa: If you install a development version of Ubuntu Focal and keep up with package updates, then you will be upgraded to the official release of 20.04 when it comes out. To make sure, type « sudo apt update && sudo apt full-upgrade » in a terminal. | 13:01 |
| Haxxa | ok | 13:02 |
| lotuspsychje | bigfoot-: is this your bug report, or reported from someone else? | 13:02 |
| Haxxa | I have some production machines that won't be used until october, can I install focal now and upgrade later in April to full release, just like its production install? | 13:03 |
| Haxxa | as they aren't in production yet | 13:03 |
| Haxxa | have free time due to Carona virus so its ideal timing right now | 13:03 |
| lotuspsychje | Haxxa: production machines, use the LTS way and wait for upgrade till 20.04.1 comes out | 13:03 |
| lotuspsychje | from 18.04 that is | 13:04 |
| bigfoot- | lotuspsychje: Mine. | 13:05 |
| lotuspsychje | bigfoot-: could you also attach your dmesg to the bug report please? | 13:05 |
| lotuspsychje | bigfoot-: and maybe also your computer brand/model in the description | 13:06 |
| bigfoot- | IMHO the most interesting part is already in the report | 13:09 |
| bigfoot- | let's see, maybe I can reproduce this in KVM. | 13:11 |
| bigfoot- | (with a clean install from focal dev daily) | 13:11 |
| bigfoot- | I attached the requested info. And it seems I can reproduce the issue with a clean kubuntu focal dev install within KVM / QEMU. | 13:23 |
| === pavlushka_ is now known as pavlushka | ||
| bigfoot- | added reproduction info to the bug report. | 13:32 |
| lotuspsychje | ok tnx bigfoot- | 13:34 |
| lotuspsychje | bigfoot-: your first dmesg on the lenovo, gives alot of acpi errors inside, i wonder if its your machine specific bugging | 13:35 |
| bigfoot- | A colleague of mine could reproduce this issue on a completely different machine. | 13:35 |
| lotuspsychje | bigfoot-: did he also affect the bug? | 13:36 |
| bigfoot- | Yes. | 13:36 |
| lotuspsychje | ok great | 13:36 |
| bigfoot- | And, as I said: I can reproduce this within KVM | 13:36 |
| bigfoot- | (steps to reproduce are in the bug report now) | 13:36 |
| bigfoot- | ... and: This has worked on my Lenovo for a long time, up until and including Ubuntu 19.10. | 13:40 |
| pragmaticenigma | bigfoot-: I'm not 100% certain, but I have a hard time believing testing hibernate in a VM is a valid test. As the VM may or maynot have that as part of the simulated system BIOS | 13:41 |
| bigfoot- | I'm not sure whether there's any hard requirement to HW when it comes to hibernation; after all, the system is fully powered off afterwards, and boots normally until Linux realizes it's been hibernated before. | 13:42 |
| bigfoot- | But it's possible that you're right, yes. However, I don't have the means right now to do this on a real install on real HW. | 13:43 |
| bigfoot- | I'll test this with Ubuntu 19.10. | 13:44 |
| bigfoot- | Ubuntu 19.10 shows a different behavior: hibernate-disk seems to actually save the state, and powers off the (virtual) machine. Resuming, however, doesn't work; I'm not sure whether this is due to the fact that in a default install, swap is /swapfile instead of a separate partition. | 14:29 |
| bigfoot- | works with the proper resume=/swapfile kernel param. Will do some more testing with 20.04, maybe I can get this to work after all. | 14:42 |
| === oerheks1 is now known as oerheks | ||
| bigfoot- | pragmaticenigma: I think I juts proved you wrong; I successfully hibernate-disk and resume on a clean eoan install in qemu-kvm, and can reproduce the faulty behavior with focal there as well. | 16:05 |
| bigfoot- | s/juts/just/ | 16:05 |
| pragmaticenigma | i never said it couldn't be done... I said that the archesture of the VM may not fully emulate what would happen on a install the main hardware. The VM could map power states to other states to satisfy the triggers within the guest system. So no... you really haven't proved anything. you're testing a feature that is intended for system that are run on actual hardware, not in a virtualized instance | 16:07 |
| bigfoot- | Well. At least it works in the KVM/QEMU environment exactly as it should, using a clean 19.10 Eoan install; and it exhibits exactly the faulty behaviour I see on the real hardware when trying the same with a clean 20.04 Focal install. | 16:11 |
| bigfoot- | Close enough for me. | 16:11 |
| Ussat | ... | 16:12 |
| pragmaticenigma | so many apples... so many oranges | 16:13 |
| Ussat | You can compare a VM with physical in a LOT of ways, BIOS is not one of them | 16:15 |
| bigfoot- | I don't really get what I could do more; I found a regression bug in 20.04, reproducible to be a regression from 19.10 to 20.04 on two different pieces of hardware *and* in KVM. Provided the exact steps to reproduce the issue with KVM (and probably also any other real HW). | 16:15 |
| bigfoot- | That QEMU's BIOS isn't the same as Lenovo's is not something I dispute. | 16:16 |
| bigfoot- | But unless I'm seeing two different bugs at once -- possible, but I don't see any indication for that -- fixing this in QEMU should also fix it on real HW. | 16:18 |
| lotuspsychje | this is just why i always advice to test clean dailys | 16:19 |
| lotuspsychje | to avoid all the noise around | 16:19 |
| bigfoot- | That's what I did, in a VM environment. | 16:20 |
| pragmaticenigma | bigfoot-: There are 8 different power states that can be defined by the system hardware. 3 of them can be used in various combinations to achieve "Hibernate" ... This is why hardware testing is more valid than your VM... Hibernate can be accomplished with different approaches. The most basic is where the OS dumps RAM to disk and then triggers G3. After that there is S4, which is almost the same but leaves some hardware enabled, | 16:20 |
| pragmaticenigma | to allow for a faster startup when full power is provided again or to recover in the event power is lost during the S4 state. | 16:20 |
| lotuspsychje | yeah well like pragmaticenigma said, VM's are not always great for testing bugs | 16:20 |
| pragmaticenigma | Power states are among the hardest things to troubleshoot. As you can't exactly capture system states after power is cut to the system. | 16:23 |
| pragmaticenigma | That is my primary reason in all support that I do, when someone says suspend-to-ram or suspend-to-disk isn't working... that it's better to find something that does work reliably, than to try and troubleshoot something, that is quite possibly a BIOS/systemfirmware or an edge case where the manufacture didn't follow specifications in order to cut costs. | 16:25 |
| bigfoot- | a) it worked before, for years and dozens of kernel versions b) it shows the same behavior in a controlled VM environment | 16:26 |
| pragmaticenigma | bigfoot-: drop the part about VMs and you have a valid bug report | 16:26 |
| qwertuttyty | https://aliexpress.ru/wholesale?catId=0&initiative_id=SB_20200311095054&SearchText=VIA+VL805 | 17:52 |
| lotuspsychje | not here qwertuttyty | 17:52 |
| qwertuttyty | if no for the test | 17:53 |
| qwertuttyty | here or on kernel irc | 17:54 |
| lotuspsychje | qwertuttyty: this channel is for ubuntu 20.04 support | 17:54 |
| qwertuttyty | i use ubuntu-mate | 17:54 |
| qwertuttyty | 5.4 5.5 5.6 does not mount usb with via VL805 ehci | 17:56 |
| qwertuttyty | xhci | 17:58 |
| qwertuttyty | bug not witch ubuntu bug in kernel 5.4 5.5 5.6 ubuntu 20.04 use kernel 5.4. I use ubyntumate 19.10 with krernel 5.6 | 18:01 |
| qwertuttyty | with | 18:01 |
| qwertuttyty | bug not witch ubuntu bug in kernel 5.4 5.5 5.6. Ubuntu 20.04 use kernel 5.4. I use ubyntumate 19.10 with krernel 5.6 | 18:02 |
| qwertuttyty | bug trekker have info about bug from 2016 year. I u I have been using VL805 since 2019 | 18:06 |
| qwertuttyty | humor in virtual machine no prblelem with usb/ Host windows guest u-mate 20.04 kernel 5.5... | 18:13 |
| qwertuttyty | kernel bug trekker have info about bug from 2016 year. I u I have been using VL805 since 2019 | 18:20 |
| lotuspsychje | qwertuttyty: please dont flood random problems in here | 18:21 |
| lotuspsychje | qwertuttyty: ask 1 ubuntu question, then wait and be patient until volunteers can help you | 18:21 |
| qwertuttyty | The only question is when the bug be fixed, but there will be no answer. | 18:25 |
| lotuspsychje | qwertuttyty: do you have a bug ID please? | 18:25 |
| qwertuttyty | for usb xhci VL805 can not mount USB device | 18:26 |
| lotuspsychje | qwertuttyty: do you have a BUG number on launchpad for that problem? | 18:28 |
| qwertuttyty | About a month ago i pressed the bug link 2016, pressed kerne.log | 18:28 |
| qwertuttyty | I can not find now, ask your colleagues in the chat someone saw. Or search on kernel.org | 18:36 |
| hggdh | qwertuttyty: that is not quite it works. If there is a mainstream kernel issue, it has to be followed/worked mainstream | 18:41 |
| qwertuttyty | I do not know why kernel developers have not fixed this bug yet. This is a question for them. | 18:55 |
| qwertuttyty | 2016 | 18:55 |
| oerheks | there is no bug, you used a test kernel | 19:05 |
| qwertuttyty | if you didn’t saw the link to the bug in Kerenel it doesn’t mean that there is no bug | 19:11 |
| qwertuttyty | use VL805 and you can saw | 19:11 |
| Bashing-om | !info nvidia-driver-440 focal | 19:12 |
| oerheks | published test kernel in mainline does not mean they are used in a release | 19:13 |
| ubottu | nvidia-driver-440 (source: nvidia-graphics-drivers-440): NVIDIA driver metapackage. In component restricted, is optional. Version 440.59-0ubuntu2 (focal), package size 404 kB, installed size 1153 kB | 19:13 |
| bigfoot- | Ah. It seems to be the kernel. When I boot into the (still installed) 5.3 kernel, hibernate-disk/resume works fine; when booting into 20.04's regular 5.4 kernel, it fails as described in the bug report. https://bugs.launchpad.net/ubuntu/+source/linux-5.4/+bug/1866984 | 19:40 |
| ubottu | Launchpad bug 1866984 in hibernate (Ubuntu) "hibernate-disk resumes instantly" [Undecided,Confirmed] | 19:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!