I've just installed Indian Summer on a new box with an SSD drive. I manually ran fstrim -v / and everything seemed OK. When I rebooted it failed to launch kde. I reinstalled and ran into the same problem. This time I tried root user and startx and I got to a 'desktop' with a notice that plasma desktop had failed. Anyone else ran into this problem?
System: Host: siduction Kernel: 3.18-5.towo.3-siduction-amd64 x86_64 (64 bit gcc: 4.9.2)
Desktop: KDE 4.14.2 (Qt 4.8.6) Distro: siduction 14.1.0 Indian Summer - kde - (201411230337)
Machine: Mobo: Gigabyte model: Z97X-UD5H v: x.x Bios: American Megatrends v: F7 date: 05/30/2014
CPU: Quad core Intel Core i7-4790 (-HT-MCP-) cache: 8192 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 28813
clock speeds: max: 4000 MHz 1: 3998 MHz 2: 3985 MHz 3: 3995 MHz 4: 3596 MHz 5: 907 MHz 6: 3997 MHz
7: 3856 MHz 8: 3960 MHz
Graphics: Card: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller bus-ID: 00:02.0
Display Server: X.Org 1.16.2.901 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.00hz
GLX Renderer: Mesa DRI Intel Haswell Desktop GLX Version: 3.0 Mesa 10.4.2 Direct Rendering: Yes
Network: Card-1: Intel Ethernet Connection I217-V driver: e1000e v: 2.3.2-k port: f080 bus-ID: 00:19.0
IF: eth1 state: up speed: 1000 Mbps duplex: full mac: 74:d4:35:ea:b0:d5
Card-2: Qualcomm Atheros Killer E220x Gigabit Ethernet Controller
driver: alx port: e000 bus-ID: 02:00.0
IF: eth0 state: down mac: 74:d4:35:ea:b0:d7
Drives: HDD Total Size: 6513.3GB (25.7% used) ID-1: model: ST2000DM001
ID-2: model: ST2000DM001 ID-3: model: Crucial_CT512MX1
ID-4: model: ST2000DM001
Info: Processes: 258 Uptime: 19 min Memory: 1065.7/15905.3MB Init: systemd runlevel: 5 Gcc sys: 4.9.2
Client: Shell (bash 4.3.331) inxi: 2.2.18
It's hard for me to think why fstrim would have any connection to a KDE or plasma desktop problem. More likely it is something about your GPU and driver. I have been running siduction (and aptosid before that) on a OCZ Revodrive SSD for 4 years:
System: Host: imerabox Kernel: 3.18-6.towo-siduction-amd64 x86_64 (64 bit gcc: 4.9.2)
Desktop: KDE 4.14.3 (Qt 4.8.6) Distro: aptosid 2011-02 Ἡμέρα - kde-lite - (201107131633)
Machine: System: ASUS product: All Series
Mobo: ASUSTeK model: Z87-WS v: Rev 1.xx Bios: American Megatrends v: 2004 date: 06/05/2014
CPU: Quad core Intel Core i7-4770 (-HT-MCP-) cache: 8192 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 28021
clock speeds: max: 3900 MHz 1: 3586 MHz 2: 3400 MHz 3: 3753 MHz 4: 3400 MHz 5: 3633 MHz 6: 3401 MHz
7: 3897 MHz 8: 3709 MHz
Graphics: Card: NVIDIA GM107 [GeForce GTX 750 Ti] bus-ID: 05:00.0
Display Server: X.Org 1.16.2.901 driver: nvidia Resolution: 1920x1200@59.88hz
GLX Renderer: GeForce GTX 750 Ti/PCIe/SSE2 GLX Version: 4.4.0 NVIDIA 340.76 Direct Rendering: Yes
Network: Card-1: Intel I210 Gigabit Network Connection driver: igb v: 5.2.15-k port: d000 bus-ID: 07:00.0
IF: eth1 state: up speed: 100 Mbps duplex: full mac: e0:3f:49:e6:85:c3
Card-2: Intel I210 Gigabit Network Connection driver: igb v: 5.2.15-k port: a000 bus-ID: 0a:00.0
IF: eth2 state: down mac: e0:3f:49:e6:85:c4
Drives: HDD Total Size: 2220.5GB (34.0% used) ID-1: model: OCZ
ID-2: model: Hitachi_HTS72101 ID-3: model: OCZ
ID-4: model: WDC_WD1000DHTZ ID-5: model: WDC_WD1000DHTZ
Info: Processes: 305 Uptime: 45 min Memory: 1630.4/7917.5MB Init: systemd runlevel: 5 Gcc sys: 4.9.2
Client: Shell (bash 4.3.331) inxi: 2.2.18
I run a weekly fstrim cron job on it.
Running X as root is never recommended -- there is no solution down that path. Try booting with a "3" boot option, which should bring you to a tty login, and login there as root. Then issue
systemctl start lightdm && exit and tell us about the error output.
Does a "3" in the boot line work with systemd?
Yes. When you see the grub menu, press "e". Find the line that begins "linux /vmlinuz-3.18-xxxxxx ...". Right cursor to the end, add a space and a "3", and then press Ctrl-X to boot it.
Thanks!
Fortunately I've not been able to reproduce this problem a third time. I'll proceed cautiously but thanks for help!
drb,
it would still be much better to dig into the problem or its cause... there must be a reason for that behaviour.
have you checked the integrity of the ISO before installing (md5 or sha256 sums) ? did you run memtest? etc...
After it happening on two installs I was pleased it appears not to be a continuing problem. The iso was fine. Only one change : on running fstrim -v / it doesn't completely trim the SDD; I now run it a second time to confirm there is nothing left to trim