search

nuclearsandwich / surface3-archlinux

Archlinux on the Microsoft Surface Pro 3
69 stars 4 forks source link

Installer hardlocks on Surface 3 (not pro) #22

Closed staticfloat closed 9 years ago

staticfloat commented 9 years ago

Hey guys, I've got a fun one that I'm trying to track down, and since ya'll are the closest to a community of experts as I could find, I thought I would try my luck here first.

I have a Surface 3 (not a pro) that I'm trying to install arch onto. Booting off of the installer USB goes fine right up to the point at which I get a root shell in the typical installer environment; that console waits a second or two, then flips to a black screen with just the cursor in the top left of the screen. That cursor blinks a few times and then freezes.

Great; so I've figured out that there's something going horrifically wrong with this environment, but what? Because it's a live USB, the kernel log isn't getting saved anywhere on the USB stick so I tacked break=y to the end of the kernel parameters, mounted the USB drive as read/write and saved dmesg output, lsmod output, etc.. which you can see here. Complicating this debugging issue is that my type cover, which works in the boot menu, e.g. for editing kernel parameters and the like, doesn't work in arch; there's something suspicious in dmesg.txt about that, the type cover seems to be continually disconnecting and reconnecting, or something.

So in short, I have two problems:

You guys have any bright ideas for dealing with these things? I initially thought that the screen clear/hardlock sounded like a video card issue, so I tried adding nomodeset i915.modeset=0 to the end of the kernel parameters, but that didn't seem to do anything.

james-lawrence commented 9 years ago

Hey the hardlock is due to /etc/systemd/logind.conf: change: HandleLidSwitch=suspend to: HandleLidSwitch=ignore

You'll have to reimage the boot image to fix this. you can also boot in single user mode to access the previous bootlogs via journalctl. which is how I figured out this issue. (noticed that a lid close event was getting handled by systemd)

Also I see the same behaviour with my typecover.

staticfloat commented 9 years ago

Ah, thank you! To change this on the installer USB, I booted off of Ubuntu on another computer, installed squashfs-tools, unsquashed the x86_64 squashfs file to a local directory, modified the directory accordingly, then resquashed it into a new .sfs file, moved that file back to the original .sfs file's location, and it all worked!

Should we report this as a bug somewhere? Would this be a bug in systemd?

james-lawrence commented 9 years ago

its a known issue last i knew. https://bugzilla.kernel.org/show_bug.cgi?id=84651 probably already resolved in 4.2?

james-lawrence commented 9 years ago

also: https://bugs.archlinux.org/task/45921 - i reported the problem with the install media when I first found it, looks like they changed it for the next release. Doesn't fix the problem in the kernel causing it to get triggered but prevents that sort of bug from impacting users attempting to install the os.

staticfloat commented 9 years ago

Excellent, thank you for that James. With that, I'm considering this closed!

hadess commented 9 years ago

Not sure why you'd want to change the defaults in systemd's lid handling, when that problem is actually a kernel bug. Pretty sure it's a kernel regression because I've also seen the problem on some BayTrail tablets.

james-lawrence commented 9 years ago

@hadess because there is no reason to respond to the suspend/hibernate events within the installation media and they can prevent users from actually installing the os in cases like this. ./shrug regardless the maintainer agreed with me. if you read the ticket I said it was pretty esoteric and unlikely to happen in general. They only changed it for the live cd, so once its installed it'll again immediately suspend, but now you can use the live cd to figure out and fix the issue.

side note: in case you meant change the systemd defaults itself. That isn't what I was suggesting in the ticket. I was asking arch linux to change the setting in the configuration file to override the default only for the live cd.

hadess commented 9 years ago

Given that rationale, yes, working around the problem is probably a good decision.