Emoji broken in gnome-terminal
Hellow, I am using Gnome desktop in Debian Sid. Today, after upgrade package via apt update/upgrade, i can not see emoji in gnome-terminal. Here related screenshot[1]: https://gitlab.com/soyeomul/stuff/-/raw/8bec2cc5d8b9d74438c17b8c202d753b15c09ab6/test-emoji.png Really i would like to solve this problem. Thanks, Byunghee from South Korea signature.asc Description: This is a digitally signed message part
Re: partition reporting full, but not
Keith Bainbridge composed on 2024-02-17 15:44 (UTC+1100): Yes the / partitions are btrfs Several years ago, I installed Debian (9?) using btrfs for root (and boot?). I failed to understand that btrfs required regular maintenance and/or I was too lazy to figure it out and do it. After a few months, the systems started running slowly and I seem to recall conflicting reports of storage usage. I STFW, RTFM, etc., and tried doing the maintenance by hand. I quickly came to the conclusion that I needed to run `btrfs balance start ...` many, many times. So, I wrote Perl script and let it hammer on the file systems for hours at a time (!). I was able to rescue most of the disks to decent performance, but one was especially bad and I was only able to rescue it to marginal performance. I continued running btrfs for a while and running the Perl script periodically. Ultimatedly, I backed up, put in fresh OS disks, and installed using ext4. This was one of my reasons to use FreeBSD and ZFS for my SOHO servers. David
Re: f3tools vs Silicon Power 4T drive
On Sat, Feb 17, 2024 at 07:59:52PM -0500, gene heskett wrote: > On 2/17/24 00:35, to...@tuxteam.de wrote: > > On Fri, Feb 16, 2024 at 12:12:06PM -0800, David Christensen wrote: > > > On 2/15/24 17:44, gene heskett wrote: > > > > [...] > > > > > > Other than that the gui access delay (30+ seconds) problems I have did > > > > NOT go away when I moved /home off the raid to another SSD [...] > > > > I think at this point few are surprised by that. Last round of debugging > > we pretty much eliminated disk access as likey cause of those delays. > > > > The most hopeful cause for a candidate, IIRC, was some thingy deep in the DE > > trying to access an unavailable resource. > > > > Cheers > Is there some way to identify that roadblock? > > It sure seems to me there ought to be a way to identify whatever it is that > is causing it.. No single path, alas. The most pin-pointed description we have is some editor blocking while trying to "open a file" (whatever those gooey thingies do in that situation). So perhaps stracing it and seeing whether it's blocking in a system call might give a clue. Wading through the logs around that delay might, too. One trick I sometimes use in those cases is to have a teminal open and create syslog messages (with logger) to have timestamps marking the start/end of the perceived delays. > Take care, stay warm and well Tomas First signs of spring around here. Take care -- tomás signature.asc Description: PGP signature
Re: Contact Name...
On Sat, Feb 17, 2024 at 12:01:13PM +0100, Thomas Schmitt wrote: > Hi, > > Clayton Penn wrote: > > I have attempted to register for the Debian Forums, but have not received a > > verification email > > Did you try wether your new account is already working ? > (Sorry, i'm not familiar with the current registration procedure.) > > If not: > There seems to be some problem with GMail: > > https://forums.debian.net/viewtopic.php?t=158230 > > Are you perhaps directly or indirectly using GMail ? > > > > Do you happen to have another email address contact? > > I have an account at forums.debian.net, although not used in years. > So if you want to add information to above topic, i could try to do so > on your behalf. > > But first consider to try registering with a completely different mail > provider which is surely not using GMail's software. The given mail address is @icloud.com: I guess that's Apple, not Google. But this doesn't mean they are any better. My guess is that icloud is either dumping the reply mail into some dark spam corner to make sure the user doesn't see it (as Google likes to do) or plainly rejecting (as Microsoft likes to do). Or, to try a new path (Apple, after all), simply dropping it. Cheers -- t signature.asc Description: PGP signature
Re: sudo udisksctl
On 18/02/2024 11:40, David Wright wrote: $ ssh bhost $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01 Passphrase: AUTHENTICATING FOR org.freedesktop.udisks2.encrypted-unlock === Authentication is required to unlock the encrypted device Multiple Card Reader (/dev/sdc1) It should be possible to modify policy to allow a specific user or a group to perform disk operations, see polkit(8). When sudo is involved, I still do not see any advantage of udiskctl over "cryptsetup open". As third option, if I remember it correctly, pmount relies on group membership, not on systemd-logind "uaccess", so local vs. remote user should not matter. This variant combines unlock and mount into a single command.
Re: sudo udisksctl
On Sun 18 Feb 2024 at 10:23:52 (+0700), Max Nikulin wrote: > I have decided to ask the following in a separate thread. > > On 17/02/2024 02:59, David Wright wrote > (Re: f3tools vs Silicon Power 4T drive): > > lulu () { sudo udisksctl unlock --block-device > > /dev/disk/by-partlabel/Lulu01 && mount /media/lulu01 > > } > > I am evaluating if udisks2 D-Bus API allows to create a tool as > convenient as pmount(1) that is smart enough to unlock a device before > mounting it (optionally with specified name of mountpoint) > > pmount /dev/sda1 mybackup > > I have puzzled by your function however. I believed that udisks was > created to allow *regular* users to mount drives. If you are using > sudo why do not you use "cryptsetup open" directly? Otherwise > udisksctl can ask password if policy does not allow disk operations > for the current user. > > P.S. Unfortunately mount name is hardcoded in udisksd. It is either > label or UUID, it can not be specified when a partition is mounted. Because policykit allows me to unlock partitions only if they're local. I rely on being able to unlock partitions remotely. For example, if I wakeonlan the PC in the basement, I need to be able to unlock its /home before I can login as myself. As a demonstration: $ hostname bhost $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01 Passphrase: Unlocked /dev/sdc1 as /dev/dm-2. $ udisksctl lock --block-device /dev/disk/by-partlabel/Nokia01 Locked /dev/sdc1. $ is fine, but ssh to a laptop and back to this machine: $ ssh ahost Linux ahost 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64 [ … ] You have new mail. Last login: Sun Feb 18 04:18:39 2024 from 192.168.1.14 $ ssh bhost Linux bhost 5.10.0-28-amd64 #1 SMP Debian 5.10.209-2 (2024-01-31) x86_64 [ … ] You have new mail. Last login: Sun Feb 18 04:18:44 2024 from 192.168.1.16 $ udisksctl unlock --block-device /dev/disk/by-partlabel/Nokia01 Passphrase: AUTHENTICATING FOR org.freedesktop.udisks2.encrypted-unlock === Authentication is required to unlock the encrypted device Multiple Card Reader (/dev/sdc1) Authenticating as: root Password: [ pressed ^C ] That's what I'm avoiding with sudo. Cheers, David.
Re: partition reporting full, but not
On 18/2/24 09:19, Cindy Sue Causey wrote: I only know to say this because it just happened a few days ago. Rsync left some semi-permanent remnants when I was having problems with the wireless capable hard drive docking station repeatedly cutting out. I was offloading videos and images from a camera during many of those times. Thanks Cindy Interesting Though as far as I can recall the only files I have rsync'd onto / are 4or5 config files, and all in /home/keith which now on another partition. And with a gain in free space which virtually matches its reported space used, yesterday. -- All the best Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00
Re: partition reporting full, but not
On 18/2/24 07:34, debian-u...@howorth.org.uk wrote: Keith Bainbridge wrote: Yes the / partitions are btrfs So the apparently missing space is perhaps taken up by btrfs snapshots. Seems to be the prime suspect. If that's the case, btrfs is NOT hard-linking the snapshots as timeshift claims it does. The only way to check is install on ext4 and compare. I have saves enough free space to do this. My effort to date is to move my home to /mnt/data and sim-link it into /home. df is now showing 2.3GB free on /. df showed /home as 2.2GB yesterday. At least there is a little space to play with; and give me time to consider. A fresh install may be worth checking in snapshots are as big as this all makes them look. a few brief answer to other comments will follow -- All the best Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00
sudo udisksctl
I have decided to ask the following in a separate thread. On 17/02/2024 02:59, David Wright wrote (Re: f3tools vs Silicon Power 4T drive): lulu () { sudo udisksctl unlock --block-device /dev/disk/by-partlabel/Lulu01 && mount /media/lulu01 } I am evaluating if udisks2 D-Bus API allows to create a tool as convenient as pmount(1) that is smart enough to unlock a device before mounting it (optionally with specified name of mountpoint) pmount /dev/sda1 mybackup I have puzzled by your function however. I believed that udisks was created to allow *regular* users to mount drives. If you are using sudo why do not you use "cryptsetup open" directly? Otherwise udisksctl can ask password if policy does not allow disk operations for the current user. P.S. Unfortunately mount name is hardcoded in udisksd. It is either label or UUID, it can not be specified when a partition is mounted.
Re: partition reporting full, but not
On 17/02/2024 09:52, Greg Wooledge wrote: If so, you *could* have data inside the /home directory of the root file system, which is hidden by the /home file system that's mounted over it. You'd need to unmount /home to check. A less intrusive way to inspect shadowed directories is bind mounts. mkdir /tmp/root mount --bind / /tmp/root
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On 2/17/24 13:45, Roy J. Tellason, Sr. wrote: On Friday 16 February 2024 04:42:12 pm Gremlin wrote: On 2/16/24 13:56, Roy J. Tellason, Sr. wrote: On Friday 16 February 2024 04:52:22 am David Christensen wrote: I think the Raspberry Pi, etc., users on this list live with USB storage and have found it to be reliable enough for personal and SOHO network use. I have one, haven't done much with it. Are there any alternative ways to interface storage? Maybe add SATA ports or something? On raspberry Pi 1 to 4 No, you have a choice of USB 2 or USB 3 Looks like I'll have to go with a USB - SATA adapter, then. It's a 4, I bought the "Canakit" package that included an enclosure, keyboard, mouse, and a small touch screen (4"?). Raspberry Pi 5 Yes with and NVME hat interfaced to the pcie "port" I am using a Pi 5 (desktop) with USB 3 port hooked to an NVME external drive and it works just fine. It is much faster than the Pi 4 I was using because of the new "south bridge" I'm aware of the 5 having come out, but haven't explored the possibility of getting one of those yet. StarTech makes an excellent sata-III to usb3 adapter for about a tenner a copy. So a 7 port hub takes up only 1 or the 4 usb3 ports on a bpi-m5, leaving 3 more ports available on the bpi-m5 itself. See at ssh into it from the Main system and run the pi headless. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: f3tools vs Silicon Power 4T drive
On 2/17/24 00:47, gene heskett wrote: On 2/16/24 21:13, Andy Smith wrote: Hello, On Fri, Feb 16, 2024 at 02:02:59PM -0600, David Wright wrote: On Fri 16 Feb 2024 at 14:48:12 (+), Andy Smith wrote: No, because it's a filesystem label for the ext4 fs created on /dev/sdz1. If sdz1 is turned into an LVM Physical Volume, there won't be an ext4 filesystem on it any more. If sdz1 is turned into a member of an MD array, there won't be an ext4 filesystem on it any more. The labels go with the filesystem. It isn't a filesystem LABEL. Oh dear, I am lost. I don't use gparted but at least one person in this thread has said that Gene created a filesystem label not a partition name, and Gene doesn't know which he created, so I've gone from guessing partition name to fs label and now back to partition name again. I'm totally willing to believe that you know what you've created there though, so fair enough. You've not yet been clear about what you want, but from what little information you have provided you've been told multiple times by multiple people that filesystem labels won't help. ↑ … which would be moot if only Gene could create partition PARTLABELs successfully. Which I have found can also be done with gparted, so the 1st 2 drives which will be put in slot 2 as the Top and Bottom drives in that 2 drive adaptor in slot 2, have had their partitions labeled as SIPWRS2T and SIPWRS2B. And labeled as such with a P-Touch. The other 2 that just walked in the door, are still cold enough to sweat if unsealed. Sure, but we still don't know what Gene is trying to do or why partition names would be useful to him so I am kind of sceptical that this leads anywhere. That part if the ^%$ drives ever get here, I just looked at the front deck and it has 2" of fresh white stuff on it. To describe what I am building, this is a 5 slot bare drive cage. You could throw tom cats thru it from most angles so I printed pretty sides for it. I've printed drawers to fill those slots. The top slot has a bpi-m5 in it, the bottom slot has a 5 volt 10 amp psu in it. slot 2 will have 2 of those nearly 4T SSD's in a 2 drive adapter, with full disk partitions on them, so obviously I should name the top one as "si-pwr-s2t". the bottom one then s/b si-pwr-s2b slot-3 then s/b si-pwr-s3t and si-pwr-s3b. slot-4 then is giga-s4t1 and giga-s4t2. ditto for the bottom one. named giga-s4b1 and giga-s4b2. 1 partition to hold amanda's database and one to serve as amanda's holding disk. Whats so meaningless to you that you can't see the utility in that? That has not been explained, so please educate me as to why you think its worthless? Thanks, Andy Cheers, Gene Heskett, CET. Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: f3tools vs Silicon Power 4T drive
On 2/17/24 00:35, to...@tuxteam.de wrote: On Fri, Feb 16, 2024 at 12:12:06PM -0800, David Christensen wrote: On 2/15/24 17:44, gene heskett wrote: [...] Other than that the gui access delay (30+ seconds) problems I have did NOT go away when I moved /home off the raid to another SSD [...] I think at this point few are surprised by that. Last round of debugging we pretty much eliminated disk access as likey cause of those delays. The most hopeful cause for a candidate, IIRC, was some thingy deep in the DE trying to access an unavailable resource. Cheers Is there some way to identify that roadblock? It sure seems to me there ought to be a way to identify whatever it is that is causing it.. Take care, stay warm and well Tomas Cheers, Gene Heskett, CET. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
Re: hexchat being discontinued?
On Mon, 2024-02-12 at 09:16 +0900, Byunghee HWANG (황병희) wrote: > Hellow^^^ > > On Sat, 2024-02-10 at 19:54 -0500, Default User wrote: > > :( > > (...) > > Any recommendations for a GOOD alternative? > > How about Emacs? > > > Sincerely, Byunghee > Hi to all. I am just going to continue to use hexchat for a while, and then switch to Pidgin. Thanks for the replies!
Re: partition reporting full, but not
On 2/17/24, Greg Wooledge wrote: > On Sat, Feb 17, 2024 at 04:00:14PM -0500, Stefan Monnier wrote: >> > So the apparently missing space is perhaps taken up by btrfs snapshots. >> >> Another possibility is a (few) large file(s) that is/are still open for >> some process(es) but have been `rm` (`unlink`) so they don't have a name >> any more. > > In the original post, they said they rebooted, in order to rule this out. I only know to say this because it just happened a few days ago. Rsync left some semi-permanent remnants when I was having problems with the wireless capable hard drive docking station repeatedly cutting out. I was offloading videos and images from a camera during many of those times. There were 3 to 5 instances of discarded remnant files in several directories while the problem was ongoing (MANY times over a couple weeks). The residual files were only visible when in CTRL+H view in Thunar. Sizes ranged from a few MB to almost a GB. All had to be manually removed. PS That hardware problem, which I think I mentioned in another thread, is semi-solved... and appears to be a possible case of [WIFI] jamming, of all things. If it starts up again, there will possibly be a new thread asking about potential tracking packages. Current instant fix? Tweet very loudly about the issue and its potential source Cindy :) NB See Also: Minnesota burglaries via suspected WIFI jamming (e.g. on reddit). -- Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
Re: partition reporting full, but not
On Sat, Feb 17, 2024 at 04:00:14PM -0500, Stefan Monnier wrote: > > So the apparently missing space is perhaps taken up by btrfs snapshots. > > Another possibility is a (few) large file(s) that is/are still open for > some process(es) but have been `rm` (`unlink`) so they don't have a name > any more. In the original post, they said they rebooted, in order to rule this out.
Re: partition reporting full, but not
> So the apparently missing space is perhaps taken up by btrfs snapshots. Another possibility is a (few) large file(s) that is/are still open for some process(es) but have been `rm` (`unlink`) so they don't have a name any more. Stefan
Re: partition reporting full, but not
Keith Bainbridge wrote: > Yes the / partitions are btrfs So the apparently missing space is perhaps taken up by btrfs snapshots.
Re: What sets LC_TIME?
On Sat, Feb 17, 2024 at 08:18:41PM +, debian-u...@howorth.org.uk wrote: > Greg Wooledge wrote: > > > That's all normal and expected. > > > > What's odd is that client *actually has* LC_NUMERIC and so on set in > > its environment. Which... is not a problem if they're all set to the > > correct values. It's weird, but not wrong. The problem for the OP > > was that one of the values was not set correctly, or at least not as > > expected. > > It's not weird at all. It's how many people set their machines, when > they have logical minds and prefer -MM-DD date format rather than > the illogical messes most countries have in their locales. It's weird to set *every* LC_* variable when all you want to change is LC_TIME. I personally set LANG and LC_TIME. But I don't set the others. Why would I? That would be weird. unicorn:~$ locale LANG=en_US.utf8 LANGUAGE= LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME=C LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL= As you can see, the only variables with unquoted, non-empty values are LANG and LC_TIME.
Re: What sets LC_TIME?
Greg Wooledge wrote: > That's all normal and expected. > > What's odd is that client *actually has* LC_NUMERIC and so on set in > its environment. Which... is not a problem if they're all set to the > correct values. It's weird, but not wrong. The problem for the OP > was that one of the values was not set correctly, or at least not as > expected. It's not weird at all. It's how many people set their machines, when they have logical minds and prefer -MM-DD date format rather than the illogical messes most countries have in their locales.
Re: f3tools vs Silicon Power 4T drive
gene heskett wrote: > On 2/16/24 15:47, Stefan Monnier wrote: > >>> One of the 1T samsungs in the md raid10 isn't entirely happy but > >>> mdadm has not fussed about it, and smartctl seems to say its ok > >>> after testing. Other than that the gui access delay (30+ seconds) > >>> problems I have did NOT go away when I moved /home off the raid > >>> to another SSD, so I may move it back. One of the reasons I ma > >>> rsync'ing this /home back to it every other day or so, takes < 5 > >>> minutes. > >> Please get a small SSD, do a fresh install, and test for the > >> access delay. If the delay is not present, incrementally add and > >> test applications. If you encounter the delay, please stop and > >> post the details; console sessions are best. If not, then connect > >> the disks with /home and test. If you encounter the delay, then > >> please stop and post the details. If you do not encounter the > >> delay, then your system is fixed. Take a Clonezilla image. > > > > FWIW, my crystal ball says "30s => software timeout rather than > > hardware problem" > > > > > > Stefan > > We are on the same page, but what is causing the timeout? You have to follow the steps David suggested including posting the details here as asked, before anybody will be able to answer your question!
Re: SMART Uncorrectable_Error_Cnt rising - should I be worried?
On Friday 16 February 2024 04:42:12 pm Gremlin wrote: > On 2/16/24 13:56, Roy J. Tellason, Sr. wrote: > > On Friday 16 February 2024 04:52:22 am David Christensen wrote: > >> I think the Raspberry Pi, etc., users on this list live with USB storage > >> and have found it to be reliable enough for personal and SOHO network use. > > > > I have one, haven't done much with it. Are there any alternative ways to > > interface storage? Maybe add SATA ports or something? > > > On raspberry Pi 1 to 4 No, you have a choice of USB 2 or USB 3 Looks like I'll have to go with a USB - SATA adapter, then. It's a 4, I bought the "Canakit" package that included an enclosure, keyboard, mouse, and a small touch screen (4"?). > Raspberry Pi 5 Yes with and NVME hat interfaced to the pcie "port" > > I am using a Pi 5 (desktop) with USB 3 port hooked to an NVME external > drive and it works just fine. > > It is much faster than the Pi 4 I was using because of the new "south > bridge" I'm aware of the 5 having come out, but haven't explored the possibility of getting one of those yet. -- Member of the toughest, meanest, deadliest, most unrelenting -- and ablest -- form of life in this section of space, a critter that can be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters" - Information is more dangerous than cannon to a society ruled by lies. --James M Dakin
Re: f3tools vs Silicon Power 4T drive
Hi, On Sat, Feb 17, 2024 at 12:46:25AM -0500, gene heskett wrote: [38 lines of irrelevance snipped out of a 71 line email] > I've printed drawers to fill those slots. The top slot has a bpi-m5 in it, > the bottom slot has a 5 volt 10 amp psu in it. slot 2 will have 2 of those > nearly 4T SSD's in a 2 drive adapter, with full disk partitions on them, so > obviously I should name the top one as "si-pwr-s2t". the bottom one then s/b > si-pwr-s2b > slot-3 then s/b si-pwr-s3t and si-pwr-s3b. > slot-4 then is giga-s4t1 and giga-s4t2. ditto for the bottom one. named > giga-s4b1 and giga-s4b2. 1 partition to hold amanda's database and one to > serve as amanda's holding disk. > > Whats so meaningless to you that you can't see the utility in that? I've got no issue with putting a drive identifier on the physical caddy/drawer that holds that drive. I do it myself. You have not ever before in this thread mentioned this, so neither I nor anyone else has objected to it. What I question the value of, is putting a drive identifier into a partlabel when the id of the partition will contain all of the same information. I have also asked you several times what it is you intend to do with that information in the context of a RAID array or LVM LV and you haven't yet been able to tell me. The closest you have come so far is saying, "I want to identify a drive when the array has problems". As you don't specify what those problems might be, all I am able to say to that is that you can either find the problem device from your logs or by listing the devices in the array/LV, and from there map to exact model and serial number from what's in the /dev/disk/by-id/. Now, I understand that you have multiple drives that have the same model and serial number. I accept that if you're going to use multiple of these in the same machine then that makes using by-id/ impossible. I've advised that I would never use multiple of these in the same machine because they are broken and will likely cause other problems further down the line. So if you want to say: despite the duplicate serial number issue I am determined to use multiple of these drives, so by-id/ is useless to me and I will instead replicate that info in partlabels and use /dev/disk/by-partlabel/, then okay! I don't agree with that course of action, but it is at least a cogent argument. So say if that's the case and we can just move on. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Debian/Xen on ARM: How to identify source of an unhandled SMC call during boot?
Am 31.01.2024 um 23:12 schrieb Tixy: On Wed, 2024-01-31 at 21:59 +0100, hw wrote: On Wed, 2024-01-31 at 08:02 +0100, Paul Leiber wrote: Am 25.01.2024 um 22:28 schrieb Paul Leiber: [...] Some people on xen-devel pointed out to me two unhandled SMC calls in the boot logs which could be the root of the problem. I am now trying to find out where these calls come from to get closer to the root cause. The suspected calls are the following ones: (XEN) d0v0 Unhandled SMC/HVC: 0x8450 (XEN) d0v0 Unhandled SMC/HVC: 0x8600ff01 These calls happen during the Dom0 boot process, so it's something from inside Linux and nothing Xen related, I've been told. The current working hypothesis is that the calls are trying to find some module not emulated by Xen and are therefore failing, leading to Linux waiting for the reply, and subsequently to the Xen watchdog triggering and rebooting. From what I could find out in ARM documentation, the unhandled SMC calls probably have the following purpose: 0x8450 = TRNG_VERSION, returns the implemented TRNG (True Random Number Generator) ABI version [2] 0x8600ff01 = Call UID Query for Vendor Specific Hypervisor Service, Returns a unique identifier of the service provider [3] The more likely cause is the second call to the address 0x8600ff01. Now I simply have no idea how to find out where in the Linux boot process these calls are made. I tried poking into the Linux sources a bit, and I couldn't find an exact match for these call addresses, so I assume these addresses are assembled from different parts. There are some matches for "0x8600" and for "ff01", but I couldn't identify if these matches are relevant. I tried to find out if strace could help, but from what I understand, this is related to commands coming from userspace, so I am not sure that strace helps during the boot process. I'd appreciate it if somebody more knowledgeable would point me in the right direction. If more information is needed, I can provide it. I would search for the message 'Unhandled SMC/HVC' itself, or even for 'Unhandled', not for the address. The address is probably determined at runtime and not hardcoded. I sure those hex values aren't 'addresses' but the ID's for the secure monitor calls Paul already identified. Looking at the Linux sources I found the header for constructing these monitor calls: include/linux/arm-smccc.h So it might be worth looking at the files that include that. There are various drivers for firmware, and a watchdog driver amongst other things... drivers/watchdog/arm_smc_wdt.c That was spot on, I think. In include/linux/arm-smccc.h, the SMC calls are constructed, therefore it is not possible to find the IDs with a simple search in the sourcecode. (For completeness' sake: I also found out that Tianocore code is using the TRNG SMC call, but although Tianocore is being used for the boot process, I think that the linux code is more likely to be the cause of the above errors. [1]) The first ID 0x8450 is used for defining the constant ARM_SMCCC_TRNG_VERSION, the second ID 0x8600ff01 is used for the constant ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID. As suggested, I'll try to find relevant sourcecode that includes linux/arm-smccc.h. What's irritating me is that the whole problem only appears when having two VLANs and traffic on a VLAN. I assume this means that some code related to VLANs is relying on information from one of those calls and therefore fails when the call is not answered. Could that be plausible? Anyway, thank you for this information! [1] https://github.com/tianocore/edk2/blob/master/ArmPkg/Include/IndustryStandard/ArmStdSmc.h#L165
Re: Can't list root directory
On 2024-02-01 02:37, Loren M. Lang wrote: On January 31, 2024 1:28:37 PM PST, hw wrote: On Wed, 2024-01-31 at 09:27 -0500, Gary Dale wrote: On 2024-01-30 15:54, hw wrote: On Mon, 2024-01-29 at 11:42 -0500, Gary Dale wrote: I'm running Debian/Trixie on an AMD64 workstation. I've lost the ability to see the root directory even when I am logged in as root (su -). This has been happening intermittently for several months. I initially thought it might be related to failing NVME drive that was part of a RAID1 array that is mounted as "/" but I replaced the device and the problem is still happening. [...] What happens when you put the device you replaced back? How could putting a known-failing device back in help? The problem existed before I replaced it and continues to exist after the replacement. It sounded like you were able to list the root directory (at least sometimes) before you did the replacement. Manually failing the device (perhaps after adding it back first) could make a difference. I've seen such indefinite hangs only when an NFS share has become unreachable after it had been mounted. You could use clonezilla to make a copy and then perhaps convert the file system to btrfs. Do you still have the problem when you remove one of the NVME storage things? Perhaps you have the equivivalent of a bad SATA cable or the mainboard doesn't like it when you access two of those at the same time, or something like that. Even simple network cables can behave very strangely, and NVME may be a bit more complicated than that. Running fsck on every boot to work around an issue like this is certainly a bad idea. Doesn't fsck report anything? If it really makes a difference in itself rather than creating some side effect that leads to the root directory being readable, it should report something. Perhaps you need to increase its verbosity. If there's no report then it would look like a side effect and raise the question what side effect it might be. Does fsck run before the RAID has been brought up or after? Is the RAID up when booting is completed? What does mdadm say about the device(s)? Can you still list the root directory when you manually fail either drive? What exactly are the circumstances under which you can and not list the root directory? You need to do some investigating and ask questions like those ... Also, instead of doing "ls -l /" which will stat() every child folder under root, try "/bin/ls -f /" and see if that is successful. That will only do a readdir() on root itself. Also, it might be interesting to get a log of "strace ls -l /" to confirm exactly where the hang happens. -Loren Thanks loren. /bin/ls -l works. The strace shows the hang is on /keybase. The strace did a really bad hang - ctrlC wouldn't kill it. I've set the fsck count to 1 again, so I can reboot and take a look at it.
Re: MiniDLNA log file permission problem
On Sat, Feb 17 2024 at 01:34:05 PM, Lothar Braun wrote: > Hi, > > I'm debugging a permission problem with the log files created by > minidlna in /var/log/minidlna. I'm trying to use a different username > to run minidlna and do not use the default user account minidlna. The > problem is that log file /var/log/minidlna/minidlna.log is created > with the owner "minidlna" and does not belong to the user that runs > minidlna. > > I use the following configuration options: > > /etc/minidlna.conf > ... > user = myuser Change to /etc/minidlna.conf is not necessary. It only matters if minidlna is started as root and you want it to drop privileges. With the systemd unit starting it as myuser already, this will have no effect. > ... > log_dir=/var/log/minidlna/ # This directory belongs to the user myuser > ... > > /etc/default/minidlna: > ... > USER="myuser" > GROUP="myuser" > ... Change to /etc/default/minidlna is not necessary. These settings have no effect if using the systemd unit. > > /usr/lib/systemd/system/minidlna.service Don't modify the file in /usr/lib. Instead, run "systemctl edit minidlna.service" and put your "User" and "Group" changes there. This will create an override file in /etc that will be preserved when the minidlna package is upgraded. > ... > [Service] > User=myuser > Group=myuser > > ExecStart=/usr/sbin/minidlnad -f $CONFIGFILE -P /run/minidlna/minidlna.pid -S > $DAEMON_OPTS -u myuser > > The systemd module was loaded with systemctl daemon-reload. > > When I reboot the system, then the loading of minidlna fails because > someone (presumably minidlna) creates the file > /var/log/minidlna/minidlna.log with owner "minidlna" and not to the > user "myuser". Minidlna therefore fails to load and therefore quits > (lsof shows no process using /var/log/minidlna.conf). > > When I manually remove this logfile and run "systemctl restart minidlna" a > new file /var/log/minidlna.log is created with the owner "myuser" and > minidlna is working properly. > > So the problem only occurs when the system is rebooted. As systemd seems to > work properly when I manually run systemctl start minidlna.service, I'm not > sure if minidlna really creates the log file with the wrong username > > My questions: > > - Is there a way to determine who creates the log file that belongs to the > wrong user at boot? (I have no way to trigger this problem other than on boot) > - Is there any configuration option in minidlna that I did not see that I > have to change to successfully run minidlna as myuser? > minidlna installs a logrotate configuration that also refers to a user/group name. See /etc/logrotate.d/minidlna. -- regards, kushal
Re: MiniDLNA log file permission problem
On Sat, Feb 17, 2024 at 01:34:05PM +0100, Lothar Braun wrote: > I'm debugging a permission problem with the log files created by minidlna in > /var/log/minidlna. I'm trying to use a different username to run minidlna and > do not use the default user account minidlna. The problem is that log file > /var/log/minidlna/minidlna.log is created with the owner "minidlna" and does > not belong to the user that runs minidlna. unicorn:~$ apt-cache search minidlna minidlna - lightweight DLNA/UPnP-AV server targeted at embedded systems There's a Debian package with this name. Are you using that? If so, the Debian package's postinst script probably created the log directory. If you need the log directory to be owned by a different user, just chown it yourself.
Re: partition reporting full, but not
Keith Bainbridge wrote: ... > No nfs mounts any swap partition or swap space? but other than that sharing /home with / is likely your issue and you mention snapshots and backintime and i do recall that needing plenty of space. as for btrfs, i have no clue, i've never touched it. songbird
Re: Contact Name...
Hi, Clayton Penn wrote: > I have attempted to register for the Debian Forums, but have not received a > verification email Did you try wether your new account is already working ? (Sorry, i'm not familiar with the current registration procedure.) If not: There seems to be some problem with GMail: https://forums.debian.net/viewtopic.php?t=158230 Are you perhaps directly or indirectly using GMail ? > Do you happen to have another email address contact? I have an account at forums.debian.net, although not used in years. So if you want to add information to above topic, i could try to do so on your behalf. But first consider to try registering with a completely different mail provider which is surely not using GMail's software. Have a nice day :) Thomas
Contact Name...
Hello, First of all I would like to apologize for sending this message to your email address. I have attempted to register for the Debian Forums, but have not received a verification email: claytonbp thepennfamilyclay...@icloud.com I then attempted to contact the board administrator, however I have not received a reply. Do you happen to have another email address contact? Kind Regards, Clayton
Re: GRUB lost graphical terminal mode
On 2024-02-16, Borden wrote: > For a couple weeks now, I can't use graphical terminal in my GRUB > configuration. Setting `GRUB_TERMINAL=console` works fine. With that line > commented out, (thus using default settings), I get a blank screen on boot, 5 > second timeout, then normal boot. > > Curiously, keyboard commands work normally. Specifically, I'm on multi-boot > system, so I can boot into Windows by pressing the down arrow the correct > number of times and pressing Enter. So I suspect that GRUB is either sending > to the wrong video output or GRUB no longer supports my video card. > > Any way I can troubleshoot without setting set debug=all? Or perhaps you have all colors set to blank. Try add something like GRUB_COLOR_NORMAL="light-blue/black" GRUB_COLOR_HIGHLIGHT="light-cyan/blue"
Re: partition reporting full, but not
On 17/2/24 17:08, Felix Miata wrote: Keith Bainbridge composed on 2024-02-17 15:44 (UTC+1100): Yes the / partitions are btrfs df was not designed for the task you gave it. You need to use btrfs filesystem commands: https://btrfs.readthedocs.io/en/latest/btrfs-filesystem.html Seems I have some serious reading to do Thanks for thelink -- All the best Keith Bainbridge keith.bainbridge.3...@gmail.com +61 (0)447 667 468 UTC + 10:00
Of irrelevant chatter and meta-chatter [was: f3tools vs Silicon Power 4T drive]
On Sat, Feb 17, 2024 at 01:32:29AM -0500, Jeffrey Walton wrote: > On Sat, Feb 17, 2024 at 12:47 AM gene heskett wrote: [...] > > That part if the ^%$ drives ever get here, I just looked at the front > > deck and it has 2" of fresh white stuff on it. > > Lol... More irrelevant chatter [...] [rest of irrelevant meta-chatter elided] ...and you are amplifying exactly what you're criticising. Somehow this eminds one of DNS DDOS [1] attacks :-) Cheers [1] https://en.wikipedia.org/wiki/Denial-of-service_attack#Distributed_DoS_attack -- t signature.asc Description: PGP signature