Re: was I hacked?
On Thu, 14 Apr 2022, jgart wrote: What I not sure of is what path on my system to find the suspicious branch/git repo pulled down by `git/guix pull` so I can push it somewhere. In other words, where does `guix pull` clone the git repo to? ~/.cache/guix/checkouts ~/.cache/guix/authentication may be interesting as well. (I bet (hope?) it's actually XDG_CACHE_DIR/guix but you get the idea) Sorry I don't have insight in to what went wrong. Take care, Jack
Re: was I hacked?
On Thu, 14 Apr 2022 21:11:32 -0400 Christine Lemmer-Webber wrote: > It was for you. Since guix pull operates via a git pull, I think it > should be possible to figure out what the state of the previous branch > was when the weirdness occured. Got it. Thanks > In terms of where to push, you can push to pretty much any forge out > there. Notabug, Gitlab, etc etc etc. What I not sure of is what path on my system to find the suspicious branch/git repo pulled down by `git/guix pull` so I can push it somewhere. In other words, where does `guix pull` clone the git repo to? If you know off the top of your head it would be helpful otherwise I'll find some time to start digging around for it since I've never explored where exactly guix pull clones the git repo. I guess somewhere in the /gnu/store/...?
Re: was I hacked?
jgart writes: > On Thu, 14 Apr 2022 16:20:05 -0400 Christine Lemmer-Webber > wrote: >> It should be possible to use the git reflog to find out what your >> previous git history state was. >> >> It would be a good idea if you could push the "suspect" branch up >> somewhere where it can be examined, I'd think? > > Hi Christine, > > Was that request for me? > > If so, how would I push the suspect branch? > > All I did was a `git pull`. > > Unless you're implying that suspect branch is on my local machine somewhere? > > all best, > > jgart It was for you. Since guix pull operates via a git pull, I think it should be possible to figure out what the state of the previous branch was when the weirdness occured. In terms of where to push, you can push to pretty much any forge out there. Notabug, Gitlab, etc etc etc. Sorry I don't have time to say more. Currently sitting in the passenger seat on a road trip. I'm not sure if others in the Guix project see this as a priority, but if you say other users on IRC expereinced something similar, it may be good to investigate.
Re: was I hacked?
On Thu, 14 Apr 2022 16:20:05 -0400 Christine Lemmer-Webber wrote: > It should be possible to use the git reflog to find out what your > previous git history state was. > > It would be a good idea if you could push the "suspect" branch up > somewhere where it can be examined, I'd think? Hi Christine, Was that request for me? If so, how would I push the suspect branch? All I did was a `git pull`. Unless you're implying that suspect branch is on my local machine somewhere? all best, jgart
Re: was I hacked?
jgart writes: > On Thu, 14 Apr 2022 09:05:29 -0700 Vagrant Cascadian > wrote: >> Rolling back to an older generation and then moving forward basically >> would be a successfull (hopefully just accidental) attack changing the >> commit history! Rolling back to an older generation isn't much different >> than just blindly allowing to move forward to a different branch... > > That's a very good point that I only just thought of now after doing it ;() > >> Is it possible that one of your channels actually had the exact same >> commit in it, but then forked off in different directions? > > I don't have any other channel that is mirroring GNU Guix upstream. > >> It is rather unsettling to not know what happened... > > Yes, it is. I agree. > > Others have reported this issue on irc at #guix. > > See the logs. > > I think they just blindly used --allow-downgrades while I blindly rolled back > and forward > > Hopefully we find out what happened. > > all best, > > jgart It should be possible to use the git reflog to find out what your previous git history state was. It would be a good idea if you could push the "suspect" branch up somewhere where it can be examined, I'd think?
Re: was I hacked?
On Thu, 14 Apr 2022 09:05:29 -0700 Vagrant Cascadian wrote: > Rolling back to an older generation and then moving forward basically > would be a successfull (hopefully just accidental) attack changing the > commit history! Rolling back to an older generation isn't much different > than just blindly allowing to move forward to a different branch... That's a very good point that I only just thought of now after doing it ;() > Is it possible that one of your channels actually had the exact same > commit in it, but then forked off in different directions? I don't have any other channel that is mirroring GNU Guix upstream. > It is rather unsettling to not know what happened... Yes, it is. I agree. Others have reported this issue on irc at #guix. See the logs. I think they just blindly used --allow-downgrades while I blindly rolled back and forward Hopefully we find out what happened. all best, jgart
Re: was I hacked?
On 2022-04-14, jgart wrote: > On Thu, 14 Apr 2022 08:26:39 +0800 Feng Shu wrote: >> jgart writes: >> >> > On Wed, 13 Apr 2022 02:25:11 -0300 Thiago Jung Bauermann >> > wrote: >> >> I don't understand why Guix thinks that. IIUC 950f3e… is a direct >> >> descendant of 42679e… >> > >> > As of today now the has changed: >> > >> > ``` >> > λ guix pull >> > Updating channel 'guixrus' from Git repository at >> > 'https://git.sr.ht/~whereiseveryone/guixrus'...Updating channel 'nonguix' >> > from Git repository at 'https://gitlab.com/nonguix/nonguix'...Updating >> > channel 'guix' from Git repository at >> > 'https://git.savannah.gnu.org/git/guix.git'...guix pull: error: aborting >> > update of channel 'guix' to commit >> > 5743d505834a8b13778da2c969ea4e15bb7a3a75, which is not a descendant of >> > 42679e3f81a0fa61e225b1f6aa0e80e39625372f >> > hint: This could indicate that the channel has been tampered with and is >> > trying to force a roll-back, preventing you from getting the latest >> > updates. If you think this is not the case, explicitly allow non-forward >> > updates. >> > ``` >> > >> > I haven't allowed downgrades yet. >> > >> > Waiting to see if I get an answer first on why it's happening. >> >> Why not roll-back to an older guix, then try guix pull again? > > Hi Feng, > > Thanks! that worked!!! > > I rolled back one generation and ran `guix pull`. That still does leave me wonder what the deal was... Was the repository tampered with? Rolling back to an older generation and then moving forward basically would be a successfull (hopefully just accidental) attack changing the commit history! Rolling back to an older generation isn't much different than just blindly allowing to move forward to a different branch... Is it possible that one of your channels actually had the exact same commit in it, but then forked off in different directions? It is rather unsettling to not know what happened... live well, vagrant signature.asc Description: PGP signature
Re: Kernel panic on new machine
On Thu, 14 Apr 2022 07:47:47 + phodina wrote: > Hi, > > > This is a Guix init issue, not "really" a kernel panic. As you can > > see, there is some kind of error in the Scheme code being run at > > boot time, but instead of being dropped into a debug shell, it > > exits, which causes the kernel to panic. > > This is because Guile is running as PID 1, that is, it is the first > > process the kernel starts. PID 1 is kinda special and AFAIK it is > > not allowed to exit, ever. Otherwise you get that panic. > > yes, I know Guix init process exiting and due to being PID 1 kernel > panics. > > In the meantime I reinstalled Guix again and it booted correctly, no > idea what caused it. > > > However, my question was/still is how to fix this? Also is there a > way to determine what caused this? Is there a way to launch the debug > shell instead of exiting? > > PS: Sorry for the image spam but it appeared that the image was not > posted the first time so I tried also sending a smaller image > > Petr > Maybe you could boot that system profile in QEMU. It looks like it is trying to open a debug shell but failing, so... not sure what you could do in that case if you are on bare metal. At least on QEMU you might be able to generate some kind of core dump or attach gdb to it or something.
Re: CJK font issues on GDM screen
Taiju HIGASHI writes: The problem is that gdm can not find a CJK fonts. you can try: (modify-services %desktop-services (gdm-service-type config => (gdm-configuration (inherit config) (gnome-shell-assets (list adwaita-icon-theme ;; the below is a CJK font font-wqy-microhei) Maybe we should add an example to guix document. > Hi, > > I am not currently having trouble, but I do have one question. > > I have had trouble displaying CJK fonts on the GDM screen. > > I have followed the steps below to install Guix initially, which > allows me to temporarily display CJK fonts on the GDM screen. > > 1. Specify `ja_JP.utf8` as locale on the graphical installation screen. > 2. Set CJK fonts to be installed globally. > 3. Execute the installation. > > However, if I run `guix system reconfigure` after this, I cannot see > the CJK fonts on the GDM screen. (The letters will be tofu.) > > I asked on #guix on IRC and was given a solution, so I am not > troubled, but the following questions remain. > > https://logs.guix.gnu.org/guix/2022-04-09.log#174359 > > 1. Why do I see CJK fonts on the GDM screen after setting the locale > and installing CJK fonts during the initial installation? > 2. Why can't I see CJK fonts on the GDM screen after running `guix > system reconfigure`? > > Is there a special process to generate a font cache during initial > installation? > Also, is that process absent when the system is reconfigured? > > I feel that it would be desirable for the system to behave the same > when reconfigured as when initially installed. > > Thank you. --
Standard fonts not shown by xpdf
Hello, after updating my system a few weeks ago, the standard fonts are left blank when showing pdf files with xpdf (while they appear with evince and okular). I currently have the following fonts installed: font-ghostscript font-dejavu font-gnu-freefont font-linuxlibertine font-gnu-unifont I have already run "fc-cache -vf" to no avail. Does anyone have an idea on what to do? Thanks for your help, Andreas
Re: Kernel panic on new machine
Hi, > This is a Guix init issue, not "really" a kernel panic. As you can see, > there is some kind of error in the Scheme code being run at boot time, > but instead of being dropped into a debug shell, it exits, which causes > the kernel to panic. > This is because Guile is running as PID 1, that is, it is the first > process the kernel starts. PID 1 is kinda special and AFAIK it is not > allowed to exit, ever. Otherwise you get that panic. yes, I know Guix init process exiting and due to being PID 1 kernel panics. In the meantime I reinstalled Guix again and it booted correctly, no idea what caused it. However, my question was/still is how to fix this? Also is there a way to determine what caused this? Is there a way to launch the debug shell instead of exiting? PS: Sorry for the image spam but it appeared that the image was not posted the first time so I tried also sending a smaller image Petr
Re: CJK font issues on GDM screen
Taiju HIGASHI writes: > I knew it. > I know there are not many Guix users in Japan, but I was wondering how other > languages users are solving this problem. > Is this problem that does not occur with SLiM? I do not know, slim just show English, do not use CJK. > > > On April 14, 2022 9:23:11 AM GMT+09:00, Feng Shu wrote: >>Taiju HIGASHI writes: >> >>> Hi, >>> >>> I am not currently having trouble, but I do have one question. >>> >>> I have had trouble displaying CJK fonts on the GDM screen. >>> >>> I have followed the steps below to install Guix initially, which >>> allows me to temporarily display CJK fonts on the GDM screen. >>> >>> 1. Specify `ja_JP.utf8` as locale on the graphical installation screen. >>> 2. Set CJK fonts to be installed globally. >>> 3. Execute the installation. >>> >>> However, if I run `guix system reconfigure` after this, I cannot see >>> the CJK fonts on the GDM screen. (The letters will be tofu.) >> >>I have faced the same problem, so I have switched to use slim, which >>*only* show English, so have no this problem :-\ >> >>> >>> I asked on #guix on IRC and was given a solution, so I am not >>> troubled, but the following questions remain. >>> >>> https://logs.guix.gnu.org/guix/2022-04-09.log#174359>> >>> 1. Why do I see CJK fonts on the GDM screen after setting the locale >>> and installing CJK fonts during the initial installation? >>> 2. Why can't I see CJK fonts on the GDM screen after running `guix >>> system reconfigure`? >>> >>> Is there a special process to generate a font cache during initial >>> installation? >>> Also, is that process absent when the system is reconfigured? >>> >>> I feel that it would be desirable for the system to behave the same >>> when reconfigured as when initially installed. >>> >>> Thank you. >> --
