Maui Forums
[SOLVED] - Major Maui Meltdown. - Printable Version

+- Maui Forums (https://forums.mauilinux.org)
+-- Forum: Maui Support (https://forums.mauilinux.org/forumdisplay.php?fid=74)
+--- Forum: Plasma Desktop (https://forums.mauilinux.org/forumdisplay.php?fid=84)
+--- Thread: [SOLVED] - Major Maui Meltdown. (/showthread.php?tid=24099)

Pages: 1 2 3 4 5 6 7

RE: Major Maui Meltdown. - kdemeoz - 12th November 2016

Hi fanisatt. No i have no other "real" OS [not Linux or anything else] installed directly on either my SSD [= location of Maui & /home] or HDD [= other data, including LOTS of VMs]. I do have many Linux distros in those VMs, but obviously that's irrelevant to your suggestion.

Given that i can't solve this problem, & the kindly help of Mods, Admins & other Users has also been unable to solve it, i would be willing to experiment with installing another Linux distro [maybe Linux Lite] for a dual-boot option, to test your idea.

I've never before setup a dual-boot Linux pc, so i will need to take the time to research it (i do not want to destroy either my Maui or my data, of course]. Ideally i would want the new Linux to be able to access all my existing data, in Maui's /home, + on the HDD. My /home is encrypted [with ecryptfs, from installation], so one of the many things i yet don't know is if installing the 2nd Linux would give me the option to use [& not format, obviously] the existing /home, & if then the data would be accessible.  I also don't yet understand if multiple distros each writing their config info into a common /home might create a disaster of conflicts & damage, or be entirely safe. These questions might be basic to people more skilled in Linux than me, but as i don't yet know, i need to not rush into this but research it all first.

Thanks again.

RE: Major Maui Meltdown. - fanisatt - 12th November 2016

(12th November 2016, 9:49)kdemeoz Wrote: Hi fanisatt. No i have no other "real" OS [not Linux or anything else] installed directly on either my SSD [= location of Maui & /home] or HDD [= other data, including LOTS of VMs]. I do have many Linux distros in those VMs, but obviously that's irrelevant to your suggestion.

Given that i can't solve this problem, & the kindly help of Mods, Admins & other Users has also been unable to solve it, i would be willing to experiment with installing another Linux distro [maybe Linux Lite] for a dual-boot option, to test your idea.

I've never before setup a dual-boot Linux pc, so i will need to take the time to research it (i do not want to destroy either my Maui or my data, of course]. Ideally i would want the new Linux to be able to access all my existing data, in Maui's /home, + on the HDD. My /home is encrypted [with ecryptfs, from installation], so one of the many things i yet don't know is if installing the 2nd Linux would give me the option to use [& not format, obviously] the existing /home, & if then the data would be accessible.  I also don't yet understand if multiple distros each writing their config info into a common /home might create a disaster of conflicts & damage, or be entirely safe. These questions might be basic to people more skilled in Linux than me, but as i don't yet know, i need to not rush into this but research it all first.

Thanks again.
Your welcome kdemeoz ! I used to keep two different Linux OSs in two different hard disks or SSDs (it is a very simple installation) and I keep all my DATA in other different partitions of the OSs. I don't really use a common HOME partition because, I had problems in the past and I wanted every time a really clean and safe installation of any new OS with my DATA in a different and safe place too. So, if any software problem occurs to the first OS I can easily and immediately work with the second one , except there is a common hardware problem. I don't use encrypted partitions and I can't help you with this. I wish I could help you on your specific MAUI problem but I am only a simple user . Happy Saturday !
 

RE: Major Maui Meltdown. - rocky7x - 12th November 2016

Hi kdemeoz,
Can you please check after you manage to boot via recovery, go to system settings -> workspace behavior -> compositor and check if you have opengl active or just Xrender? I ask because after googling a bit, when this happens and you are able to start the desktop only via recovery, there is a problem with graphics card or driver - it is not able to start compositing.. just check what you have after booting..

RE: Major Maui Meltdown. - kdemeoz - 13th November 2016

(12th November 2016, 17:50)fanisatt Wrote: Your welcome kdemeoz ! I used to keep two different Linux OSs in two different hard disks or SSDs (it is a very simple installation) and I keep all my DATA in other different partitions of the OSs. I don't really use a common HOME partition because, I had problems in the past and I wanted every time a really clean and safe installation of any new OS with my DATA in a different and safe place too. So, if any software problem occurs to the first OS I can easily and immediately work with the second one , except there is a common hardware problem. I don't use encrypted partitions and I can't help you with this. I wish I could help you on your specific MAUI problem but I am only a simple user . Happy Saturday !
 

Thanks fanisatt. Yes, i have also read in other places online that some [many?] people who have multi-boot Linux distros keep each distros' /home strictly separated from each other, & basically only used for configs, but all user data is kept in a separate dedicated shared data partition &/or ssd/hdd. I have occasionally wondered about maybe doing that too myself... but my laziness is a bit of an obstacle, not to mention my fear of destroying everything!   Tongue

RE: Major Maui Meltdown. - kdemeoz - 13th November 2016

(12th November 2016, 21:23)rocky7x Wrote: Hi kdemeoz,
Can you please check after you manage to boot via recovery, go to system settings -> workspace behavior -> compositor and check if you have opengl active or just Xrender? I ask because after googling a bit, when this happens and you are able to start the desktop only via recovery, there is a problem with graphics card or driver - it is not able to start compositing.. just check what you have after booting..

Hi rocky. Yes it was a good idea & one that also occurred to me soon after this strange bug commenced. I have checked several times since then [including just as i began this reply], & each time, Compositing is still on my OpenGL 3.1 setting [this is after doing the recovery fsck boot option btw; the only way now i can boot].

Here's something a little strange as well. My usual behaviour at day's/night's end, once i need zzzzzzzzzz, is to Suspend my Tower, not Shutdown, & then Resume it the following morning. Hence, in a way, some might argue that my anxiety over this recent problem is unwarranted, if i hardly ever have to do an actual boot [but for me, my anxiety is justified, as something must have changed / gone wrong, & that can't be a good thing]. Anyway, until a couple of days ago [that i can remember], after each morning's Resume, my previous night's plasmashell desktop with all active windows on all my VDs would correctly return & all compositing [eg, desktop effects] would be good & fine, BUT the Cairo-Dock [which uses OpenGL] icons would all be broken [they still worked correctly if i clicked them, but their icons/emblems were missing or pixelated]. To fix it each time i had to stop & start CD. 

However for the past couple [that i can remember] of mornings' Resumes, everything is good... including CD. I can only definitely certainly recall the past couple of days that this new behaviour is true, but it is possible this new behaviour might actually have begun when the main bug arose of no normal boots possible, hence the recovery option needed. I cannot explain this, & it might be a mere coincidence unrelated to the recovery boot, but thought i'd mention it in case it gave anyone any fresh ideas.

Golly this is all so weird!

RE: Major Maui Meltdown. - leszek - 13th November 2016

I thought the boot error happens early in the boot so it isn't even starting X.
Can you confirm that with the quiet splash boot parameters removed ?

RE: Major Maui Meltdown. - kdemeoz - 13th November 2016

In #10 above, https://forums.mauilinux.org/showthread.php?tid=24099&pid=40322#pid40322, in answer to your "Press e on boot entry in grub remove the splash and quiet parameter and hit ctrl+x to boot", i said "yes this stopped the skyblue Maui splash screen appearing, but instead the screen then just stayed black except for a low-res pixelated rectangular border near the screen edges. Nothing happened after this [& i retried this many times], so i had to re-reboot".

Does this adequately answer your latest question, or have i misunderstood?

RE: Major Maui Meltdown. - leszek - 13th November 2016

The only option then left is removing the proprietary nvidia driver and remove the nomodeset parameter.
As the graphics initialization on a kernel level even fails it must be the nvidia driver being the culprit here again.
At least you should get boot messages again by removing the nvidia driver. However I am not sure why it works in recovery for you as you apparently are using nvidia here successfully.

Is the nomodeset parameter still used by your normal boot to disable nouveau?
Is nouveau maybe loaded as module even in recovery boot? lsmod shows you a list of loaded kernel modules.

Did you tried booting older kernels?

RE: Major Maui Meltdown. - kdemeoz - 14th November 2016

(13th November 2016, 13:36)leszek Wrote: The only option then left is removing the proprietary nvidia driver and remove the nomodeset parameter.
As the graphics initialization on a kernel level even fails it must be the nvidia driver being the culprit here again.

Questions:
1. To remove the NVidia driver, do you mean literally uninstall it via apt or Synaptic, or do you only mean that in the Maui Settings Driver Manager i would simply stop selecting it like it is currently, & instead select nouveau?

2. I am not arguing, but am only trying to understand. Given that obviously the Nvidia driver WAS working fine, at least up until the day i experienced this fault & posted here [9 Nov], it is thus not faulty by design. How then can it have "failed" on 9 Nov? Does this mean its code became corrupted somehow? 


Quote:At least you should get boot messages again by removing the nvidia driver. However I am not sure why it works in recovery for you as you apparently are using nvidia here successfully. 

Would no NVidia driver in-use = no Plasma Desktop Effects?

Yes, the Nvidia driver appears to be working perfectly after using the recovery boot option to get back into a desktop session [eg, now]. In fact everything seems quite wonderful, other than this rotten recent problem stopping me doing a normal boot. This is another reason i don't yet understand the logic of removing the Nvidia driver...

Quote:Is the nomodeset parameter still used by your normal boot to disable nouveau? 

Is nouveau maybe loaded as module even in recovery boot? lsmod shows you a list of loaded kernel modules. 

Here's the output:
Code:
Z97-HD3:~$ lsmod
Module                  Size  Used by
serpent_avx2           49152  2
serpent_avx_x86_64     49152  1 serpent_avx2
serpent_sse2_x86_64    53248  0
serpent_generic        32768  3 serpent_sse2_x86_64,serpent_avx_x86_64,serpent_avx2
twofish_generic        20480  0
twofish_avx_x86_64     49152  2
twofish_x86_64_3way    28672  1 twofish_avx_x86_64
twofish_x86_64         16384  2 twofish_avx_x86_64,twofish_x86_64_3way
twofish_common         24576  4 twofish_generic,twofish_avx_x86_64,twofish_x86_64_3way,twofish_x86_64
xts                    16384  2 serpent_sse2_x86_64,twofish_x86_64_3way
uas                    24576  0
usb_storage            69632  3 uas
pci_stub               16384  1
vboxpci                24576  0
vboxnetadp             28672  0
vboxnetflt             28672  0
vboxdrv               454656  3 vboxnetadp,vboxnetflt,vboxpci
binfmt_misc            20480  1
drbg                   32768  1
ansi_cprng             16384  0
intel_rapl             20480  0
x86_pkg_temp_thermal    16384  0
intel_powerclamp       16384  0
dm_crypt               28672  5
coretemp               16384  0
kvm_intel             172032  0
snd_hda_codec_hdmi     53248  1
kvm                   540672  1 kvm_intel
irqbypass              16384  1 kvm
crct10dif_pclmul       16384  0
crc32_pclmul           16384  0
nvidia_uvm            745472  0
snd_soc_rt5640        114688  0
joydev                 20480  0
aesni_intel           167936  11075
snd_soc_rl6231         16384  1 snd_soc_rt5640
snd_soc_ssm4567        16384  0
input_leds             16384  0
snd_soc_core          212992  2 snd_soc_rt5640,snd_soc_ssm4567
aes_x86_64             20480  1 aesni_intel
lrw                    16384  6 serpent_sse2_x86_64,aesni_intel,serpent_avx_x86_64,serpent_avx2,twofish_avx_x86_64,twofish_x86_64_3way
gf128mul               16384  2 lrw,xts
snd_compress           20480  1 snd_soc_core
snd_hda_codec_realtek    86016  1
glue_helper            16384  6 serpent_sse2_x86_64,aesni_intel,serpent_avx_x86_64,serpent_avx2,twofish_avx_x86_64,twofish_x86_64_3way
ac97_bus               16384  1 snd_soc_core
ablk_helper            16384  5 serpent_sse2_x86_64,aesni_intel,serpent_avx_x86_64,serpent_avx2,twofish_avx_x86_64
snd_hda_codec_generic    77824  1 snd_hda_codec_realtek
snd_pcm_dmaengine      16384  1 snd_soc_core
cryptd                 20480  5541 aesni_intel,ablk_helper
snd_seq_midi           16384  0
snd_hda_intel          40960  7
snd_seq_midi_event     16384  1 snd_seq_midi
snd_rawmidi            32768  1 snd_seq_midi
snd_seq                69632  2 snd_seq_midi_event,snd_seq_midi
snd_hda_codec         135168  4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
serio_raw              16384  0
snd_hda_core           73728  5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
snd_hwdep              16384  1 snd_hda_codec
snd_pcm               106496  8 snd_soc_rt5640,snd_soc_core,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_pcm_dmaengine,snd_hda_core
mei_me                 36864  0
snd_seq_device         16384  3 snd_seq,snd_rawmidi,snd_seq_midi
mei                    98304  1 mei_me
shpchp                 36864  0
snd_timer              32768  2 snd_pcm,snd_seq
lpc_ich                24576  0
snd                    81920  26 snd_hda_codec_realtek,snd_soc_core,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_compress
elan_i2c               36864  0
soundcore              16384  1 snd
dw_dmac                16384  0
snd_soc_sst_acpi       16384  0
i2c_designware_platform    16384  0
spi_pxa2xx_platform    24576  0
dw_dmac_core           24576  1 dw_dmac
8250_fintek            16384  0
8250_dw                16384  0
i2c_designware_core    20480  1 i2c_designware_platform
mac_hid                16384  0
acpi_pad               20480  0
ip6t_REJECT            16384  1
nf_reject_ipv6         16384  1 ip6t_REJECT
nf_log_ipv6            16384  5
xt_hl                  16384  22
ip6t_rt                16384  3
nf_conntrack_ipv6      20480  8
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
ipt_REJECT             16384  1
nf_reject_ipv4         16384  1 ipt_REJECT
nf_log_ipv4            16384  5
nf_log_common          16384  2 nf_log_ipv4,nf_log_ipv6
xt_LOG                 16384  10
xt_limit               16384  13
xt_tcpudp              16384  18
xt_addrtype            16384  4
nf_conntrack_ipv4      16384  8
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
xt_conntrack           16384  16
ip6table_filter        16384  1
ip6_tables             28672  1 ip6table_filter
nf_conntrack_netbios_ns    16384  0
nf_conntrack_broadcast    16384  1 nf_conntrack_netbios_ns
nf_nat_ftp             16384  0
nf_nat                 24576  1 nf_nat_ftp
nf_conntrack_ftp       20480  1 nf_nat_ftp
nf_conntrack          106496  8 nf_nat_ftp,nf_conntrack_netbios_ns,nf_nat,xt_conntrack,nf_conntrack_broadcast,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_ipv6
iptable_filter         16384  1
ip_tables              24576  1 iptable_filter
x_tables               36864  13 ip6table_filter,xt_hl,ip_tables,xt_tcpudp,xt_limit,xt_conntrack,xt_LOG,iptable_filter,ip6t_rt,ipt_REJECT,ip6_tables,xt_addrtype,ip6t_REJECT
parport_pc             32768  1
ppdev                  20480  0
lp                     20480  0
parport                49152  3 lp,ppdev,parport_pc
autofs4                40960  2
hid_generic            16384  0
usbhid                 49152  0
i915                 1208320  0
nvidia_drm             45056  1
nvidia_modeset        765952  16 nvidia_drm
i2c_algo_bit           16384  1 i915
drm_kms_helper        155648  2 i915,nvidia_drm
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
nvidia              11489280  354 nvidia_modeset,nvidia_uvm
psmouse               126976  0
ahci                   36864  5
drm                   364544  5 i915,drm_kms_helper,nvidia_drm
r8169                  81920  0
libahci                32768  1 ahci
mii                    16384  1 r8169
i2c_hid                20480  0
sdhci_acpi             16384  0
video                  40960  1 i915
hid                   118784  3 i2c_hid,hid_generic,usbhid
sdhci                  45056  1 sdhci_acpi
fjes                   28672  0


Quote:Did you tried booting older kernels?

Yes. Here's one of my points in my original post:
Quote:11. Now when i rebooted for the umpteenth time i selected the 4.4.0-42 kernel instead of my usual 4.4.0-45 kernel, but it made no difference.

Given that i now use the 47 kernel, that's 3 separate kernels which now behave this way [& 42 + 45 never used to, until 9 Nov]. To my mind this more or less eliminates a specific kernel problem.

In the Maui Settings Driver Manager, the very first row [not ticked at the moment] is "Using Processor microcode firmware for Intel CPUs from intel-microcode". Should i try selecting that & booting? Could it cause other [new] problems?

RE: Major Maui Meltdown. - rocky7x - 14th November 2016

Hi,

I think I've found what's the difference between normal and recovery boot: recovery adds nomodeset and xforcevesa parameters to the boot string. So, please, in addition to nomodeset, try to also add xforcevesa to your default grub launch string in /etc/default/grub. Then try the normal boot.