Re: Learning ipv6 quirks
On 22/06/2021 11:41, Gordon Messmer wrote: On 6/21/21 6:17 AM, Robert McBroom via users wrote: @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:42:25 2021 mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused 1: Is the nfs port open on ipv6? Use "ss -ln | grep :2049" and look for a listening port with an IPv6 address, like: tcp LISTEN 0 64 [::]:2049 [::]:* Oh, and BTW, using the same mount command trying to mount a share from my Synology NAS using the link IPv6 address of the NAS fails. That is one of the reasons I feel the OP should be using the actual IPv6 address and not the link address. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 22/06/2021 11:41, Gordon Messmer wrote: On 6/21/21 6:17 AM, Robert McBroom via users wrote: @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:42:25 2021 mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused 1: Is the nfs port open on ipv6? Use "ss -ln | grep :2049" and look for a listening port with an IPv6 address, like: tcp LISTEN 0 64 [::]:2049 [::]:* 2: Does your firewall allow access to port 2049 on IPv6? Use "firewall-cmd --list-services" and look for "nfs", or use "ip6tables -L" and look for the input chain for your default zone (possibly IN_public_allow). I got the impression from the OP that the NFS server is not a Fedora system. When I asked about logging into the NFS and running the "ip addr show" command the response was "Web interface. It shows". That doesn't seem to be what one would do if the NFS server were Fedora based. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 6/21/21 6:17 AM, Robert McBroom via users wrote: @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:42:25 2021 mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused 1: Is the nfs port open on ipv6? Use "ss -ln | grep :2049" and look for a listening port with an IPv6 address, like: tcp LISTEN 0 64 [::]:2049 [::]:* 2: Does your firewall allow access to port 2049 on IPv6? Use "firewall-cmd --list-services" and look for "nfs", or use "ip6tables -L" and look for the input chain for your default zone (possibly IN_public_allow). ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
On 2021-06-21 4:29 p.m., Stephen Morris wrote: On 20/6/21 02:22, Ed Greshko wrote: On 19/06/2021 21:44, Stephen Morris wrote: My system has been upgraded from versions without ZRAM. That is the reason my system has a defined swap partition on disk. I don't see the connection between Video Memory and swap. As I understand it, because I'm not using a dedicated graphics card the video/graphics memory used by the vm is being sourced from real memory, and I assume as part of the memory allocation being given to the vm, hence would potentially increase the requirement for memory paging. The system graphics card is irrelevant. The VM display is virtual anyway, so I expect any memory used by the virtual graphics card comes from system RAM. VirtualBox has a per-VM setting for its display and video memory. At least that is the case for VirtualBox running as a host on linux. I seem to recall you're using VirtualBox on HW running Windows? I am running Virtualbox on a Windows 10 host as I am running on a raid 10 motherboard supplied raid environment and Fedora workstation won't install to raid (it can't see any devices), but having said that though, Windows 10 can't see any devices to install to, but the motherboard bios provides facilities to generate the necessary raid drivers to specify at windows install time, but unfortunately it doesn't generate linux drivers. The possible issue with video memory in virtualbox is the windows version of virtualbox only allows a maximum of 128MB to be allocated, which I think is no where near enough, hence the performance issues. This is also why I'm still using Vmware player, as it allows significantly more video memory allocation, and I was giving it 2GB of video memory, but with that I was getting performance issues (I was allocating 16GB of memory to the vm) and when I dropped the video memory allocation back to the recommended of 768MB performance improved. You don't mention how much RAM the computer has, but 2GB of video memory for a VM seems extremely excessive. Even the 768MB seems far beyond anything useful. There's a reason virtualbox has a max of 128MB. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 22/06/2021 05:41, Patrick O'Callaghan wrote: On Mon, 2021-06-21 at 21:18 +0800, Ed Greshko wrote: On 21/06/2021 20:31, Patrick O'Callaghan wrote: On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote: I thought I mentioned they should have been taken at the same time. journal starts at Jun 20 15:44:50 dmesg Sun Jun 20 22:38:39 2021 Kinda hard to match things that way. :-) OK, see reply to Chris below. Right. Well, I think it is well understood the HW in some form is responsible for the 30 sec delay in boot times. I see 3 avenues open. 1. Continue to search for the HW cause and hopefully fix it without incurring cost. 2. Find a way to ignore the HW during boot. 3. Live with the 30 second delay. I was looking at #2 but couldn't find a way with BTRFS raid. Maybe with software raid and ext4. I do wonder how many brain-seconds have collectively been used in search of a solution. :-) :-) -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 22/06/2021 07:34, Tom Horsley wrote: On Tue, 22 Jun 2021 07:25:23 +0800 Ed Greshko wrote: Could you define a bit more what you mean by "name resolution"? Or are you thinking about the Stateless IP assignment I mention in a different reply? I have no idea :-). Maybe what I read about had something to do with mdns providing symbolic names on the local lan? (I don't even know if that is a real thing :-). Well, mdns is related to use of the .local domain and Avahi/Bonjour. Neither of which I utilize. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On Tue, 22 Jun 2021 07:25:23 +0800 Ed Greshko wrote: > Could you define a bit more what you mean by "name resolution"? Or are you > thinking about > the Stateless IP assignment I mention in a different reply? I have no idea :-). Maybe what I read about had something to do with mdns providing symbolic names on the local lan? (I don't even know if that is a real thing :-). ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
On 20/6/21 02:22, Ed Greshko wrote: On 19/06/2021 21:44, Stephen Morris wrote: On 19/6/21 15:31, Ed Greshko wrote: On 19/06/2021 12:45, Stephen Morris wrote: Hi, I've noticed when trying remediate performance issues in F34 under a vm, that fedora does not have a swap specification in fstab anymore, but is using, in my case, and 8GB swap partition in /dev/zram0. Does this mean that if I create a swap partition of a bigger size and specify it in fstab it will be ignored? Ignored? No. But not primary. e.g. [egreshko@meimei ~]$ swapon NAME TYPE SIZE USED PRIO /dev/sda2 partition 16.9G 0B -2 /dev/zram0 partition 4.7G 0B 100 So, it may or may not be used. Alternatively, given the fedora is using it's own rules for determining the swap size based on the amount of memory available, is there any way to increase the size of /dev/zram0 so that there is more swap space available to the system? I think man zram-generator will help in that. Thanks Ed, I'll check that man data out. In my case with an auto storage configuration at F34 install time there isn't any swap entry in fstab or swap partition. I think I need to expand this in virtualbox as I think that virtualbox's lack of video memory is causing performance issues in F34. My system has been upgraded from versions without ZRAM. That is the reason my system has a defined swap partition on disk. I don't see the connection between Video Memory and swap. As I understand it, because I'm not using a dedicated graphics card the video/graphics memory used by the vm is being sourced from real memory, and I assume as part of the memory allocation being given to the vm, hence would potentially increase the requirement for memory paging. VirtualBox has a per-VM setting for its display and video memory. At least that is the case for VirtualBox running as a host on linux. I seem to recall you're using VirtualBox on HW running Windows? I am running Virtualbox on a Windows 10 host as I am running on a raid 10 motherboard supplied raid environment and Fedora workstation won't install to raid (it can't see any devices), but having said that though, Windows 10 can't see any devices to install to, but the motherboard bios provides facilities to generate the necessary raid drivers to specify at windows install time, but unfortunately it doesn't generate linux drivers. The possible issue with video memory in virtualbox is the windows version of virtualbox only allows a maximum of 128MB to be allocated, which I think is no where near enough, hence the performance issues. This is also why I'm still using Vmware player, as it allows significantly more video memory allocation, and I was giving it 2GB of video memory, but with that I was getting performance issues (I was allocating 16GB of memory to the vm) and when I dropped the video memory allocation back to the recommended of 768MB performance improved. regards, Steve ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 22/06/2021 00:48, Tom Horsley wrote: On Tue, 22 Jun 2021 00:37:56 +0800 Ed Greshko wrote: Oh, I forgot to mention that your IPv6 addresses appear to be Dynamically assigned IP addresses. Meaning they are not "fixed" and may change. Not the best for uses in a client/server environment. Isn't there some sort of automagic ipv6 name resolution? I've avoided ever learning anything about ipv6, but I swear I saw something about that in some overview once. Could you define a bit more what you mean by "name resolution"? Or are you thinking about the Stateless IP assignment I mention in a different reply? -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, 2021-06-21 at 11:47 -0600, Joe Zeff wrote: > On 6/21/21 3:14 AM, Patrick O'Callaghan wrote: > > Yes, that's been established (strictly, I haven't bothered swapping > > the > > drives in the dock to see what happens, but it's immaterial). Again, > > the issue is not that one drive takes time to spin up, but that the > > system start-up waits for it when it doesn't need to. > > Even so, if it's always the same drive, there might be something wrong > with it and if so, simply replacing that drive might be the simplest > solution. Just for kicks, I've uploaded the smartctl readings for both drives to the same cloud folder: https://drive.google.com/drive/folders/1H4XNTtZRaEgPUlGif2w-CR4Fof5OIqE0?usp=sharing I don't see anything alarming but I'm no expert. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, 2021-06-21 at 13:13 -0600, Chris Murphy wrote: > On Mon, Jun 21, 2021 at 10:58 AM Chris Murphy > > wrote: > > > > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 > > uas_eh_abort_handler > > 0 uas-tag 2 inflight: IN > > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 CDB: Mode Sense(6) > > 1a > > 00 08 00 18 00 > > > Yeah and in the install-boot log it happens again: > > > Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: tag#16 uas_eh_abort_handler > 0 > uas-tag 1 inflight: IN > Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: tag#16 CDB: Mode Sense(6) 1a > 00 08 00 18 00 > Jun 20 15:45:20 Bree kernel: scsi host6: uas_eh_device_reset_handler > start > Jun 20 15:45:20 Bree kernel: usb 4-3: reset SuperSpeed Gen 1 USB > device number 2 using xhci_hcd > Jun 20 15:45:20 Bree kernel: scsi host6: uas_eh_device_reset_handler > success > Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Write cache: enabled, > read cache: enabled, doesn't support DPO or FUA > Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Optimal transfer size > 33553920 bytes not a multiple of physical block size (4096 bytes) > Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Attached SCSI disk > > What's new here is the explicit USB reset message. I rebooted and took some new logs. However this time, for whatever reason, there was no 30-second delay. The logs are prefixed "nodelay-*" in the same directory. I then rebooted and this time there was a delay. These logs are labelled "delay-*". One interesting point is that in both cases I have to wait before getting some of these, e.g. $ systemd-analyze blame Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0). Please try again later. Hint: Use 'systemctl list-jobs' to see active jobs [poc@Bree ~]$ systemctl list-jobs JOB UNIT TYPE STATE 294 dock-watch.service start running 1 jobs listed. IOW the system thinks that boot hasn't finished because the dock-watch unit is still running, even after I've already logged in. Probably not important. nodelay-journal doesn't have the reset message, so that is clearly a clue to what's going on. [...] > Curiously there is no usb of a second ASM1156 product, even though > there are two: > > Jun 20 15:44:50 Bree kernel: scsi 6:0:0:0: Direct-Access ASMT > ASM1156-PM 0 PQ: 0 ANSI: 6 > Jun 20 15:44:50 Bree kernel: scsi 6:0:0:1: Direct-Access ASMT > ASM1156-PM 0 PQ: 0 ANSI: 6 > > > Jun 20 15:44:50 Bree kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte > logical blocks: (1.00 TB/932 GiB) > Jun 20 15:44:50 Bree kernel: sd 6:0:0:1: [sde] 1953525168 512-byte > logical blocks: (1.00 TB/932 GiB) > > > And they have their own /dev node. So is one in a USB enclosure and > the other isn't? Or maybe they are both just appearing as usb 4-3 > even > though they get different scsi id's - that's probably it. But then > one > of them is having some sort of issue, even if it's just confusion > that > results in the need for the kernel to do a reset on it. but *shrug* > this is the joy of USB, it's not necessarily a hardware problem per > se. There is a single dock with two slots and no other type of enclosure. The disks are internal SATA units inserted directly into the slots. The dock has a single dedicated USB-3 connection direct to the system motherboard with no intervening hub or splitter. It is independently powered via a wall socket and power block. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gsl
On Saturday, June 19, 2021 2:38:02 PM WEST Patrick Dupre wrote: > Hello, > > There is a new version of gsl (2.7). > http://www.gnu.org/software/gsl/ > > What are the plans to have it available in fc34? Historically all the new releases of gsl where never released in stable distributions. I am guessing that this pattern will be repeated this time as well. > Thanks > > === > Patrick DUPRÉ | | email: pdu...@gmx.com > Laboratoire interdisciplinaire Carnot de Bourgogne > 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE > Tel: +33 (0)380395988| | Room# D114A > === -- José Matos___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, 2021-06-21 at 21:18 +0800, Ed Greshko wrote: > On 21/06/2021 20:31, Patrick O'Callaghan wrote: > > On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote: > > > On 21/06/2021 19:48, Patrick O'Callaghan wrote: > > > > To avoid ambiguity, maybe you should tell me the journal > > > > options > > > > you´d > > > > like (the timestamps in the uploaded logs don´t show wallclock > > > > time). > > > The journal times of what you've supplied seem fine. They show > > > > > > Jun 20 15:44:50 for example > > > > > > and dmesg -T would show > > > > > > [Sun Jun 20 18:35:35 2021] > > > > > > So, they are easy to match up. > > I've replaced the dmesg file with the output of 'dmesg -T'. > > > > I thought I mentioned they should have been taken at the same time. > > journal starts at > > Jun 20 15:44:50 > > dmesg > > Sun Jun 20 22:38:39 2021 > > Kinda hard to match things that way. :-) OK, see reply to Chris below. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: packagekitd Hogging CPU
On Mon, Jun 21, 2021 at 7:18 AM Tim Evans wrote: > > $ uname -a > Linux harrier 5.12.11-300.fc34.x86_64 #1 SMP Wed Jun 16 15:47:58 UTC > 2021 x86_64 x86_64 x86_64 GNU/Linux > > As I sit here, my Lenovo T530 laptop is reporting packagekitd is taking > anywhere from 20 to 40 percent of CPU, per 'top.' There is continuous > disk activity. Nothing going on with the system other than Thunderbird > e-mail and Chrome browser. > > This seems to go on, with CPU percentage growing over time, and it > rebooting cures this, but it comes back after the system has slept > overnight (lid closed). PackageKit and dnf keep separate metadata in /var/cache and they update periodically. PackageKit seems to do this on login, but I've also noticed it trigger an update when I switch networks. And dnf is on a timer. Either of them can use a lot of cpu, it just depends on how much updating they need. Recently I've been experimenting with cgroups to restrict the amount of cpu packagekit gets via the packagekit.service unit. i.e. this is a service unit specific restriction, not on all instances of packagekit. Thus it doesn't affect offline updates, where it can still use 100% cpu if need be. But, it's possible GNOME Software could be a bit slower since it uses packagekit, though I haven't noticed any ill effect so far. $ sudo systemctl edit packagekit.service Read the file that appears and insert these two lines where it says to: [Service] CPUQuota=25% Save it out, and when the unit restarts (logout and login or do the daemon-reload followed by service restart dance) you'll see packagekit uses this value as a maximum. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
On Mon, Jun 21, 2021 at 1:25 PM Samuel Sieb wrote: > > On 2021-06-21 1:05 a.m., Bill Shirley wrote: > > The server is running on Raid-1 SSDs with 64GB of RAM > > > > Bill > > > > On 6/21/2021 3:41 AM, Samuel Sieb wrote: > >> On 6/20/21 7:25 PM, Bill Shirley wrote: > >>> One of the first things I did after installing F34 is disable > >>> swap-on-zram: > >>>touch /etc/systemd/zram-generator.conf > >>> and define a swap partition in fstab. > >> > >> Why? > > I don't see how that's an answer to why you would disable zram. > Especially when your later reply shows that you're not really even using > the disk swap anyway. Lots of folks don't realize that zram devices don't use any memory (small amount of overhead based on the size of the zram device, and driver; less than 0.1% of the zram device size), and that it's dynamically allocated. But it's true that swap efficacy as a percentage cannot be 100% like it is with disk or file based swap. That it's so much faster makes up for the lower efficacy. By that I mean, a 4 KiB page being swapped out to disk means you free 4 KiB RAM and consume 4 KiB on disk. With zram based swap, it's still memory, but it's compressed. So you free up 4 KiB uncompressed memory for other things; and you consume ~2 KiB RAM for that compressed page in the zram device. The efficacy is related to the compression ratio you get, which is anywhere 2:1 to 3:1. So it's an efficacy of 50% to 75%. For sure it's better than no swap which has an efficacy of 0% :) In fact that's misleading because when a system can't evict dirty pages at all, it's forced to do file page reclaim, i.e. libraries, executables, configurations that exist as files on disk, can be removed from memory via reclaim, because they're already on disk and can just be read back in. But when under memory pressure, reclaim can look a lot like swap thrashing and even compete with it. So some swap is better, and also due to SSDs, we're probably better off with a higher swappiness value, i.e. give equal weight to page out of anonymous pages as reclaim. But some workloads are different and you can actually get a kind of in-memory swap thrashing same as on disk. It's so fast that it's normally not a problem. Until it is. So we definitely want to keep an eye on reports of folks having issues that sound like hangs or lockups, any time the desktop becomes unresponsive we want to find out what's going on First thing to check in those cases is if the system is running uresourced. It's only enabled by default on GNOME right now. But it's considered safe to run as an opt in for other desktops, though we want to keep an eye on possible regressions. There is still more work to do in this area, in particular wiring up the IO isolation. Any time there's memory pressure it'll quickly lead to IO pressure: reclaim and swap. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
On Mon, Jun 21, 2021 at 10:51 AM Barry Scott wrote: > > The SSDs are a lot slower than compressing a page into RAM. > > There was extensive discussion on the Fedora Devel list when this change was > proposed. > > Personally I was convinced that this change is an improvement for any system > that is under > memory pressure. I'm not going to try to recall the discussion as I may get > some details > wrong. At a high level, zram is a ram disk that has transparent compression. You can format it with mkswap or any other file system, use it as a block device. But nuts and bolts memory management, reclaim, paging in and out, it's quite complicated. There's work happening since kernel 5.8 to make swap a lot more effective. And on going work to make mm and zswap do the right thing. And zswap is a different thing altogether, it's a front cache that uses a compressed memory pool as a cache for a conventional swap file or partition. And it works on an least recently used basis. So it has a way of determining what's stale and pushing that out to disk, while keeping recent things in the (memory) cache. In this case we don't have the concerns with priority inversions that can happen when a particular sequence of events happens: 1. zram based swap has higher priority 2. conventional swap has lower priority 3. early workloads fill up zram with stale things not used again later 4. the general workload ends up using disk based swap So this is not really any worse than before at this point except it is consuming some memory, just to keep stale things available in case they get used. And if they do get used, it'll be quite fast. That's not obviously a bad thing, except it is taking a limited resource off the table. That's atypical for desktop workloads. But you can imagine that the more resources a system has the more variable the workload can be, and you could see early swap fill up a zram device, and then it can't be used again until the programs that created those anonymous pages are quit, in the extreme case. Anyway, how to optimize was the whole point of moving to zram based swap. And it won't stop there. There is still more work happening to get zswap cgroups aware. Neither zram nor zswap are at the moment so for resource control purposes, we actually need a plain swap partition or swap file, it can't even be on dm-crypt at the moment. And one of the nice things about zram based swap is, it's volatile, so we have less security concerns about questionable things ending up on persistent storage that don't even go in a user's ~/home. Anything could be evicted to swap. > I switched it on in F33 and have for over a year seen no down side for my > work loads. > My work loads are file+email server, firewall, KDE desktops, Kodi music > server. > > At my work once we get on to Centos 8 I'm planning to performance test with > zram swap. > We have a work load that is very sensitive to disk I/O spikes and there is > some sad > code that uses swap for 10s to 15s every 20mins of so that I want to make go > away. > We have RAID-10 SSD where we see issues. With centos 8 kernels you'd probably use zram based swap because it's more mature in the older kernels. If you are able to use an elrepo kernel you could try changing nothing else and see if the kernel 5.8+ changes help your workload all by themselves. And if not you could look at either zram based swap or zswap. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
On 2021-06-21 1:05 a.m., Bill Shirley wrote: The server is running on Raid-1 SSDs with 64GB of RAM Bill On 6/21/2021 3:41 AM, Samuel Sieb wrote: On 6/20/21 7:25 PM, Bill Shirley wrote: One of the first things I did after installing F34 is disable swap-on-zram: touch /etc/systemd/zram-generator.conf and define a swap partition in fstab. Why? I don't see how that's an answer to why you would disable zram. Especially when your later reply shows that you're not really even using the disk swap anyway. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, Jun 21, 2021 at 10:58 AM Chris Murphy wrote: > > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 uas_eh_abort_handler > 0 uas-tag 2 inflight: IN > Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 CDB: Mode Sense(6) 1a > 00 08 00 18 00 Yeah and in the install-boot log it happens again: Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: IN Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: tag#16 CDB: Mode Sense(6) 1a 00 08 00 18 00 Jun 20 15:45:20 Bree kernel: scsi host6: uas_eh_device_reset_handler start Jun 20 15:45:20 Bree kernel: usb 4-3: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd Jun 20 15:45:20 Bree kernel: scsi host6: uas_eh_device_reset_handler success Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 20 15:45:20 Bree kernel: sd 6:0:0:1: [sde] Attached SCSI disk What's new here is the explicit USB reset message. Jun 20 15:44:50 Bree kernel: usb 4-3: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd Jun 20 15:44:50 Bree kernel: usb 4-3: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00 Jun 20 15:44:50 Bree kernel: usb 4-3: New USB device strings: Mfr=2, Product=3, SerialNumber=1 Jun 20 15:44:50 Bree kernel: usb 4-3: Product: ASM1156-PM Jun 20 15:44:50 Bree kernel: usb 4-3: Manufacturer: ASMT Jun 20 15:44:50 Bree kernel: usb 4-3: SerialNumber: Curiously there is no usb of a second ASM1156 product, even though there are two: Jun 20 15:44:50 Bree kernel: scsi 6:0:0:0: Direct-Access ASMT ASM1156-PM 0PQ: 0 ANSI: 6 Jun 20 15:44:50 Bree kernel: scsi 6:0:0:1: Direct-Access ASMT ASM1156-PM 0PQ: 0 ANSI: 6 Jun 20 15:44:50 Bree kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 20 15:44:50 Bree kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) And they have their own /dev node. So is one in a USB enclosure and the other isn't? Or maybe they are both just appearing as usb 4-3 even though they get different scsi id's - that's probably it. But then one of them is having some sort of issue, even if it's just confusion that results in the need for the kernel to do a reset on it. but *shrug* this is the joy of USB, it's not necessarily a hardware problem per se. I've got one SATA USB enclosure that tries to use the uas driver if direct connected to an Intel NUC. And I get no end of grief from it (this is with a pre 5.0 kernel I'm sure, it may very well have since been fixed in the kernel). All kinds of uas related errors. Plug it into an externally powered USB hub, and it doens't use the uas driver and I don't have any problems with it, and it reads/writes at approximately the drive's spec'd performance, depending on where on the platter the head is at. As it turns out a USB hub is very much like an ethernet hub. It's not just amplifying a signal, it's reading it, parsing it, and rewriting out that entire stream, as well as any other stream from another connected device. They're a PITA but kind of an engineering marvel (from my perspective anyway). So the hub does in effect seem to normalize the command/control/data streams from myriad devices so they have a better chance of playing well together. It's almost like the idea is "we'll use crap chipsets in the devices and hosts themselves, and just let the hubs figure it all out". And as it turns out with the well behaved SATA USB enclosures, they have transient read and write errors (one a day, then 10 times in a row) if direct connect to that same Intel NUC. With the *externally* powered (not bus powered) hub, zero problems. For years. So if both drives are in SATA USB enclosures, and if they're both connected to ports on a dock, you might track down or borrow an externally powered hub and connect both of the drives to that hub, and the hub to the dock. And see if this problem goes away. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 22/06/2021 02:36, Robert McBroom via users wrote: On 6/21/21 12:37 PM, Ed Greshko wrote: On 22/06/2021 00:35, Ed Greshko wrote: On 21/06/2021 22:47, Robert McBroom via users wrote: Web interface. It shows IPv6 IP Address fe80::200:1eb5:75df:b84:98d1 , 2600:1702:4860:9dd0:21d:60ff:fe35:b813/64 exports configuration is "*" Then the IPv6 address you want to use is 2600:1702:4860:9dd0:21d:60ff:fe35:b813 Oh, I forgot to mention that your IPv6 addresses appear to be Dynamically assigned IP addresses. Meaning they are not "fixed" and may change. Not the best for uses in a client/server environment. Assignment is done by the ISP router. While not fixed they don't change much. Stable through power failure and reboot for the most part. There are basically 2 types of IPv6 IP Dynamic assignment techniques. State-full, and Stateless. Briefly, State-full is DHCPv6. While Stateless is a bit more involved. In Stateless the device needing an IP address receives a Router Announcement which tells it the IP address of the router and subnet information. From there a unique IPv6 address is determined. Given the *huge* IPv6 address space they can both can stay the same for quite some time but that is not guaranteed. Not an ideal situation for client/server. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 6/21/21 12:37 PM, Ed Greshko wrote: On 22/06/2021 00:35, Ed Greshko wrote: On 21/06/2021 22:47, Robert McBroom via users wrote: Web interface. It shows IPv6 IP Address fe80::200:1eb5:75df:b84:98d1 , 2600:1702:4860:9dd0:21d:60ff:fe35:b813/64 exports configuration is "*" Then the IPv6 address you want to use is 2600:1702:4860:9dd0:21d:60ff:fe35:b813 Oh, I forgot to mention that your IPv6 addresses appear to be Dynamically assigned IP addresses. Meaning they are not "fixed" and may change. Not the best for uses in a client/server environment. Assignment is done by the ISP router. While not fixed they don't change much. Stable through power failure and reboot for the most part. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 6/21/21 3:14 AM, Patrick O'Callaghan wrote: Yes, that's been established (strictly, I haven't bothered swapping the drives in the dock to see what happens, but it's immaterial). Again, the issue is not that one drive takes time to spin up, but that the system start-up waits for it when it doesn't need to. Even so, if it's always the same drive, there might be something wrong with it and if so, simply replacing that drive might be the simplest solution. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 6/21/21 8:17 AM, Robert McBroom via users wrote: Trying to connect to NAS with nfs using the ipv6 addressing. @RobertPC ~]#ping fd2e:cb3b:f005::ec1 PING fd2e:cb3b:f005::ec1(fd2e:cb3b:f005::ec1) 56 data bytes 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=1 ttl=64 time=0.120 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=2 ttl=64 time=0.100 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=3 ttl=64 time=0.117 ms @RobertPC ~]#mount -v -t nfs fd2e:cb3b:f005::ec1:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:41:56 2021 mount.nfs: Failed to resolve server fd2e: Name or service not known Try putting the IPv6 address inside square brackets. mount [fd2e:cb3b:f005::ec1]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy -- In Soviet Russia, Google searches you! ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
> On 21 Jun 2021, at 17:48, Tom Horsley wrote: > > On Tue, 22 Jun 2021 00:37:56 +0800 > Ed Greshko wrote: > >> Oh, I forgot to mention that your IPv6 addresses appear to be Dynamically >> assigned IP >> addresses. Meaning they are not "fixed" and may change. Not the best for >> uses in a >> client/server environment. > > Isn't there some sort of automagic ipv6 name resolution? I've avoided > ever learning anything about ipv6, but I swear I saw something about that > in some overview once. Just as with ipv4 you want a fixed address for servers and its the same with ipv6. You clearly want DNS to provide a name for the server to avoid using the long address. But you do not want that address to change after you have done the look up! Barry > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, Jun 21, 2021 at 3:20 AM Patrick O'Callaghan wrote: > > The logs are now publicly visible at: > https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing From the live boot (the least complicated one to look at for starters), there is an anomaly: Jun 19 08:46:41 fedora kernel: BTRFS: device label fedora_localhost-live devid 1 transid 1768306 /dev/sda3 scanned by systemd-udevd (602) Jun 19 08:46:41 fedora kernel: BTRFS: device label storage devid 1 transid 3481192 /dev/sdc1 scanned by systemd-udevd (595) Jun 19 08:46:44 fedora kernel: BTRFS: device label RAID devid 1 transid 1973 /dev/sdd scanned by systemd-udevd (595) Jun 19 08:46:56 fedora systemd[1]: Mounted /sysroot. Jun 19 12:47:14 fedora kernel: BTRFS: device label RAID devid 2 transid 1973 /dev/sde scanned by systemd-udevd (1000) rewinding to see why this device is so much later (ignoring 8 vs 12 which is some clock artifact and not real), even though it's not holding up live boot: Jun 19 08:46:41 fedora kernel: scsi host6: uas Jun 19 08:46:41 fedora kernel: usbcore: registered new interface driver uas Jun 19 08:46:41 fedora kernel: scsi 6:0:0:0: Direct-Access ASMT ASM1156-PM 0PQ: 0 ANSI: 6 Jun 19 08:46:41 fedora kernel: scsi 6:0:0:1: Direct-Access ASMT ASM1156-PM 0PQ: 0 ANSI: 6 Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: Attached scsi generic sg4 type 0 Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: Attached scsi generic sg5 type 0 Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] 4096-byte physical blocks Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Write Protect is off Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Mode Sense: 43 00 00 00 Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB) Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] 4096-byte physical blocks Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] Write Protect is off Jun 19 08:46:41 fedora kernel: sd 6:0:0:1: [sde] Mode Sense: 43 00 00 00 Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 19 08:46:41 fedora kernel: sd 6:0:0:0: [sdd] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 19 08:46:44 fedora kernel: sd 6:0:0:0: [sdd] Attached SCSI disk Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 uas_eh_abort_handler 0 uas-tag 2 inflight: IN Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 CDB: Mode Sense(6) 1a 00 08 00 18 00 Jun 19 12:47:12 fedora kernel: scsi host6: uas_eh_device_reset_handler start Jun 19 12:47:12 fedora kernel: usb 4-3: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd Jun 19 12:47:12 fedora kernel: scsi host6: uas_eh_device_reset_handler success Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: [sde] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) Jun 19 12:47:14 fedora kernel: sd 6:0:0:1: [sde] Attached SCSI disk Jun 19 12:47:14 fedora kernel: BTRFS: device label RAID devid 2 transid 1973 /dev/sde scanned by systemd-udevd (1000) Both sd 6:0:0:0: (/dev/sdd) and sd 6:0:0:1: (/dev/sde) are found at the same time, but there's a uas related reset that happens only on /dev/sde. I don't know what this means: Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 uas_eh_abort_handler 0 uas-tag 2 inflight: IN Jun 19 12:47:12 fedora kernel: sd 6:0:0:1: tag#2 CDB: Mode Sense(6) 1a 00 08 00 18 00 But that's the clue that there's some kind of communication issue between drive and kernel. If these are both in SATA USB enclosures I'd ask on the linux-usb list what these messages mean and why the file system on the one with these messages isn't recognized by the kernel until later. You could switch cables only around and see if the problem follows the cables; then switch the drives to see if it follows the drives. I would sooner expect the drive enclosure than cable but since I've got no clue what the above two messages mean, it's just an iterative process. I do recommend using lsusb -v in the initial email to linux-usb, maybe compare the two enclosure outputs to see if there's anything different. The make/model might be identical but it's possible a partial explanation lies with a chipset difference, or revision of the chipset. There's a bunch of usb and uas driver quirks that can be applied to work around problems like this. By reporting them, if there's enough differentiation reported by the enclosures to use a quirk, they'll apply it by default in a future kernel. If not, then it becomes something you apply every boot. -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to
Re: packagekitd Hogging CPU
> On 21 Jun 2021, at 14:18, Tim Evans wrote: > > $ uname -a > Linux harrier 5.12.11-300.fc34.x86_64 #1 SMP Wed Jun 16 15:47:58 UTC 2021 > x86_64 x86_64 x86_64 GNU/Linux > > As I sit here, my Lenovo T530 laptop is reporting packagekitd is taking > anywhere from 20 to 40 percent of CPU, per 'top.' There is continuous disk > activity. Nothing going on with the system other than Thunderbird e-mail and > Chrome browser. > > This seems to go on, with CPU percentage growing over time, and it rebooting > cures this, but it comes back after the system has slept overnight (lid > closed). > > packagekit is gnome-packagekit-common-3.32.0-7.fc34.x86_64 What files is packagekitd accessing? I'd use lsof to look for what its doing. lsof -p Also if you do ps -afx are there any subprocesses of packagekitd? What are they doing? Barry > -- > Tim Evans |5 Chestnut Court > 443-394-3864 |Owings Mills, MD 21117 > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
The SSDs are a lot slower than compressing a page into RAM. There was extensive discussion on the Fedora Devel list when this change was proposed. Personally I was convinced that this change is an improvement for any system that is under memory pressure. I'm not going to try to recall the discussion as I may get some details wrong. I switched it on in F33 and have for over a year seen no down side for my work loads. My work loads are file+email server, firewall, KDE desktops, Kodi music server. At my work once we get on to Centos 8 I'm planning to performance test with zram swap. We have a work load that is very sensitive to disk I/O spikes and there is some sad code that uses swap for 10s to 15s every 20mins of so that I want to make go away. We have RAID-10 SSD where we see issues. Barry > On 21 Jun 2021, at 09:05, Bill Shirley wrote: > > The server is running on Raid-1 SSDs with 64GB of RAM > > Bill > > On 6/21/2021 3:41 AM, Samuel Sieb wrote: >> On 6/20/21 7:25 PM, Bill Shirley wrote: >>> One of the first things I did after installing F34 is disable swap-on-zram: >>>touch /etc/systemd/zram-generator.conf >>> and define a swap partition in fstab. >> >> Why? >> ___ >> users mailing list -- users@lists.fedoraproject.org >> To unsubscribe send an email to users-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On Tue, 22 Jun 2021 00:37:56 +0800 Ed Greshko wrote: > Oh, I forgot to mention that your IPv6 addresses appear to be Dynamically > assigned IP > addresses. Meaning they are not "fixed" and may change. Not the best for > uses in a > client/server environment. Isn't there some sort of automagic ipv6 name resolution? I've avoided ever learning anything about ipv6, but I swear I saw something about that in some overview once. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 22/06/2021 00:35, Ed Greshko wrote: On 21/06/2021 22:47, Robert McBroom via users wrote: Web interface. It shows IPv6 IP Address fe80::200:1eb5:75df:b84:98d1 , 2600:1702:4860:9dd0:21d:60ff:fe35:b813/64 exports configuration is "*" Then the IPv6 address you want to use is 2600:1702:4860:9dd0:21d:60ff:fe35:b813 Oh, I forgot to mention that your IPv6 addresses appear to be Dynamically assigned IP addresses. Meaning they are not "fixed" and may change. Not the best for uses in a client/server environment. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 21/06/2021 22:47, Robert McBroom via users wrote: Web interface. It shows IPv6 IP Address fe80::200:1eb5:75df:b84:98d1 , 2600:1702:4860:9dd0:21d:60ff:fe35:b813/64 exports configuration is "*" Then the IPv6 address you want to use is 2600:1702:4860:9dd0:21d:60ff:fe35:b813 -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 6/21/21 10:16 AM, Ed Greshko wrote: On 21/06/2021 22:06, Robert McBroom via users wrote: On 6/21/21 9:49 AM, Ed Greshko wrote: On 21/06/2021 21:17, Robert McBroom via users wrote: Trying to connect to NAS with nfs using the ipv6 addressing. @RobertPC ~]#ping fd2e:cb3b:f005::ec1 PING fd2e:cb3b:f005::ec1(fd2e:cb3b:f005::ec1) 56 data bytes 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=1 ttl=64 time=0.120 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=2 ttl=64 time=0.100 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=3 ttl=64 time=0.117 ms @RobertPC ~]#mount -v -t nfs fd2e:cb3b:f005::ec1:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:41:56 2021 mount.nfs: Failed to resolve server fd2e: Name or service not known mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: Connection refused @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1%enp2s0]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 09:18:19 2021 mount.nfs: Failed to resolve server fd2e:cb3b:f005::ec1%enp2s0: Name or service not known The ipv4 connection works What is needed to get the ipv6 connection? You really should be using the "actual" ip6 address and not the link address. The router shows multiple ipv6 addresses for the device. How to distinguish which one is actual? IPv6 Address 2600:1702:4860:9dd0:c210:8c59:6c38:52fd Type slaac Valid Lifetime 3600s Preferred Lifetime 3600s IPv6 Address 2600:1702:4860:9dd0:21d:60ff:fe35:b813 Type slaac Valid Lifetime 3600s Preferred Lifetime 3600s IPv6 Address fd2e:cb3b:f005::ec1 Type slaac Valid Lifetime forever Preferred Lifetime forever IPv6 Address fe80::1eb5:75df:b84:98d1 Type slaac Valid Lifetime forever Preferred Lifetime forever -- Can you not login to 192.168.1.239 and run the "ip add show" command to see what the address is? Web interface. It shows IPv6 IP Address fe80::200:1eb5:75df:b84:98d1 , 2600:1702:4860:9dd0:21d:60ff:fe35:b813/64 exports configuration is "*" ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 21/06/2021 22:06, Robert McBroom via users wrote: On 6/21/21 9:49 AM, Ed Greshko wrote: On 21/06/2021 21:17, Robert McBroom via users wrote: Trying to connect to NAS with nfs using the ipv6 addressing. @RobertPC ~]#ping fd2e:cb3b:f005::ec1 PING fd2e:cb3b:f005::ec1(fd2e:cb3b:f005::ec1) 56 data bytes 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=1 ttl=64 time=0.120 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=2 ttl=64 time=0.100 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=3 ttl=64 time=0.117 ms @RobertPC ~]#mount -v -t nfs fd2e:cb3b:f005::ec1:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:41:56 2021 mount.nfs: Failed to resolve server fd2e: Name or service not known mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: Connection refused @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1%enp2s0]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 09:18:19 2021 mount.nfs: Failed to resolve server fd2e:cb3b:f005::ec1%enp2s0: Name or service not known The ipv4 connection works What is needed to get the ipv6 connection? You really should be using the "actual" ip6 address and not the link address. The router shows multiple ipv6 addresses for the device. How to distinguish which one is actual? IPv6 Address2600:1702:4860:9dd0:c210:8c59:6c38:52fd Typeslaac Valid Lifetime 3600s Preferred Lifetime 3600s IPv6 Address2600:1702:4860:9dd0:21d:60ff:fe35:b813 Typeslaac Valid Lifetime 3600s Preferred Lifetime 3600s IPv6 Addressfd2e:cb3b:f005::ec1 Typeslaac Valid Lifetime forever Preferred Lifetime forever IPv6 Addressfe80::1eb5:75df:b84:98d1 Typeslaac Valid Lifetime forever Preferred Lifetime forever -- Can you not login to 192.168.1.239 and run the "ip add show" command to see what the address is? -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 6/21/21 9:49 AM, Ed Greshko wrote: On 21/06/2021 21:17, Robert McBroom via users wrote: Trying to connect to NAS with nfs using the ipv6 addressing. @RobertPC ~]#ping fd2e:cb3b:f005::ec1 PING fd2e:cb3b:f005::ec1(fd2e:cb3b:f005::ec1) 56 data bytes 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=1 ttl=64 time=0.120 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=2 ttl=64 time=0.100 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=3 ttl=64 time=0.117 ms @RobertPC ~]#mount -v -t nfs fd2e:cb3b:f005::ec1:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:41:56 2021 mount.nfs: Failed to resolve server fd2e: Name or service not known mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: Connection refused @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1%enp2s0]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 09:18:19 2021 mount.nfs: Failed to resolve server fd2e:cb3b:f005::ec1%enp2s0: Name or service not known The ipv4 connection works What is needed to get the ipv6 connection? You really should be using the "actual" ip6 address and not the link address. The router shows multiple ipv6 addresses for the device. How to distinguish which one is actual? IPv6 Address2600:1702:4860:9dd0:c210:8c59:6c38:52fd Typeslaac Valid Lifetime 3600s Preferred Lifetime 3600s IPv6 Address2600:1702:4860:9dd0:21d:60ff:fe35:b813 Typeslaac Valid Lifetime 3600s Preferred Lifetime 3600s IPv6 Addressfd2e:cb3b:f005::ec1 Typeslaac Valid Lifetime forever Preferred Lifetime forever IPv6 Addressfe80::1eb5:75df:b84:98d1 Typeslaac Valid Lifetime forever Preferred Lifetime forever ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 21/06/2021 21:17, Robert McBroom via users wrote: What is needed to get the ipv6 connection? Oh, and of course, you'll need the appropriate entry in the server's exports file. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Learning ipv6 quirks
On 21/06/2021 21:17, Robert McBroom via users wrote: Trying to connect to NAS with nfs using the ipv6 addressing. @RobertPC ~]#ping fd2e:cb3b:f005::ec1 PING fd2e:cb3b:f005::ec1(fd2e:cb3b:f005::ec1) 56 data bytes 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=1 ttl=64 time=0.120 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=2 ttl=64 time=0.100 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=3 ttl=64 time=0.117 ms @RobertPC ~]#mount -v -t nfs fd2e:cb3b:f005::ec1:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:41:56 2021 mount.nfs: Failed to resolve server fd2e: Name or service not known mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: Connection refused @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1%enp2s0]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 09:18:19 2021 mount.nfs: Failed to resolve server fd2e:cb3b:f005::ec1%enp2s0: Name or service not known The ipv4 connection works What is needed to get the ipv6 connection? You really should be using the "actual" ip6 address and not the link address. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 21/06/2021 20:31, Patrick O'Callaghan wrote: On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote: On 21/06/2021 19:48, Patrick O'Callaghan wrote: To avoid ambiguity, maybe you should tell me the journal options you´d like (the timestamps in the uploaded logs don´t show wallclock time). The journal times of what you've supplied seem fine. They show Jun 20 15:44:50 for example and dmesg -T would show [Sun Jun 20 18:35:35 2021] So, they are easy to match up. I've replaced the dmesg file with the output of 'dmesg -T'. I thought I mentioned they should have been taken at the same time. journal starts at Jun 20 15:44:50 dmesg Sun Jun 20 22:38:39 2021 Kinda hard to match things that way. :-) -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
packagekitd Hogging CPU
$ uname -a Linux harrier 5.12.11-300.fc34.x86_64 #1 SMP Wed Jun 16 15:47:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux As I sit here, my Lenovo T530 laptop is reporting packagekitd is taking anywhere from 20 to 40 percent of CPU, per 'top.' There is continuous disk activity. Nothing going on with the system other than Thunderbird e-mail and Chrome browser. This seems to go on, with CPU percentage growing over time, and it rebooting cures this, but it comes back after the system has slept overnight (lid closed). packagekit is gnome-packagekit-common-3.32.0-7.fc34.x86_64 -- Tim Evans |5 Chestnut Court 443-394-3864|Owings Mills, MD 21117 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Learning ipv6 quirks
Trying to connect to NAS with nfs using the ipv6 addressing. @RobertPC ~]#ping fd2e:cb3b:f005::ec1 PING fd2e:cb3b:f005::ec1(fd2e:cb3b:f005::ec1) 56 data bytes 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=1 ttl=64 time=0.120 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=2 ttl=64 time=0.100 ms 64 bytes from fd2e:cb3b:f005::ec1: icmp_seq=3 ttl=64 time=0.117 ms @RobertPC ~]#mount -v -t nfs fd2e:cb3b:f005::ec1:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:41:56 2021 mount.nfs: Failed to resolve server fd2e: Name or service not known @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:42:25 2021 mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'addr=fd2e:cb3b:f005::ec1' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: portmap query retrying: RPC: Program not registered mount.nfs: prog 13, trying vers=3, prot=17 mount.nfs: portmap query failed: RPC: Program not registered mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'addr=fd2e:cb3b:f005::ec1' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: portmap query retrying: RPC: Program not registered mount.nfs: prog 13, trying vers=3, prot=17 mount.nfs: portmap query failed: RPC: Program not registered mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'addr=fd2e:cb3b:f005::ec1' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: portmap query retrying: RPC: Program not registered mount.nfs: prog 13, trying vers=3, prot=17 mount.nfs: portmap query failed: RPC: Program not registered mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'addr=fd2e:cb3b:f005::ec1' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: portmap query retrying: RPC: Program not registered mount.nfs: prog 13, trying vers=3, prot=17 mount.nfs: portmap query failed: RPC: Program not registered mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'addr=fd2e:cb3b:f005::ec1' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: portmap query retrying: RPC: Program not registered mount.nfs: prog 13, trying vers=3, prot=17 mount.nfs: portmap query failed: RPC: Program not registered mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'addr=fd2e:cb3b:f005::ec1' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: portmap query retrying: RPC: Program not registered mount.nfs: prog 13, trying vers=3, prot=17 mount.nfs: portmap query failed: RPC: Program not registered mount.nfs: trying text-based options 'vers=4.2,addr=fd2e:cb3b:f005::ec1,clientaddr=fd2e:cb3b:f005::ec1' mount.nfs: mount(2): Connection refused mount.nfs: trying text-based options 'addr=fd2e:cb3b:f005::ec1' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: portmap query retrying: RPC: Program not registered mount.nfs: prog 13, trying vers=3, prot=17 mount.nfs: portmap query failed: RPC: Program not registered mount.nfs: Connection refused @RobertPC ~]# mount -v -t nfs [fd2e:cb3b:f005::ec1%enp2s0]:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 09:18:19 2021 mount.nfs: Failed to resolve server fd2e:cb3b:f005::ec1%enp2s0: Name or service not known The ipv4 connection works @RobertPC ~]# mount -v -t nfs 192.168.1.239:/mnt/HD/HD_a2/mcstuffy /mnt/mcstuffy mount.nfs: timeout set for Mon Jun 21 06:43:30 2021 mount.nfs: trying text-based options 'vers=4.2,addr=192.168.1.239,clientaddr=192.168.1.185' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,minorversion=1,addr=192.168.1.239,clientaddr=192.168.1.185' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'vers=4,addr=192.168.1.239,clientaddr=192.168.1.185' mount.nfs: mount(2): Protocol not supported mount.nfs: trying text-based options 'addr=192.168.1.239' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 192.168.1.239 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 192.168.1.239 prog 15 vers 3 prot UDP port 49748 What is needed to get the ipv6 connection? ___ users mailing list --
Re: Long wait for start job
On Mon, 2021-06-21 at 20:02 +0800, Ed Greshko wrote: > On 21/06/2021 19:48, Patrick O'Callaghan wrote: > > To avoid ambiguity, maybe you should tell me the journal options > > you´d > > like (the timestamps in the uploaded logs don´t show wallclock > > time). > > The journal times of what you've supplied seem fine. They show > > Jun 20 15:44:50 for example > > and dmesg -T would show > > [Sun Jun 20 18:35:35 2021] > > So, they are easy to match up. I've replaced the dmesg file with the output of 'dmesg -T'. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 21/06/2021 18:17, Patrick O'Callaghan wrote: I thought the contents of dmesg were already in the journal, but I may have misunderstood their relationship. I asked for dmesg since there is a gap in dmesg but not a corresponding gap in the journal. [ 30.093669] logitech-hidpp-device 0003:046D:400A.0005: HID++ 2.0 device connected. [ 30.389335] rfkill: input handler enabled [ 299.942841] usb 4-3: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd [ 299.955717] usb 4-3: New USB device found, idVendor=174c, idProduct=55aa, bcdDevice= 1.00 But I don't know what real time that happened, thus the -T. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 21/06/2021 19:48, Patrick O'Callaghan wrote: To avoid ambiguity, maybe you should tell me the journal options you´d like (the timestamps in the uploaded logs don´t show wallclock time). The journal times of what you've supplied seem fine. They show Jun 20 15:44:50 for example and dmesg -T would show [Sun Jun 20 18:35:35 2021] So, they are easy to match up. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, 2021-06-21 at 18:57 +0800, Ed Greshko wrote: > On 21/06/2021 18:27, Ed Greshko wrote: > > On 21/06/2021 18:17, Patrick O'Callaghan wrote: > > > On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote: > > > > On 21/06/2021 17:20, Patrick O'Callaghan wrote: > > > > > The logs are now publicly visible at: > > > > > https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing > > > > > > > > > > I've included my home-grown 'dock' scripts for completeness, > > > > > plus > > > > > logs > > > > > of a Fedora Live boot (with no delay) and my current > > > > > installed > > > > > system > > > > > (with the delay), both with unchanged hardware. > > > > How about supplying the dmesg output? > > > > > > > > Wondering if the BTRFS raid is detected at that early stage. > > > Uploaded to the installed-boot folder. > > > > > > I thought the contents of dmesg were already in the journal, but > > > I may > > > have misunderstood their relationship. > > > > Oh, I forgot to add, could you use "dmesg -T"? :-) > > > > I just realized I may have been a bit ambiguous. > > I would like the journal and dmesg -T output at the same time so > date/time are the > same. To avoid ambiguity, maybe you should tell me the journal options you´d like (the timestamps in the uploaded logs don´t show wallclock time). poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 21/06/2021 18:27, Ed Greshko wrote: On 21/06/2021 18:17, Patrick O'Callaghan wrote: On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote: On 21/06/2021 17:20, Patrick O'Callaghan wrote: The logs are now publicly visible at: https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing I've included my home-grown 'dock' scripts for completeness, plus logs of a Fedora Live boot (with no delay) and my current installed system (with the delay), both with unchanged hardware. How about supplying the dmesg output? Wondering if the BTRFS raid is detected at that early stage. Uploaded to the installed-boot folder. I thought the contents of dmesg were already in the journal, but I may have misunderstood their relationship. Oh, I forgot to add, could you use "dmesg -T"? :-) I just realized I may have been a bit ambiguous. I would like the journal and dmesg -T output at the same time so date/time are the same. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 21/06/2021 18:17, Patrick O'Callaghan wrote: On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote: On 21/06/2021 17:20, Patrick O'Callaghan wrote: The logs are now publicly visible at: https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing I've included my home-grown 'dock' scripts for completeness, plus logs of a Fedora Live boot (with no delay) and my current installed system (with the delay), both with unchanged hardware. How about supplying the dmesg output? Wondering if the BTRFS raid is detected at that early stage. Uploaded to the installed-boot folder. I thought the contents of dmesg were already in the journal, but I may have misunderstood their relationship. Oh, I forgot to add, could you use "dmesg -T"? :-) -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, 2021-06-21 at 17:43 +0800, Ed Greshko wrote: > On 21/06/2021 17:20, Patrick O'Callaghan wrote: > > The logs are now publicly visible at: > > https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing > > > > I've included my home-grown 'dock' scripts for completeness, plus > > logs > > of a Fedora Live boot (with no delay) and my current installed > > system > > (with the delay), both with unchanged hardware. > > How about supplying the dmesg output? > > Wondering if the BTRFS raid is detected at that early stage. Uploaded to the installed-boot folder. I thought the contents of dmesg were already in the journal, but I may have misunderstood their relationship. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
[0 07:20:34 root@yoda33 ~]$ swapon NAME TYPE SIZE USED PRIO /dev/sdc1 partition 64G 9.7M 300 /dev/sdd1 partition 64G 9.4M 300 [0 03:06:33 root@yoda33 ~]$ uptime 03:08:30 up 23 days, 18:33, 2 users, load average: 0.01, 0.01, 0.00 On 6/21/2021 4:18 AM, Ed Greshko wrote: On 21/06/2021 16:05, Bill Shirley wrote: The server is running on Raid-1 SSDs with 64GB of RAM I suppose the follow-up question would be are you seeing the swap partition actually being used? Does "swapon" show it has been used? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On 21/06/2021 17:20, Patrick O'Callaghan wrote: The logs are now publicly visible at: https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing I've included my home-grown 'dock' scripts for completeness, plus logs of a Fedora Live boot (with no delay) and my current installed system (with the delay), both with unchanged hardware. How about supplying the dmesg output? Wondering if the BTRFS raid is detected at that early stage. -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, 2021-06-21 at 06:19 +0800, Ed Greshko wrote: > On 21/06/2021 06:02, Ed Greshko wrote: > > On 21/06/2021 05:48, Patrick O'Callaghan wrote: > > > $ systemd-analyze blame |grep dracut-initqueue.service > > > 486ms dracut-initqueue.service > > > > > > If I power on the dock on after startup is complete, one drive > > > appears > > > immediately and the other takes 30 seconds or so, so the delay is > > > not > > > being caused by the boot process itself. It must be the hardware > > > (the > > > drive or the dock) taking that long for whatever reason, possibly > > > power > > > management as George suggested. As I've said, my goal is to > > > convince > > > the kernel that it doesn't need to wait for this so as to > > > continue with > > > the startup. > > > > Right. I just wanted to confirm that, it would appear, the 30sec > > is in that service/area. > > > > So far I've not found a configuration file/setting which would tell > > it "don't look here...". > > > > > > This may be a bit of work, but *may* help define/narrow the issue. > > https://fedoraproject.org/wiki/How_to_debug_Dracut_problems Hmm. I see there's a way to breakpoint the boot process e.g. at the pre-udev stage, but I'm not sure what I can achieve by doing that. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Sun, 2021-06-20 at 18:00 -0600, Chris Murphy wrote: > On Sun, Jun 20, 2021 at 3:48 PM Patrick O'Callaghan > wrote: > > > > If I power on the dock on after startup is complete, one drive > > appears > > immediately and the other takes 30 seconds or so, so the delay is not > > being caused by the boot process itself. It must be the hardware (the > > drive or the dock) taking that long for whatever reason, possibly > > power > > management as George suggested. As I've said, my goal is to convince > > the kernel that it doesn't need to wait for this so as to continue > > with > > the startup. > > > > dmesg will show this whole sequence: dock appearing, bus appearing, > drive on bus appearing, partition map appearing. I couldn't open the > previous journal log provided, it wasn't publicly visible or I'd have > taken a gander. The logs are now publicly visible at: https://drive.google.com/drive/folders/1nGwVkeTJh5hz4dYRBD7Ikpx6q4MaPki9?usp=sharing I've included my home-grown 'dock' scripts for completeness, plus logs of a Fedora Live boot (with no delay) and my current installed system (with the delay), both with unchanged hardware. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Sun, 2021-06-20 at 17:40 -0600, Joe Zeff wrote: > On 6/20/21 3:48 PM, Patrick O'Callaghan wrote: > > If I power on the dock on after startup is complete, one drive > > appears > > immediately and the other takes 30 seconds or so, so the delay is > > not > > being caused by the boot process itself. It must be the hardware > > (the > > drive or the dock) taking that long for whatever reason, possibly > > power > > management as George suggested. > > Is it always the same drive taking so long? If so, that's the > culprit. Yes, that's been established (strictly, I haven't bothered swapping the drives in the dock to see what happens, but it's immaterial). Again, the issue is not that one drive takes time to spin up, but that the system start-up waits for it when it doesn't need to. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Long wait for start job
On Mon, 2021-06-21 at 06:59 +0800, Ed Greshko wrote: > On 21/06/2021 06:02, Ed Greshko wrote: > > On 21/06/2021 05:48, Patrick O'Callaghan wrote: > > > $ systemd-analyze blame |grep dracut-initqueue.service > > > 486ms dracut-initqueue.service > > > > > > If I power on the dock on after startup is complete, one drive > > > appears > > > immediately and the other takes 30 seconds or so, so the delay is > > > not > > > being caused by the boot process itself. It must be the hardware > > > (the > > > drive or the dock) taking that long for whatever reason, possibly > > > power > > > management as George suggested. As I've said, my goal is to > > > convince > > > the kernel that it doesn't need to wait for this so as to > > > continue with > > > the startup. > > > > Right. I just wanted to confirm that, it would appear, the 30sec > > is in that service/area. > > > > So far I've not found a configuration file/setting which would tell > > it "don't look here...". > > > > > > You're running software raid on the dock drives, right? Is that the > only place you're > using raid? I'm only using BTRFS raid. > Does you system have a /etc/mdadm.conf? No. I did have one under F33, but since doing a clean install of F34 that's no longer the case. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
On 21/06/2021 16:05, Bill Shirley wrote: The server is running on Raid-1 SSDs with 64GB of RAM I suppose the follow-up question would be are you seeing the swap partition actually being used? Does "swapon" show it has been used? -- Remind me to ignore comments which aren't germane to the thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
The server is running on Raid-1 SSDs with 64GB of RAM Bill On 6/21/2021 3:41 AM, Samuel Sieb wrote: On 6/20/21 7:25 PM, Bill Shirley wrote: One of the first things I did after installing F34 is disable swap-on-zram: touch /etc/systemd/zram-generator.conf and define a swap partition in fstab. Why? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: No Swap Allocation in FSTAB
On 6/20/21 7:25 PM, Bill Shirley wrote: One of the first things I did after installing F34 is disable swap-on-zram: touch /etc/systemd/zram-generator.conf and define a swap partition in fstab. Why? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
