Re: realpath quoting
In days of yore (Fri, 03 May 2024), jeremy ardley thus quoth: > > On 3/5/24 19:06, Greg Wooledge wrote: > > I would suggest that if you need to use a debugger to track down a bug > > in your program, you should use filenames that don't require quoting > > when you set up your tests. > > 1970's style static test cases are not relevant here. > > In the real world... I download files generated by another system that > are constantly changing content and with names I don't control. > > My workflow is to download a new file from a remote source and then run my > processor over it. > > As a necessary consequence I need the fully quoted or escaped file name of > the new file to feed to the processor/debugger. > > I can obviously add an extra step to the process to convert the new file > name to something acceptable before processing. However, my question was > how to avoid that extra step by getting fully quoted filenames to process. Encase the file-name in single or double quotes. If it contains any kind of construct that could be expanded by the shell, single quotes. Consider this example: $ file=abc $ echo "$file" $ echo '$file' If you copy-paste anywhere, slap single quotes around it by habit and you will not get taken by surprise by spaces or anything the shell decide looks like something it can evaluate or expand. -- Kind regards, /S
Re: Installing testing on Acer Aspire 315
In days of yore (Thu, 02 May 2024), Paul Scott thus quoth: > > On 5/1/2024 10:44 AM, Nicolas George wrote: > > Paul Scott (12024-05-01): > > > I read that I should try a more complete image which I am downloading > > > (jigdo) now. > > Waste of time. The drivers are either in the kernel image or in > > individual packages, you can install them on top of what you have. > > > > > I would appreciate any thoughts or suggestions, > > Check the PCI ids of your Ethernet controller. Download the kernel image > > you are considering, check if any of its modules matches these ids. n > > I may need to do that. Thank you, > > In the mean time, an install seemed to be working but gave an failure > error which said it would be in the log and visible on virtual terminal 4, > I didn't know how to get to a virtual in the installer. Various > combinations with F4 didn't seem to work. > > Google didn't seem to help. Can someone tell me how to get to a virtual > terminal in the installer? Control-Alt-F4 should get you to vc4. It might be enough with Alt-F4 if it is text-mode installation, but if you are doing a GUI install (Wayland or X running) you need the Control-Alt combo. -- Kind regards, /S
Re: Zutty fonts - zutty always uses the same font and fontsize
In days of yore (Thu, 02 May 2024), Sirius thus quoth: > Tab-handling is one of the things that kitty does well that I > really like. But when it takes over ten times the memory for a single > instance compared to urxvt - I can forego the tab-handling and have > multiple windows instead. (Not looked yet if there is urxvt patches for > kitty style tab handling - which would be awesome if it exists.) To follow up on this: https://github.com/gryf/tabbedalt $ mkdir -p ~/.urxvt/ext/ $ wget -O ~/.urxvt/ext/tabbedalt https://raw.githubusercontent.com/gryf/tabbedalt/master/tabbedalt $ echo "URxvt.perl-ext: tabbedalt" >> .Xdefaults Now you have tabs in urxvt. -- Kind regards, /S
Re: Installing testing on Acer Aspire 315
In days of yore (Wed, 01 May 2024), Paul Scott thus quoth: > > On 5/1/2024 10:57 AM, Sirius wrote: > > I have an Aspire A715-41G and the wireless is an Intel AX200. I am > > currently using iwd and iwctl to manage it, but NetworkManager picked it > > up off the bat and allowed it to be configured - even during installation. > > > > You will want to use 'lspci' to figure out if the card is seen at all and > > you should get a line like: > > > > 04:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) > > > > Once you know what make/model the wifi is, you can start looking for the > > right driver if it is not auto-detected. > > How did you install Debian? I have a USB stick with Ventoy on it, and a collection of ISOs that I can pick through depending on what I am doing. The Debian ISO is the 12.5 DVD version. It was surprising to me just how much the installer detected and got right, because it asked me about wifi network and key and then off it went. If your wifi is also the AX200 (maybe a different revision), it *should* work. There is a lot to be said about Intel, but their drivers do get pushed upstream and make it into the distribution kernels. iwd is also an Intel thing and quite nice to use when digging into it. -- Kind regards, /S
Re: Zutty fonts - zutty always uses the same font and fontsize
In days of yore (Wed, 01 May 2024), Karl Vogel thus quoth:
> On Wed, May 01, 2024 at 08:32:31AM -0400, Sirius wrote:
> > If Debian still packages it, look for rxvt instead, or use xterm. Both
> > are well tried and well tested for when you want something.. dated. ;)
>
> I resemble that remark. Xterm v390 was released on 19 Feb 2024, and
> building it from source is easy.
>
> https://invisible-island.net/archives/xterm/xterm-390.tgz{,.asc}
It was meant tongue-in-cheek. OP's post prompted me to start digging into
urxvt and it is now my default terminal. :)
Modern terminals like Gnome-terminal, Konsole, alacritty, kitty and others
are essentially slapping a spruced-up UI on top of something that is 40+
years old. Tab-handling is one of the things that kitty does well that I
really like. But when it takes over ten times the memory for a single
instance compared to urxvt - I can forego the tab-handling and have
multiple windows instead. (Not looked yet if there is urxvt patches for
kitty style tab handling - which would be awesome if it exists.)
And as someone pointed out about the control character handling, there is
a security aspect to pay attention to as well. Xterm and Rxvt have both
been down this road for so long that they have that side of things
relatively well handled.
I've seen zutty because it was installed by default, but I have no idea
why it is installed by default. It does not strike me as the best choice
when both xterm and rxvt are available.
> My mind is like my browser: 19 open tabs, three of them are frozen, and
> I have no clue where the music is coming from.
Oh, I s identify with this one.
--
Kind regards,
/S
Re: Installing testing on Acer Aspire 315
In days of yore (Wed, 01 May 2024), Paul Scott thus quoth: > Hello, > > I have many installs over many years (only a few per year).. > > I tried a Testing net install pn my new Acer Aspire 315 and it didn't find > an Ethernet driver. (wireless?). > > I read that I should try a more complete image which I am downloading > (jigdo) now. > > I would appreciate any thoughts or suggestions, I have an Aspire A715-41G and the wireless is an Intel AX200. I am currently using iwd and iwctl to manage it, but NetworkManager picked it up off the bat and allowed it to be configured - even during installation. You will want to use 'lspci' to figure out if the card is seen at all and you should get a line like: 04:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) Once you know what make/model the wifi is, you can start looking for the right driver if it is not auto-detected. -- Kind regards, /S
Re: Zutty fonts - zutty always uses the same font and fontsize
In days of yore (Wed, 01 May 2024), Greg Wooledge thus quoth: > On Wed, May 01, 2024 at 02:31:49PM +0200, Sirius wrote: > > zutty is kind of only necessary when you want something *really* > > lightweight and you do not need to worry about UTF-8. Just writing this > > means a trip down memory lane and back to configuring CTWM on old Sun 5 > > workstations back in the 90's. If Debian still packages it, look for rxvt > > instead, or use xterm. Both are well tried and well tested for when you > > want something .. dated. ;) > > The original rxvt is no longer packaged in Debian, as far as I can see. > There's rxvt-unicode, which is what I use, which has most of the same > look and feel as rxvt, but is substantially larger. I pulled down rxvt-unicode and started looking at how to configure it up so that it works more or less like kitty (which is what I normally use). > Between xterm and rxvt-unicode you should have most of your "basic > no-frills terminal" needs met by one or the other. I was right about .Xresources that it is one of the files used for loading settings into the X server, but urxvt looks at .Xdefaults instead. If one puts something like the below into .Xdefaults in $HOME, it works with Powerline and it does not look too terrible. Rxvt.depth: 24 Rxvt.jumpScroll: on Rxvt.fading: 20 Rxvt.background: #101010 Rxvt.foreground: #efefef Rxvt.cursorColor: #dd Rxvt.font: xft:Hack:pixelsize=16,xft:Powerline:pixelsize=16 Rxvt.boldFont: xft:Hack Bold:pixelsize=16,xft:Powerline:pixelsize=16 Rxvt.italicFont: xft:Hack Italic:pixelsize=16,xft:Powerline:pixelsize=16 Rxvt.boldItalicFont: xft:Hack BoldItalic:pixelsize=16,xft:Powerline:pixelsize=16 Rxvt.loginShell: on Rxvt.visualBell: on Rxvt.scrollBar_right: on Rxvt.scrollBar_floating: on Rxvt.saveLines: 5000 Rxvt.termName: xterm-256color Rxvt.disablePasteBrackets: off As per usual, getting the fonts right was the hardest part. As for memory use.. USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND sirius 56392 0.1 0.1 48136 28160 ?S16:48 0:00 /usr/bin/urxvt sirius 56393 0.0 0.0 21928 816 ?S16:48 0:00 /usr/bin/urxvt sirius 56465 0.1 0.1 43192 23232 ?S16:52 0:00 /usr/bin/urxvt sirius 56466 0.0 0.0 21928 820 ?S16:52 0:00 /usr/bin/urxvt sirius 56532 2.5 1.0 745480 150828 ? Sl 16:54 0:02 /usr/bin/kitty sirius 56533 1.5 0.2 61388 35692 ?Ss 16:54 0:01 /usr/bin/kitty sirius 56595 0.0 0.0 9212 2096 pts/2S+ 16:55 0:00 grep kitty\|rxvt\|USER Good old urxvt is quite lightweight compared to kitty. -- Kind regards, /S
Re: Zutty fonts - zutty always uses the same font and fontsize
In days of yore (Wed, 01 May 2024), Richmond thus quoth: > I am puzzled by the zutty terminal emulator. I have tried: > > 1186 zutty -fontpath /usr/share/fonts/X11/ -fontsize 20 > 1187 zutty -fontpath /usr/share/fonts/X11/ -font adobe > 1190 zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 20 > 1191 zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 24 > 1192 zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 12 > 1193 zutty -font 9x20 > 1198 zutty -fontsize 10x20 > 1199 zutty -fontpath /usr/share/fonts/X11/misc/ -fontsize 10x20 > 1200 zutty -font 10x20 > > I clearly have fonts: > > find /usr/share/fonts -print|grep "x20" > /usr/share/fonts/X11/misc/10x20-ISO8859-9.pcf.gz > /usr/share/fonts/X11/misc/10x20-ISO8859-3.pcf.gz > /usr/share/fonts/X11/misc/10x20-ISO8859-11.pcf.gz Use 'xlsfonts' to see what fonts are available and use those names. I can get it working with "zutty -font 12x24" and other numerically named fonts. Trying with something like 'lucidasans-24' will make it dump core however. Maybe it respects what you tell it via .Xresources or what the file used to be called, when you had to configure fonts by sitting with xfontsel and try and work out what would look decent. The manual pages for xterm should have enough clues for how to configure that - I have already forgotten all that stuff as it no longer is required with the more modern terminal emulators. > Nothing I have tried works, zutty always uses the same rather small > font. > > https://tomscii.sig7.se/zutty/doc/USAGE.html#Font%20selection > > Has this package been implemented correctly? > > aptitude show zutty > Package: zutty > Version: 0.14.0.20230218+dfsg1-1 > > cat /etc/issue > Debian GNU/Linux 12 \n \l zutty is kind of only necessary when you want something *really* lightweight and you do not need to worry about UTF-8. Just writing this means a trip down memory lane and back to configuring CTWM on old Sun 5 workstations back in the 90's. If Debian still packages it, look for rxvt instead, or use xterm. Both are well tried and well tested for when you want something .. dated. ;) -- Kind regards, /S
Re: is security.debian.org broken
In days of yore (Wed, 17 Apr 2024), fxkl4...@protonmail.com thus quoth: > have a look at > > https://security.debian.org/debian-security/dists/bookworm-security/updates/ > > is it broken or just me > w.f.m. from here (Sweden). -- Kind regards, /S
Re: e1000e driver Network Card Detected Hardware Unit Hang
In days of yore (Tue, 16 Apr 2024), Jamie thus quoth: > Look this is a kernel bug and Debian needs to > fix this! Don't give me any of this crap about upstream > this is a bug with the Debian Kernel! Pay attention, because I am now in Support Mode as a former Principal Technical Account Manager for Red Hat. No, this is not necessarily a kernel bug. It can be a hardware bug and it is plausible it can not be solved with a driver work-around. You are hitting a problem and you want someone else to fix it for you. The answer may simply be that you need to replace the NIC with something else. FWIW, I have these Intel NICs in my two NUCs and they are functioning fine. With Debian 12.5 and the latest updates. $ lspci -v -s 00:1f.6 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-V (rev 21) DeviceName: LAN Subsystem: Intel Corporation Ethernet Connection I219-V Flags: bus master, fast devsel, latency 0, IRQ 123, IOMMU group 7 Memory at df10 (32-bit, non-prefetchable) [size=128K] Capabilities: Kernel driver in use: e1000e Kernel modules: e1000e The revision of the NIC may determine whether you have *hardware* problems or not. > This needs to be fixed! Quick answer: replace the NIC. And do some groundwork to determine if the NIC you replace it with has issues you should be aware of or not. > I have already tried disabling the offloads and it does > not work. The specific offloads seemed to be the CRC related ones. # ethtool -k eno1 Features for eno1: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: off [fixed] tx-checksum-ip-generic: on tx-checksum-ipv6: off [fixed] tx-checksum-fcoe-crc: off [fixed] tx-checksum-sctp: off [fixed] Note: when you disable these, throughput can drop sharply. The other setting suggested was to hike the TX ringbuffer. # ethtool -g eno1 Ring parameters for eno1: Pre-set maximums: RX: 4096 RX Mini:n/a RX Jumbo: n/a TX: 4096 Current hardware settings: RX: 256 RX Mini:n/a RX Jumbo: n/a TX: 256 RX Buf Len: n/a CQE Size: n/a TX Push:off TCP data split: n/a # ethtool -G eno1 tx 2048 rx 2048 # ethtool -g eno1 Ring parameters for eno1: Pre-set maximums: RX: 4096 RX Mini:n/a RX Jumbo: n/a TX: 4096 Current hardware settings: RX: 2048 RX Mini:n/a RX Jumbo: n/a TX: 2048 RX Buf Len: n/a CQE Size: n/a TX Push:off TCP data split: n/a The reason the ringbuffers are important is that the kernel and the OS can construct packets faster in bursts than the NIC can handle, so the OS can queue up packets in the ringbuffer and the NIC can asynchronously pick the packets from the buffer and send them across the wire. If the ringbuffers are set too small, they will overflow and you will get overflow errors. # ethtool -S eno1 NIC statistics: rx_packets: 24463 tx_packets: 6358 rx_bytes: 3093199 tx_bytes: 669733 rx_broadcast: 8044 tx_broadcast: 9 rx_multicast: 10434 tx_multicast: 2510 rx_errors: 0 tx_errors: 0 tx_dropped: 0 If buffers are set too small, this increases multicast: 10434 collisions: 0 rx_length_errors: 0 rx_over_errors: 0 rx_crc_errors: 0 rx_frame_errors: 0 rx_no_buffer_count: 0 rx_missed_errors: 0 tx_aborted_errors: 0 tx_carrier_errors: 0 tx_fifo_errors: 0 tx_heartbeat_errors: 0 tx_window_errors: 0 tx_abort_late_coll: 0 tx_deferred_ok: 0 tx_single_coll_ok: 0 tx_multi_coll_ok: 0 tx_timeout_count: 0 tx_restart_queue: 0 rx_long_length_errors: 0 rx_short_length_errors: 0 rx_align_errors: 0 tx_tcp_seg_good: 0 tx_tcp_seg_failed: 0 rx_flow_control_xon: 9 rx_flow_control_xoff: 9 tx_flow_control_xon: 0 tx_flow_control_xoff: 0 rx_csum_offload_good: 8539 If you have issues with checksum rx_csum_offload_errors: 0 offload, check these rx_header_split: 0 alloc_rx_buff_failed: 0 tx_smbus: 0 rx_smbus: 0 dropped_smbus: 0 rx_dma_failed: 0 tx_dma_failed: 0 rx_hwtstamp_cleared: 0 uncorr_ecc_errors: 0 corr_ecc_errors: 0 tx_hwtstamp_timeouts: 0 tx_hwtstamp_skipped: 0 > It isn't the cable either I have tried different cables it > still happens! This is an issue with the Kernel module for > the e1000e NIC card. Excellent data-point, you have ruled out whether the cable is faulty or not. But your assumption that this is the kernel module that is broken is still faulty. Provably, I am running the same type of NIC (albeit a different revision) with the same driver and I do not observe any issues. Thus, leveraging Occam's Razor, it follows that scrutinising your particular NIC
Re: e1000e driver Network Card Detected Hardware Unit Hang
In days of yore (Tue, 16 Apr 2024), Sirius thus quoth: > In days of yore (Mon, 15 Apr 2024), Jamie thus quoth: > > So there is a very nasty bug in the e1000e network card > > driver. Doing some reading turned up a Proxmox thread about the issues with these Intel NICs. https://forum.proxmox.com/threads/e1000-driver-hang.58284/page-10 May be worth scanning that thread and applying some of their solutions to this problem. -- Kind regards, /S
Re: e1000e driver Network Card Detected Hardware Unit Hang
In days of yore (Mon, 15 Apr 2024), Jamie thus quoth: > So there is a very nasty bug in the e1000e network card > driver. https://www.intel.com/content/www/us/en/support/articles/05480/ethernet-products.html notes that MSI interrupts may be problematic on some systems. Worth digging into whether that is an issue on this system of yours. I am not sure Debian can resolve this problem with the driver, but upstream kernel folks might. Unsure whether Intel still helps maintain this driver as it is quite old (I dealt with support issues on this driver some 15-16 years ago). The Intel page states this is upstream kernel only at this point, so going to SourceForge for their out-of-tree driver is no longer an option. > I am running Debian 12 Bookworm. > > You will get the message "Detected Hardware Unit Hang" and then > the network card just stops working. [snip] > This is a gigabit network card as I said it is a built in NIC I believe it > is an Intel NIC. It is an Intel NIC. Most of the NIC drivers beginning with an 'e' followed by numbers are Intel as far as I know. These NICs were very common as on-board NICs in OEM systems as Intel provided them in large volumes. They are not the best, but they usually do their job. [snip] > This seems to happen when you are actually pushing a bit of traffic > though it not a lot but just even a little bit. It isn't network overload > or anything I am barely doing anything really but it will do this. If it is a hardware hang, it may be the NIC firmware getting its knickers in a twist, and that is not something the kernel or the driver can do much about. > I have already tried the following > > ethtool -K eth1 tx off rx off > ethtool -K eth1 tso off gso off > ethtool -K eth1 gso off gro off tso off tx off rx off rxvlan off txvlan > off sg off All worthwhile things to try. You can also try reducing the RX buffers from the default 4096 to 2048 if you are not running a lot of traffic. It might not help, but worth trying. > I have disabled all power management in the bios as well including the one > for ASPM > > I added the following to grub > > pcie_aspm=off e1000e.SmartPowerDownEnable=0 > > > This is in /etc/default/grub > GRUB_CMDLINE_LINUX_DEFAULT="quiet pcie_aspm=off > e1000e.SmartPowerDownEnable=0" Good thinking about power management. :) > Then I did an update-grub as well. > > None of this has worked in fixing this problem. I am still getting the > same issue. Best bet at this point would be to scout the Linux Kernel Mailing List archives to see if anyone else have run into the same problems, and then reviewing the kernel maintainers list to find someone that works on the e1000e driver to strike up a direct dialogue with them. > Can you please fix this issue this is a really nasty problem with Debian > 12 (Bookworm) > > I am seeing this being reported back in Kernel 5.3.x but i am not seeing any > reports for 6.1.x about this issue. > > Debian Bug report logs - #945912 > Kernel 5.3 e100e Detected Hardware Unit Hang > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945912 If it has been reported before and is still present now, one of two things is likely true. 1) the problem was intermittent and could not be reliably reproduced in order to debug and resolve 2) the problem was related to the hardware itself, and there was no way to fix it in either driver or firmware It has been known to happen that drivers implement workarounds for issues in the hardware itself, so that hardware bugs do not get tripped (or are tripped less often). > Please reply back and confirm that you got this email and that you are > looking into this problem please. To state the obvious, I am not a kernel maintainer for Debian and do not speak on behalf of the Debian project. I work for a Linux company you may have heard of and have done so for almost eighteen years, a decade of which was in support. 15 years ago, I know exactly who I would have gone to to look into this problem, but he now works for Broadcom and probably has forgotten all about the e1000/e1000e drivers. Upstream driver maintainer would be the best bet IMHO. If this driver is community support only (i.e. if Intel no longer participates in driver maintenance), I would say that all bets are off. With only one datapoint - your system and your NIC, it is not possible to rule out that the NIC itself is bad. :-/ > -- This email message, including any attachments, is for the intended > recipient(s) only and may contain information that is privileged, > confidential and/or exempt from disclosure under applicable law. If you > have received this message in error, or are obviously not one of the > intended recipients, please immediately notify the sender by reply email > and delete this email message, including any attachments. All > information in this email including any attachment(s) is to be kept in > strict confidence and is not to be released to anyone without my prior > written
Re: filesystem info
In days of yore (Sun, 24 Mar 2024), fxkl4...@protonmail.com thus quoth: > when i type mount i see many different filesystem names > > sysfs, proc, udev, devpts, tmpfs, securityfs, cgroup2, pstore, none, > systemd-1, hugetlbfs, mqueue, debugfs, tracefs, sunrpc, fusectl, configfs > binfmt_misc, portal > > is there "simple" documentation to explain what these are > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/filesystems?h=v6.8.1 The Linux Kernel sources have a Documentation tree that documents many aspects and features of the kernel. There may be a kernel-doc package you can install that should put that documentation right onto your system in /usr/share/doc/kernel/. Do note: reading the docs about /proc and /sys (procfs and sysfs respectively) may give ideas - write those ideas down if you decide to try them out so you have a record of what you might have done on the system. It can be relatively easy to unintentionally cause bad performance by poking around with those settings. Happy learning! -- Kind regards, /S
Re: Anyone using xmonad + vim on sid?
I can reproduce this with another (tiling) windowmanager: Debian Sid (upgraded today) with wmii. It works as long as I keep the window on the screen where I started gvim. When I move it to my second screen it freezes, resulting in the error you quoted on the terminal. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20110930t220203-...@post.gmane.org
Linux Cdsi
Merhaba,Biz Erciyes Üniversitesi Mekatronik Kulübü Olarak Linux'un tanınması amacıyla her üyemize Linux Cd'si vermek istiyoruz.Fakat cd ücretinikulüp olarak karşılamamız zor.Bir miktar Ubuntu'dan cd istedik ve geldi.Ayrıca Pardus için Uludağ'dan da Cd istedik.Fakat bu sayı bizim için yeterli olmayabilir.Bu yüzden bize bu konuda yardımcı olabilirseniz çok sevineceğiz. İyi Çalışmalar Erciyes Mekatronik Kulübü[EMAIL PROTECTED](E-postanızı Direkt olarak buraya atabilirsiniz.)www.ermek.org
