You are not logged in.
I'm betting that most of us are leaving the screw in and thus doing a traditional mbr/grub setup via SeaBIOS. (And in fact, you're the only data point I know of for EFI install, and I'm now dissuaded against trying)
How did you manage dual booting with stock ChromeOS? Did you shrink the existing ChromeOS partitions to make room for your own?
As for graphical corruption, I assume you have a DE configured to start during your boot? I'm not sure, installing X, xorg-intel drivers and that was sufficient. Adding i915 to mkinitcpio just fixed some early boot graphical corruption.
Well, my "dual boot" setup isn't GRUB-like bootloader setup. It handles like this:
First, I get the initial ChromeOS bootsplash telling me that OS verification is off. At that point, I can use ctrl-D in a brief window of time to get it to boot ChromeOS. From there, if I don't ctrl-D, it will go to SeaBIOS and give me the option to hit escape to select my boot device. If I do that, and select the internal hard drive, it would totally boot from the internal hard drive if I had anything bootable on it. I like to think, at least. I'm going to try it again with a guided installer (Antergos) and see if it can work with the bootloader setup than I can manually. So, yes, I did shrink the Chrome OS partition. The guide for that is here: https://wiki.archlinux.org/index.php/Ch … _Chrome_OS (this script went without a hitch)
I actually had no xorg/wayland on the machine. I think the display corruption was from the gumiboot being misconfigured. So, I'm going under to install Antergos now as a sort of stab in the dark. I'll post results.
By the way, I don't know if this has already been posted, but I have used this multiple times to bring my chromebook back from the dead and it seems to work without a hitch: https://support.google.com/chromebook/answer/6002417
Offline
colemickens wrote:I'm betting that most of us are leaving the screw in and thus doing a traditional mbr/grub setup via SeaBIOS. (And in fact, you're the only data point I know of for EFI install, and I'm now dissuaded against trying)
How did you manage dual booting with stock ChromeOS? Did you shrink the existing ChromeOS partitions to make room for your own?
As for graphical corruption, I assume you have a DE configured to start during your boot? I'm not sure, installing X, xorg-intel drivers and that was sufficient. Adding i915 to mkinitcpio just fixed some early boot graphical corruption.
Well, my "dual boot" setup isn't GRUB-like bootloader setup. It handles like this:
First, I get the initial ChromeOS bootsplash telling me that OS verification is off. At that point, I can use ctrl-D in a brief window of time to get it to boot ChromeOS. From there, if I don't ctrl-D, it will go to SeaBIOS and give me the option to hit escape to select my boot device. If I do that, and select the internal hard drive, it would totally boot from the internal hard drive if I had anything bootable on it. I like to think, at least. I'm going to try it again with a guided installer (Antergos) and see if it can work with the bootloader setup than I can manually. So, yes, I did shrink the Chrome OS partition. The guide for that is here: https://wiki.archlinux.org/index.php/Ch … _Chrome_OS (this script went without a hitch)
I actually had no xorg/wayland on the machine. I think the display corruption was from the gumiboot being misconfigured. So, I'm going under to install Antergos now as a sort of stab in the dark. I'll post results.
By the way, I don't know if this has already been posted, but I have used this multiple times to bring my chromebook back from the dead and it seems to work without a hitch: https://support.google.com/chromebook/answer/6002417
How would SeaBIOS be able to load gummiboot? gummiboot is an efi boot manager and SeaBIOS doesn't enable any sort of UEFI mode. Or am I missing something further?
Offline
How would SeaBIOS be able to load gummiboot? gummiboot is an efi boot manager and SeaBIOS doesn't enable any sort of UEFI mode. Or am I missing something further?
...yep. I guess I didn't think too hard about that one... BIOS installation it is then. Thanks for pointing that out. I've decided against the dual boot as well, although for the record, it is very possible.
Offline
I received my pixel this week as well. And love it. I tried to install with syslinux, but settled for the mbr/grub-way to have something up and running to play around with. Kudos to you all in this thread! Have some DM-related about HiDPI, but that should be another thread.
One thing I would like to change is the boot process. I don't like how I have to press CTRL-L and also how anybody would be able to boot from USB on my Pixel. I still somehow like syslinux over grub, so I wouldn't say no to using syslinux either.
Anybody played around with the screw and SeaBIOS? Would I have to flash it to do what I just wrote?
Offline
I received my pixel this week as well. And love it. I tried to install with syslinux, but settled for the mbr/grub-way to have something up and running to play around with. Kudos to you all in this thread! Have some DM-related about HiDPI, but that should be another thread.
One thing I would like to change is the boot process. I don't like how I have to press CTRL-L and also how anybody would be able to boot from USB on my Pixel. I still somehow like syslinux over grub, so I wouldn't say no to using syslinux either.
Anybody played around with the screw and SeaBIOS? Would I have to flash it to do what I just wrote?
You don't have to flash it. You do have to remove the screw to disable write-protect on the gbb flags that control the scary boot screen. And you'll need a working Chrome OS install to be able to use set_gbb_flags.sh to set the gbb flags
Offline
But how do I disable boot from usb, if I just wiped it and installed arch from usb? Are you saying that's impossible?
Offline
But how do I disable boot from usb, if I just wiped it and installed arch from usb? Are you saying that's impossible?
You can use this method and change the script to disable the flags, rather than re-enable them. https://sites.google.com/a/chromium.org … n-dev-mode
Offline
For anyone who missed it earlier, the graphical issues when booting can be handled by setting MODULES="i915" in mkinitcpio.conf and GRUB_TERMINAL=console in /etc/default/grub.
Second, when they say lights can be controlled through `/sys/class/leds/chromeos::kbd_backlight.`, what does that mean? Is there just a file there, that when written, changes the color of the lights?.
Thanks!
This is what I'm using to adjust the keyboard backlight: https://github.com/razor-x/archrc/blob/ … _backlight
I received my pixel this week as well. And love it. I tried to install with syslinux, but settled for the mbr/grub-way to have something up and running to play around with. Kudos to you all in this thread! Have some DM-related about HiDPI, but that should be another thread.
One thing I would like to change is the boot process. I don't like how I have to press CTRL-L and also how anybody would be able to boot from USB on my Pixel. I still somehow like syslinux over grub, so I wouldn't say no to using syslinux either.
Anybody played around with the screw and SeaBIOS? Would I have to flash it to do what I just wrote?
The arch wiki has good HiDPI advice. I'm currently using Xft.dpi: 144.
Opening the back was actually really easy. Two things I will recommend:
1) Pull off the rubber feet gently so you don't stretch them out, and use a little super glue for putting them back. Mine are back on good as new now.
2) Do NOT use cheap screwdrivers on the tiny screws. I almost stripped a few with a $10 set and had to stop. I bought these and the normal Phillips worked perfectly http://www.amazon.com/gp/product/B000JCT3W0/
Offline
satchmosgroove wrote:But how do I disable boot from usb, if I just wiped it and installed arch from usb? Are you saying that's impossible?
You can use this method and change the script to disable the flags, rather than re-enable them. https://sites.google.com/a/chromium.org … n-dev-mode
Hm, while this information is good to know, I think I meant something different. I was hoping for turning that feature on/off behind a password in the BIOS. With that script, you linked, I would turn USB-boot off for good, right? This would lock myself out for good as well, if I ever want to install arch again (or something different, which sound very unrealistic ;-)).
Maybe my thought was a little too paranoid and I should not worry about that still being enabled.
@Razor X: thanks for the amazon link :-) I am usually never too scared to remove screws.
Offline
colemickens wrote:satchmosgroove wrote:But how do I disable boot from usb, if I just wiped it and installed arch from usb? Are you saying that's impossible?
You can use this method and change the script to disable the flags, rather than re-enable them. https://sites.google.com/a/chromium.org … n-dev-mode
Hm, while this information is good to know, I think I meant something different. I was hoping for turning that feature on/off behind a password in the BIOS. With that script, you linked, I would turn USB-boot off for good, right? This would lock myself out for good as well, if I ever want to install arch again (or something different, which sound very unrealistic ;-)).
Maybe my thought was a little too paranoid and I should not worry about that still being enabled.
@Razor X: thanks for the amazon link :-) I am usually never too scared to remove screws.
Yes, that would indeed lock you out from installing Arch later. You would need to use this same technique the turn ON the flags, or reinstall ChromeOS and use set_gbb_flags.sh from there.
AFAIK, there's no BIOS setup screen from which to change these flags. This is all for spoofing/security reasons.
Maybe my thought was a little too paranoid and I should not worry about that still being enabled.
I'm not too worried about it tbh.
Offline
Maybe my thought was a little too paranoid and I should not worry about that still being enabled.
I'm not too worried about it tbh.
I thought about this a bit, but I'm running everything encrypted, so the only real attack vector is someone specifically booting off USB while I'm not looking with the intent of replacing the kernel with something malicious.
Offline
Okay, so now that I tinkered around I would wipe it once more to get rid of the CTRL-L screen and set up system encryption.
To get rid of the CTRL-L screen I have to recover to ChromeOS first and then follow https://wiki.archlinux.org/index.php/Ch … by_default, correct?
Does GPT not work at all in SeaBIOS? Or did just nobody try? Guess I couldn't care less to use MBR.
And what is wrong with Syslinux? Does that not work at all either?
Offline
Okay, so now that I tinkered around I would wipe it once more to get rid of the CTRL-L screen and set up system encryption.
To get rid of the CTRL-L screen I have to recover to ChromeOS first and then follow https://wiki.archlinux.org/index.php/Ch … by_default, correct?
Does GPT not work at all in SeaBIOS? Or did just nobody try? Guess I couldn't care less to use MBR.
And what is wrong with Syslinux? Does that not work at all either?
I am using GPT with a BIOS boot partition (https://wiki.archlinux.org/index.php/GR … structions).
Last edited by Razor X (2015-05-04 18:37:32)
Offline
Okay, so now that I tinkered around I would wipe it once more to get rid of the CTRL-L screen and set up system encryption.
To get rid of the CTRL-L screen I have to recover to ChromeOS first and then follow https://wiki.archlinux.org/index.php/Ch … by_default, correct?
Does GPT not work at all in SeaBIOS? Or did just nobody try? Guess I couldn't care less to use MBR.
And what is wrong with Syslinux? Does that not work at all either?
You don't need to flash SeaBIOS, but you'll need to remove the write protect screw from the inside of the machine in order to disable the scary boot screen via set_gbb_flags.sh
Offline
You don't need to flash SeaBIOS, but you'll need to remove the write protect screw from the inside of the machine in order to disable the scary boot screen via set_gbb_flags.sh
Okay, that's what I meant, thanks.
@ Raxor X: Cool, I think it was colemickens' guide which said to do MBR/GRUB and Syslinux failed for me for some reason. So, wasn't sure if all that had a specific reason.
You are all very helpful! I like my new toy very much.
Offline
Opening the back was actually really easy. Two things I will recommend:
1) Pull off the rubber feet gently so you don't stretch them out, and use a little super glue for putting them back. Mine are back on good as new now.
2) Do NOT use cheap screwdrivers on the tiny screws. I almost stripped a few with a $10 set and had to stop. I bought these and the normal Phillips worked perfectly http://www.amazon.com/gp/product/B000JCT3W0/
Did you initially stretch your rubber strips?
I had the worst luck with trying to remove my write protect screw. The last screw I had to unscrew to open the back got stripped and as I was putting everything back together just now, it turns out both my rubber strips got stretched when I removed them even though I removed them fairly slowly. One is 1mm too long and the other is 2mm. I notice there are little slivers of space on the sides of the strips now so I definitely stretched them lengthwise; they didn't just expand.
Hopefully a hair dryer will work to contract them a little, but worst case I guess I can amputate the extra. Anyways, I'm hoping you have a better solution.
Offline
Razor X wrote:Opening the back was actually really easy. Two things I will recommend:
1) Pull off the rubber feet gently so you don't stretch them out, and use a little super glue for putting them back. Mine are back on good as new now.
2) Do NOT use cheap screwdrivers on the tiny screws. I almost stripped a few with a $10 set and had to stop. I bought these and the normal Phillips worked perfectly http://www.amazon.com/gp/product/B000JCT3W0/Did you initially stretch your rubber strips?
I had the worst luck with trying to remove my write protect screw. The last screw I had to unscrew to open the back got stripped and as I was putting everything back together just now, it turns out both my rubber strips got stretched when I removed them even though I removed them fairly slowly. One is 1mm too long and the other is 2mm. I notice there are little slivers of space on the sides of the strips now so I definitely stretched them lengthwise; they didn't just expand.
Hopefully a hair dryer will work to contract them a little, but worst case I guess I can amputate the extra. Anyways, I'm hoping you have a better solution.
Yes I did stretch mine when I pulled them (was not thinking that would be an issue at the time) and only realized this when they seemed to be a bit too long to fit perfectly back in place. Anyway, The trick I used was to 1) use small dabs of superglue in the spaces between the screws, and 2) place each end in snugly first and then smooth down towards the middle. Now they fit back good as new and I can't tell that there was ever any stretching.
As for the screws: yea they are delicate and the best bet to avoid stripping is to buy quality tools like the ones I linked earlier.
Offline
hobn wrote:Razor X wrote:Opening the back was actually really easy. Two things I will recommend:
1) Pull off the rubber feet gently so you don't stretch them out, and use a little super glue for putting them back. Mine are back on good as new now.
2) Do NOT use cheap screwdrivers on the tiny screws. I almost stripped a few with a $10 set and had to stop. I bought these and the normal Phillips worked perfectly http://www.amazon.com/gp/product/B000JCT3W0/Did you initially stretch your rubber strips?
I had the worst luck with trying to remove my write protect screw. The last screw I had to unscrew to open the back got stripped and as I was putting everything back together just now, it turns out both my rubber strips got stretched when I removed them even though I removed them fairly slowly. One is 1mm too long and the other is 2mm. I notice there are little slivers of space on the sides of the strips now so I definitely stretched them lengthwise; they didn't just expand.
Hopefully a hair dryer will work to contract them a little, but worst case I guess I can amputate the extra. Anyways, I'm hoping you have a better solution.
Yes I did stretch mine when I pulled them (was not thinking that would be an issue at the time) and only realized this when they seemed to be a bit too long to fit perfectly back in place. Anyway, The trick I used was to 1) use small dabs of superglue in the spaces between the screws, and 2) place each end in snugly first and then smooth down towards the middle. Now they fit back good as new and I can't tell that there was ever any stretching.
As for the screws: yea they are delicate and the best bet to avoid stripping is to buy quality tools like the ones I linked earlier.
I . . . cannot believe that worked! I didn't apply any super glue and it still worked. Thanks!
Offline
I opened it as well and that was fairly easy. I actually bought the recommended tools (good buy!) I was careful to take the strips off. They have some double-sided scotch tape. I put it back on without superglue (sounded too permanent to me) and it holds perfect. Shouldn't do that too often, though.
I have now an encrypted gpt/grub install. all works very well. only issue I have is the microphone, but I didn't follow tsowell's github's thread yet. will do that later this week.
Offline
Re the microphone: just heads up that there still seems to be some situations left unresolved, you can see the Issue opened here: https://github.com/tsowell/linux-samus/issues/4
But it also seems that some people have got it to work too, but I am not sure how.
Whichever happens for you, mind keeping this thread updated?
Offline
sure, will do
Offline
Am I the only one getting graphical corruption past boot? Sometimes when the X server is started or killed or when I'm switching ttys or resuming from suspend, my screen splits into rectangles and seems to flicker between them. This happens not only when running an X server, but also on ttys. One time it went away as I was installing Chromium. Launching Chrome or Chromium also seems to fix it fairly reliably. If it is already running relaunching does the same thing.
One interesting and very replicable discovery that I've made is that if I run DWM on two ttys and set one to a custom 1280x850 mode and leave the other one on the default 2560x1700, the 1280x850 session has the flickering for like a second when I switch to it and goes back to normal. The other one continues to flicker.
Does anyone have any ideas what could be causing this?
Last edited by hobn (2015-05-13 10:07:58)
Offline
I don't have that flickering. I am using Plasma and remember having similar issues with plasma on another laptop. Switching the opengl option under compositing to egl solved that one. Don't know if that's your problem, if you have it already right at booting up.
Besides the mic I have another audio issue. After bringing it back from sleep audio seems to go away. After reboot audio works again.
EDIT: can't reproduce on every sleep, though.
Last edited by satchmosgroove (2015-05-13 13:18:32)
Offline
I don't have that flickering. I am using Plasma and remember having similar issues with plasma on another laptop. Switching the opengl option under compositing to egl solved that one. Don't know if that's your problem, if you have it already right at booting up.
Besides the mic I have another audio issue. After bringing it back from sleep audio seems to go away. After reboot audio works again.
EDIT: can't reproduce on every sleep, though.
Have you tried alsactl store? It's mentioned here.
How exactly do you switch the OpenGL option? I can't find anything on that.
Offline
I did alsactl store. that's why I always get it back after reboot. Still have to figure how to reproduce.
For the opengl: Plasma has a "compositing" section under "Desktop Effects" in System Settings. you can change the rendering method there. Don't know if there are similar options in other DEs.
Offline