[01:39] <kadiro> hello
[01:41] <kadiro> I want help about lirc
[14:02] <djtravz> Hello, I am doing a new installation of xubuntu and installing windows alongside. I can't resize the partition more than 32 mb. Why is this?
[14:04] <diogenes_> djtravz, first install win then xubuntu
[14:05] <djtravz> I will need to resize the partitions after I install windows
[14:05] <djtravz> So I want to make sure that I can before I go through with too much effort in installation
[14:07] <diogenes_> install win the from win with the help of easeus partition manager create free space.
[14:09] <djtravz> Once I have them both installed, if I need more space in either one of them I want to make sure that I can still resize both of their partitions
[16:18] <hans_> got an old computer from 2005 running 17.10, a couple of months ago an update made the start menu and desktop icons disappear
[16:19] <hans_> i tested 18.04 in live, and 18.04 is also affected
[16:19] <hans_> it's running an ancient nvidia GPU, i tested both the nvidia legacy gpu driver and the X-org driver, didn't make a difference
[16:21] <diogenes_> hans_, and the question is?
[16:21] <hans_> any idea how to make the start-menu visible again?
[16:22] <hans_> (and the desktop icons)
[16:22] <diogenes_> by start menu you mean whisker menu?
[16:22] <hans_> sure, the 1 that opens when you press the windows button
[16:23] <diogenes_> right click on the panel > panel > add new item and look for whisker menu there
[16:23] <hans_> https://i.imgur.com/LvpgAmD.png
[16:24] <hans_> its configured, it's there according to the panel configuration thing
[16:24] <hans_> ... but it's not visible
[16:24] <hans_> i guess it crash while attempting to start or something
[16:24] <diogenes_> in terminal run: sudo apt intstall -f
[16:25] <hans_> 0 everything, 0 to update 0 errors ~
[16:26] <diogenes_> then you got no broken packages, i's assume it's some misconfigs and a good start would be if you create a new user and login as the new use and see if everything works there.
[16:27] <hans_> i don't think that will make a difference as the xubuntu live system was also affected, but ok i will check
[16:28] <diogenes_> i've never had a problem with the live system.
[16:28] <hans_> ok i made a new user and logged in, same issue.
[16:28] <hans_> (did n't
[16:28] <hans_> (didn't make a difference)
[16:29] <brainwash> share your ~/.xsession-errors log file via a pastebin service
[16:31] <hans_> https://paste.ubuntu.com/p/Q524SCWm5G/
[16:31] <hans_> (that's from the brand new user, first time login)
[16:34] <brainwash> is xfce4-panel running as process? or xfdesktop
[16:35] <hans_> yes both of them, according to ps -A | grep -i xfce4
[16:35] <hans_> both of them are running
[16:38] <brainwash> ohh. the panel should be running, you only miss the menu.
[16:38] <brainwash> those wrapper-2.0 entries in the log file are related to whiskermenu
[16:38] <hans_> (i miss the desktop icons as well)
[16:39] <brainwash> desktop icons are handled by xfdesktop
[16:39] <brainwash> open a terminal window and run "killall xfdesktop; xfdesktop"
[16:39] <brainwash> see if that gives any output
[16:40] <hans_> as root or as logged in user?
[16:40] <brainwash> as user
[16:41] <brainwash> you can try with xfdesktop --enable-debug  too
[16:41] <brainwash> that will print additional debug output
[16:41] <hans_> error: no protocol specified
[16:41] <hans_> (without --enable-debug)
[16:41] <hans_> it said more than that but the rest is localized to norwegian
[16:41] <hans_> .. should i try to translate that back to english?
[16:42] <hans_> roughly translated: could not understand the arguments: could not open the screen
[16:43] <brainwash> for that you can use LC_ALL=C
[16:44] <brainwash> like this: LC_ALL=C xfdesktop
[16:44] <hans_> set that as an enviorment variable before starting xfdesktop?
[16:44] <brainwash> or export it beforehand
[16:44] <hans_> kk
[16:47] <hans_> now it said (xfdesktop:2679): Gtk-WARNING **: Locale not supported by C library. \n Using the fallback 'C' locale. \n Failed to parse arguments: Cannot open display: (blank, but i get the feeling that it would put a display name/identifier here if it had 1)
[16:47] <hans_> oh sorry
[16:47] <hans_> i forgot a line
[16:48] <hans_> it also said: No protocol Specified
[16:48] <brainwash> mmh
[16:48] <hans_> on the line before it said "Failed to parse arguments"
[16:48] <brainwash> can you make it work by specifying the display?
[16:48] <brainwash> DISPLAY=:0 xfdesktop
[16:49] <hans_> yup
[16:49] <hans_> now it started but gave a lot of errors (but still running)
[16:50] <brainwash> errors or just warning?
[16:50] <brainwash> warnings
[16:51] <brainwash> I think xfdesktop tends to print quite some theming related warnings
[16:51] <hans_> https://paste.ubuntu.com/p/sQQrtWDcNn/
[16:52] <hans_> that's what i got (but it's still running)
[16:53] <brainwash> I guess the next step would be to see what the xfce settings daemon does
[16:53] <brainwash> XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon
[16:54] <brainwash> it's responsible for setting up the environment
[16:55] <hans_> sorry busy a bit, checking if Lubuntu 18.10 is affected
[16:55] <brainwash> lubuntu?
[16:55] <hans_> yes, much like Xubuntu it's an ubuntu-based distro based on... LXDE, iirc
[16:56] <hans_> (its
[16:56] <brainwash> I know that
[16:56] <brainwash> but why not check with xubuntu 18.10 or 19.04 (dev)?
[17:00] <hans_> because now i know that it's not XFCE-specific and not Xubuntu-specific: original Xubuntu 17.10 is not affected, fully up-to-date 17.10 is affected, Xubuntu 18.04 is affected, and Lubuntu 18.10 is affected
[17:03] <brainwash> probably not that easy to go back and try to reproduce the bug again
[17:03] <brainwash> as 17.10 is not supported anymore
[17:03] <hans_> right, but 18.04 is also affeccted
[17:03] <hans_> is Xubuntu 16.04 supported?
[17:04] <brainwash> the update history of the 17.10 installation could be useful
[17:05] <brainwash> Xubuntu 16.04 is supported for 3 years
[17:06] <hans_> meaning support ended like a couple of days ago?
[17:06] <brainwash> pretty much I would guess
[17:06] <brainwash> the Ubuntu core (main repository) has support for 5 years
[17:08] <brainwash> so, you need to somehow pinpoint the update which breaks the desktop
[17:09] <brainwash> also, the output of this command may give a hint:
[17:09] <brainwash> XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon
[17:11] <brainwash> update history is located in /var/log/apt/
[17:11] <brainwash> if still present
[17:12] <hans_> is it normal that it use a long time to execute? xfsettingsd
[17:12] <hans_> it has printed a lot of info but then just kinda froze
[17:12] <hans_> still running but not outputting anything
[17:15] <hans_> here is what it has printed so far, but it's still running: http://paste.ubuntu.com/p/rHM2xX5n2B/
[17:16] <brainwash> it should keep running
[17:17] <brainwash> can you start xfdesktop now from another terminal window?
[17:17] <brainwash> without DISPLAY
[17:18] <brainwash> killall xfdesktop; xfdesktop
[17:19] <hans_> in the middle of a reboot but once it starts, sure
[17:20] <brainwash> I mean after starting xfsettingsd manually
[17:20] <brainwash> it seemed to launch fine according to the output
[17:20] <hans_> yup will do
[17:21] <brainwash> with that I assume that xfdesktop should launch without issues also
[17:23] <hans_> got no output when running xfdesktop
[17:23] <hans_> i assume it daemonized
[17:23] <hans_> yup its running in the background
[17:24] <brainwash> with icons visible?
[17:25] <hans_> no
[17:25] <hans_> icons are still invisible
[17:25] <hans_>  / not present
[17:25] <brainwash> maybe another
[17:25] <brainwash> killall xfdesktop; xfdesktop
[17:27] <hans_> i added -w to that command, but nothing
[17:27] <hans_> no output and no icons
[17:27] <hans_> (i have confirmed with thunar that there is a text file on the desktop that should be a dedicated icon, if nothing else)
[17:28] <hans_> (thunar can see the files there as it should, when running thunar from the terminal)
[17:30] <hans_> btw a long time ago i learned that as a general rule of thumb, it's a good habit to add -w to your killall command, because by default killall does not wait until it's actually dead, that's what the -w flag does, and commands like `killall xfdesktop; xfdesktop` may try to start a new instance of xfdesktop before the previous has exited
[17:32] <hans_> (reminds me of "avoiding race conditions" in multithreaded programs :p)
[17:32] <brainwash> not really sure what to suggest at this point
[17:33] <brainwash> any luck with checking the update history?
[17:33] <brainwash> 17.10 is dead, so it's not easy to check for changes online
[17:33] <brainwash> as info about that release has been removed mostly
[17:36] <brainwash> other than that, you could do some testing with a different distribution
[17:37] <brainwash> you mentioned that the computer is from 2005
[17:40] <hans_> |-/var/log/apt/term.log: text/plain: https://paste.fedoraproject.org/paste/TIMQhYSyRG7lQ8j2ATvXhA/raw?password=FmzCPPTd1FESETA82_zv
[17:40] <hans_> |-/var/log/apt/history.log: text/plain: https://paste.fedoraproject.org/paste/2YBhC~dq7OqCy3ba2NKy2A/raw?password=iFdnhC6RkoKWRO05GiIz
[17:41] <hans_> here is a list of everything in the folder but with a lot of noise.. i can decompress everything if there's interest: https://paste.fedoraproject.org/paste/owozYhTHLDyctYJtEaMKoA/raw?password=-mW7Op8iqY4JKY37x2Ck&fbclid=IwAR3-KlfQOLk-pL_ZjtTM-dJMQIOOAjEoMUjlqx7dMX8yHMz-u5gyfUxxeCM
[17:41] <hans_> but..
[17:42] <hans_> both of those logs on show stuff after the problem occured, i have to decompress the other stuff and maybe it's in there
[17:42] <hans_> (logs from when the problem ocurred)
[17:42] <brainwash> indeed
[17:42] <brainwash> 2019-04-14
[17:42] <brainwash> that's not relevant
[17:43] <hans_> .. is there a command to just decompress every .gz file in a folder?
[17:43] <gnrp> hans_: `for file in *.gz; do gunzip "${file}"; done`
[17:43] <gnrp> ur `gunzip *.gz` should also work, I see...
[17:44] <brainwash> 17.10 was supported until july 2018
[17:45] <brainwash> that should be the last date for updates
[17:46] <brainwash> you installed a bunch of remaining updates today
[17:46] <brainwash> so, when was the last time you applied updates?
[17:47] <brainwash> I would assume before july 2018
[17:56] <hans_> yeah i installed all remaining updates today, hoping that would fix everything; it didn't
[17:57] <hans_> here is links to most of the logs if anyone is curious, but i cba atm, testing if debian is affected. https://paste.fedoraproject.org/paste/IGOUTuG37a3enuS8t2-~xw/raw?password=sXcjp3c7aefDTRx476H4&fbclid=IwAR2oe2ZH9Cdvv2oJalQZ-cMYxJUwbBAwfaQCVJF8Dd2l6NuE9DEccyKEABs
[18:03] <brainwash> history.log.1 2018-11-17
[18:04] <brainwash> the first thing I would try it to boot with an older kernel version
[18:04] <brainwash> from the grub boot menu
[18:05] <hans_> i will try that, it has a lot of older kernels unpurged
[18:05] <hans_> but right now it's busy resizing the ext4 partition
[18:07] <hans_> (.. to be fair, it said "this operation may take a long time, are you sure?")
[18:08] <brainwash> okay
[18:08] <brainwash> but why do that while still debugging the problem?
[18:11] <hans_> because i'm making a dedicated partition for a debian installation to see if debian is also affected. i was probably stupid to not just try the debian-live system, but i couldn't find a live-version of the "non-free/cd-including-firmware/"-builds of debian and.. stuff
[18:13] <hans_> ok the resize is finished and i aborted the installation and booted back to xubuntu, but it's either set to hide the ask-for-kernel-menu (yes, it's an option to hide the menu while still having a countdown, and on some ubuntu distros that's even the default behaviour, which i find.. stupid), or it's set to 0-second-timeout (instant boot without asking), i'm not sure which yet
[18:14] <brainwash> you have to press Shift after the BIOS phase
[18:14] <hans_> Shift, gotcha
[18:14] <brainwash> well, hold it
[18:15] <hans_> great now it asked me
[18:16] <hans_> got -16 -17 -19 -21 -25 -32 -39 -46
[18:16] <hans_> before that they are all 4.13.0-
[18:16] <hans_> and after that they are all -generic then 50% of them are (recovery mode)
[18:16] <hans_> guess i should just try -16 then?
[18:16] <brainwash> -46 was installed on 2018-11-17
[18:17] <brainwash> should be the one that potentially broke the desktop
[18:18] <brainwash> furthermore, intel-microcode was pulled in on that day too
[18:18] <hans_> that could be related, it has an intel cpu iirc (don't remember which)
[18:19] <hans_> Intel Core 2 6300 @ 1.86GHz according to /proc/cpuinfo
[18:21] <brainwash> removing intel-microcode may be something worth testing also
[18:21] <hans_> oddly the reboot sequence got noticably slower after the partition resize
[18:22] <hans_> (i didn't remove space from the start, i removed space from the end of the partition)
[18:22] <brainwash> I think it was added automatically in 2018 due to the recent intel vulnerabilities
[18:22] <brainwash> but that CPU is way too old for any new patches anyway
[18:23] <hans_> uhm
[18:23] <brainwash> does the older kernel make the desktop work?
[18:25] <hans_> is this a bad time to add that i added "nokaslr nopti" to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub a long time ago? (long before the desktop broke)
[18:26] <brainwash> not quite sure what those two change
[18:26] <hans_> take away some of the overhead of the KAISER/SPECTRE mitigations, iirc
[18:26] <hans_> .. but is unsafe
[18:27] <hans_> (as in, makes it easier for a hacker trying to exploit those vulnerabilities)
[18:27] <brainwash> but for that mitigation to have any effect you would need the proper cpu firmware, no?
[18:28] <hans_> i think they're software solutions to hardware problems, unrelated to firmware
[18:28] <hans_> anyway, both the -16 kernel and the -39 kernel are affected still, they make no difference :(
[18:28] <kadiro> hello, I need to install an old kernel ( ex 4.8 ) but apt-cache gives me only 4.15 and so
[18:28] <hans_> brainwash, should i try `apt remove intel-microcode` ?
[18:28] <hans_> (and reboot?)
[18:29] <brainwash> hans_: sure. it's possible that the initramfs for -16 was updated to include the new microcode.
[18:29] <brainwash> but it would be pretty odd if that's the reason for the breakage
[18:30] <hans_> running that it wants to also remove linux-generic and linux-image-generic
[18:30] <brainwash> indeed
[18:30] <hans_> "the following additional blah blah"
[18:30] <hans_> should i continue?
[18:30] <brainwash> it's a new dependency
[18:30] <brainwash> you can reinstall linux-generic and linux-image-generic later
[18:30] <brainwash> those are meta packages
[18:30] <hans_> kk
[18:30] <hans_> ok i removed them, should i reboot now or
[18:31] <brainwash> right
[18:31] <brainwash> kadiro: why do you need 4.8?
[18:31] <hans_> i also removed the custom kernel boot options (on the basis that, as non-default configurations they're probably less tested)
[18:31] <kadiro> brainwash, for a specific module that was working but the new kernel replaced it
[18:32] <hans_> kadiro, named?
[18:32] <kadiro> hans_, lirc_serial was replaced with serial_ir
[18:33] <brainwash> I don't think that using an unsupported kernel version is the way to go
[18:34] <hans_> brainwash, come to think of it, the nopti option is automatically applied if the kernel bugs flags say they don't need it, iirc
[18:34] <kadiro> brainwash, the problem that i fellow all the guides, docs, helps without success
[18:34] <hans_> .. removing intel-microcode and the custom boot options did nothing, problem is still present :(
[18:34] <kadiro> i tried ir-keytable to replace lirc but nothing happen
[18:34] <hans_> brainwash, kernel cpu bugs flags*
[18:35] <hans_> ok, i guess i should go back to the debian test?
[18:35] <brainwash> probably
[18:36] <kadiro> I was thinking that my remote control is no longer work but the command mode2 still gives result also cat /dev/lirc0 and using my remote gives output and tested on windows just work out of a box
[18:37] <kadiro> I lost my mind
[18:37] <brainwash> you probably need to contact the module devs
[18:38] <brainwash> installing 4.8 in ubuntu 18.04 may be possible, but it may be a bad idea
[18:39] <brainwash> especially when you have that system connected to the internet
[18:39] <kadiro> yeah i know that but i have no choice
[18:40] <kadiro> 3 days without sleep trying to solve that problem and still no success
[18:40] <kadiro> thank you brainwash for your help
[18:42] <kadiro> In the docs they say that the new kernels can talk directly with any devices using ir-keytable but i can't make it happen
[18:44] <brainwash> kadiro: did you find this? https://ubuntuforums.org/showthread.php?t=2403337
[18:46] <kadiro> brainwash, yes i did
[19:26] <hans_> brainwash, in case you're curious, Debian 9.8 with xfce desktop was also affected
[19:27] <brainwash> kernel version?
[19:28] <hans_> is there some easy-ish way to check from the kernel?
[19:28] <hans_> err, check from the iso*
[19:28] <brainwash> internet says 4.9
[19:30] <hans_> probably correct
[19:30] <hans_> found references to Package: btrfs-modules-4.9.0-8-686-di
[19:30] <hans_> in the iso
[19:30] <hans_> so 4.9 yeah
[19:31] <hans_> ok found this in the iso: Depends: kernel-image-4.9.0-8-686-di, crc-modules-4.9.0-8-686-di, md-modules-4.9.0-8-686-di
[19:33] <brainwash> not sure how much more time you want to invest into this
[19:33] <brainwash> you could test with a non debian based distro
[19:33] <brainwash> or with something from before 2018
[19:34] <brainwash> and then apply updates step by step
[20:51] <KernelP8901> Morning/Evening All. I have a Atom Intel stick. It's a 32 bit UEFI and a 64bit CPU. I managed to get the OS to live boot by adding the 32bit EFI files to the USB however it's failing to install grub during the install process. I have manually added pool\main\g\grub2\grub-efi-ia32_2.02+dfsg1-5ubuntu8_i386 to try and resolve the issue but installer fails. Any ideas/advice on how to get this installed? Thanks :)
[21:02] <hans_> you're installing ubuntu to a usb stick?
[21:02] <hans_> (well, xubuntu)
[21:02] <hans_> KernelP8901, ^
[21:02] <KernelP8901> @hans_ from
[21:03] <KernelP8901> Install media is USB and storage is EMMC
[21:04] <hans_> have you tried 32bit xubuntu btw? does that install cleanly? (xubuntu still has 32bit systems)
[21:05] <hans_> (probabky not what you want but it'd still be interesting)
[21:06] <KernelP8901> That's the ISO I was using. I am now trying the AMD64 Xubuntu Beta (19.04) and this time I was lucky enough to find my USB3 to HDMI, VGA, Ethernet, USB 2.0 adapter so it can get online and download packages not included in the ISO