View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004239 | Kali Linux | [All Projects] Kali Package Bug | public | 2017-09-11 10:39 | 2020-12-01 10:48 |
| Reporter | vanguard | Assigned To | rhertzog | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 2017.1 | ||||
| Target Version | Fixed in Version | 2017.2 | |||
| Summary | 0004239: kali-live: LXDE - many problems with X, language environment, boot | ||||
| Description | Dear maintainers, I am regulary building kali-linux live for LXDE. The build is done in an actual kali environt. Live-build is always up-to-date. Note, that I build or German environment. It should not be dangerous, to add a list of additional packages. Also, I use apt-cacher-ng, which also should not be a problem. The problems: 1. The boot hangs, when starting X. Lightdm is eating 100 percent cpu, but this is not a problem with lightdm, as sddm or kdm do the same. Please see for thius behaviour bug 0008114. 2. Before last build, when entering password or username in lwindow-manager, the German keyboard is not used, although it is shown, that UTF-8 is active. (ie.the letter z and y are exchenged) 3. After the last build, additionally it iis no more possible to enter passwort and username into lightdm. This means, keyboard isno more recognized. So, latest build is no more usable again, and I believe, there is a big bug in some of packages. The command, I am building kali live is the followinng: ./build.sh --arch i386 --distribution kali-rolling --variant lxde --verbose -- --apt-http-proxy http://localhost:3142/ --bootappend-live "boot=live noconfig=sudo username=root hostname=kali ignore_uuid locales=de_DE.UTF-8 keyboard-layouts=de keyboard-variants=nodeadkeys" This always worked very well. The strange thing is: using the same command for buildding with XFCE., X starts fine (axcept of the keyboard misconfiguration). However, I prefer LXDE mostly, as it is much faster and more comfortable on my EEEPC. Please note, that I wanted to try a prebuild lkali-ive from your website, but I could only find your build on 64-bit, not on 32-bit. Hope it helps, please ask for miore information. Thank you very much. Best Hans | ||||
|
|
You have already filed 0004118. Is this something different really? Yes we are only building amd64 images for alternate desktops. Please stop reporting multiple issues in a single ticket. Go read https://kali.training/chapter-6/filing-a-good-bug-report/ please. |
|
|
Hi Raphael, yes, it looks liker 0004118, and maybe it is the same cause. But the described problems in this bug are new (i.e. no keyboard input). IMO there may be different bugs (however, I can not prove it). When I could have been able, zto find the cause for the bug, I qwould not have opened a new one. However, I guess, the new bug withe the "wronbg language keyboard environment" and the "missing ability of keyboard input at all", mihght be another cause than the one described at bug0004118. So this is the reason for the new bugreport. Maybe all bugs are caused by ONE package, both bugreports can be closed. On the other hand, if we found ONE reason for BOTH bugreports, we can merge both bugreports. What do you think, we should do? Best regards Hans P.S. I sent the packages list as you requested on 0008114. |
|
|
Hi, I just built a new livefile (as usual) and most things are working now. So, as this bugreport is also related to bug 0004118, I recommended that one as closed. However, there is still the problem with the wrong keyboard layout in X (should be German but is still US). In console (tty1-6) the German keyboard environment/layout is working, but still not oin X. So please let this bugreport open. Just a hint: This problem appeared already some months ago (bug ßßß3849), filed by me and fixed by rhertzog. Maybe the same cause appeared again? Thanks for your help. Best regards Hans |
|
|
So, some more information. IMHO it looks like some relation to live-build. I checked all related configurations in the livefile and they look ok. Then I did the following command (as told in the xorg documentation), without changing anything: udevadm trigger --subsystem-match=input --action=change started lightdm again and - voila, keyboard input is in German. So I think, that something is not configured correctly during the build in live-build. Sorry that I am not enough experienced with live-build, and I have no clue, where to oo at. Are these this "hooks", which are configuring this? Do not now, and the dokumentation of ive-buid does it not make clear enough for me. Maybe this report helps, and maybe this thing can easily be fixed. Please drop me a note, if you think, you fixed this issue, I will then build a new one for testing. Best regards Hans |
|
|
Thank you, this is useful information. Please test the attached live-config_5.20170830_all.deb by putting it in kali-config/common/config/packages.chroot/ (it must be in config/packages.chroot at the time of the build) live-config_5.20170830_all.deb (33,202 bytes) |
|
|
Hi Raphael, I did as you advised, and it is working now perfectly. This bug can safely be closed now, many, many thanks! Maybe you can answer me some questions with closing this bugreport? 1. I suppose, you will upload a ne live-build to the repo. As usual I am starting kali-live system which is alwáys the latest build I did. Then I upgrade the live system and make sure, all needed packages are installed. This upgrades the latest live-build from the repo, too. Do I need the live-build package in ~/config/packages.chroot any more at next build? 2. I asked some time before, but stillgot no answer: Why does kali recommend the command "./build.sh *****" instead of using "lb config" and "lb build" as it is everywhere recommended in the live-build docu? 3. Can I build with several windowmanagers like XFCE and LXDE at one build and what is the syntax? "--variant lxde,xfce" or "--variant lxde --variant xfce"? (same question for amd64 and i386) 4. I wondered,why the metapackage "kali-forensics-*" does not include "forensics-full", which includes a lot of valuable tools. Does it make the ISO too big? (+890MB) Thank you for any answers, and again thank you for fixing this bug. As I said above, this bugreport can be safely closed. |
|
|
I was too fast and forgot: Best regards and happy hacking Hans :-) |
|
|
1. I uploaded live-config 5.20170914 to Debian and will import it to Kali later. (it's live-config, not live-build, which matters here). Keep the package in packages.chroot until you see the newer package in Kali. 2. Because we have our own machinery to handle different profiles. Our build.sh calls lb config and lb build after having setup the appropriate files. 3. No. 4. Because forensics-full is not really a curated meta-package and contains too many things that we would not categorize as forensics tools. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-09-11 10:39 | vanguard | New Issue | |
| 2017-09-11 12:15 | rhertzog | Note Added: 0007291 | |
| 2017-09-11 18:04 | vanguard | Note Added: 0007296 | |
| 2017-09-12 15:28 | vanguard | Note Added: 0007303 | |
| 2017-09-13 18:55 | vanguard | Note Added: 0007311 | |
| 2017-09-14 05:25 | rhertzog | File Added: live-config_5.20170830_all.deb | |
| 2017-09-14 05:25 | rhertzog | Note Added: 0007312 | |
| 2017-09-14 05:25 | rhertzog | Assigned To | => rhertzog |
| 2017-09-14 05:25 | rhertzog | Status | new => assigned |
| 2017-09-14 12:27 | vanguard | Note Added: 0007318 | |
| 2017-09-14 12:28 | vanguard | Note Added: 0007319 | |
| 2017-09-14 13:06 | rhertzog | Note Added: 0007320 | |
| 2017-09-14 13:07 | rhertzog | Status | assigned => resolved |
| 2017-09-14 13:07 | rhertzog | Resolution | open => fixed |
| 2017-09-14 13:07 | rhertzog | Fixed in Version | => 2017.2 |
| 2020-12-01 10:48 | g0tmi1k | Priority | high => normal |