| svendre | hello, I am interested in testing the 19.10 release. My question is, if I install the OS (not liveboot) on top of ZFS, how difficult would it be to change it to a newer, official release in the future while leaving the initial ZFS filesystem infrastructure in place? I realize I could have problems with a beta and the filesystem it creates, but my understanding is that the filesystem itself is mature, and the beta is | 16:56 |
|---|---|---|
| svendre | mostly about the installer process.. | 16:56 |
| svendre | I'm pretty excited about this release, despite the licensing stuff I've heard, I think ZFS (on root) is a huge milestone for linux | 16:57 |
| tomreyn | svendre: the plan (and an implementation which is in the works) is to add experimental (!) ZFS support to the 19.10 desktop installer. if future ubuntu versions will also support ZFS you'll be able to upgrade to those. i am unsure whether predictions on whether this will be the case are currently possible. | 17:08 |
| svendre | tomreyn: I guess I was talking about if I download the daily image now (before the final release of 19.10 or newer), when the final release comes out, can the "beta" releases or whatever you call them be upgraded to the final releases? | 17:14 |
| tomreyn | svendre: while none of this is supported, yes, you can usually upgrade pre-release installations to release versions just fine by installing updates. | 17:15 |
| svendre | tomreyn: thanks, good enough for me. I'll give it a try and report anything buggy if I encounter it. | 17:16 |
| tomreyn | svendre: if installation defaults would change in the meantime, though (such as, e.g., which parameters file systems are created with) you'd loose this change, though. | 17:16 |
| tomreyn | svendre: this said, i checked two days agao and back then is wasn't easily possible to test the daily installers with ZFS | 17:17 |
| svendre | tomreyn: ok. I'm a pretty good person to test it out, I guess it'll be exciting. | 17:18 |
| svendre | I was just playing with SmartOS.. oh man.. good ideas there, but really, typing in a huge UUID of an image name in low rez kind of turned me off. | 17:18 |
| === Kamilion|ZNC is now known as Kamilion | ||
| === luxifer_ is now known as luxifer | ||
| tomreyn | svendre: you're basically waiting for https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity/+merge/372690 | 17:20 |
| misternumberone | hi i am on 19.10 kernel 5.3 mesa 19.3 and I recently switched from NVIDIA to AMD. I use multihead and I need a single X screen across all monitors, so that fullscreen applications are never told the physical resolution, only the virtual resolution. This is achieved with Xinerama and nvidiaXineramaInfo setting when using the nvidia proprietary driver. However, using xrandr --setmonitor for the same result on AMD and the open | 22:56 |
| misternumberone | source mesa/amdgpu/RadeonSI driver like the arch wiki advises does not obscure the physical resolution from fullscreen applications. Is there a way to create a single X screen from multiple physical displays using amdgpu? | 22:56 |
| misternumberone | I am using 19.10 because my graphics card (radeon rx 5700 xt) is not supported by any kernel older than 5.3. The kernel documentation states that creating virtual displays for randr forwarding should be supported, but when I add that kernel parameter it does not add any virtual displays to xrandr. https://dri.freedesktop.org/docs/drm/gpu/amdgpu.html | 22:58 |
| tomreyn | bionic-proposed (18.04 LTS) has linux-image-generic-hwe-18.04-edge | 5.3.0.12.83 | 23:07 |
| misternumberone | tomreyn: thanks for the suggestion but it appears that the newest mesa for bionic is 19.0.8 and support for my graphics card was added in 19.2 | 23:13 |
| tomreyn | oh ok. then, unless oibaf or padoka also offer this mesa version *and* a 5.3+ kernel image, you're doing exactly the right thing. ;) | 23:14 |
| tomreyn | do you want me to have a look at and second guess whether you configured amdgpu's virtual_display correctly? | 23:24 |
| tomreyn | i'm not sure this is actually what you want / need, though | 23:24 |
| tomreyn | misternumberone: maybe this would be an alternative: https://www.displaylink.com/products/find?cat=3&res=3840x2160&num=2&vid_dp=1 | 23:34 |
| tomreyn | though i don't know how performant those are, never used their products. but they're said to usually work fine on ubuntu. | 23:34 |
| misternumberone | tomreyn: sure here is my grub cfg also i am reading about that product https://paste.linux.community/view/raw/01d8d296 and im a little busy ill respond soon | 23:40 |
| tomreyn | that's unrelated, but in case you don't know it, and since you seem to be a power user, you may be interested in this as well: https://www.mesa3d.org/envvars.html | 23:41 |
| tomreyn | note there's also #amdgpu here on freenode. this is mostly used by driver developers, but maybe they'd help there, too. | 23:42 |
| tomreyn | the user named Venemo has actually answered support questions there in the past. | 23:44 |
| tomreyn | about virtual_display, have you tried amdgpu.virtual_display=0000:01:00.0,1 instead? i assume you have verified that this address points to the correct device by using lspci -s 0000:01:00.0,1 ? | 23:51 |
| tomreyn | (i'm suggesting to add the extra 0) | 23:52 |
| tomreyn | i assume what virtual_display really does is to just add more (virtual) 'screens' though, which can then be configured, too. | 23:53 |
| misternumberone | "lspci -s 0000:01:00.0" yields "01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Device 1478 (rev c1)", if I add the ",1" it yields "lspci: -s: Invalid function number". I can add the 0 you did and try that just in case, even though lspci doesn't seem to need the 0 | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!