Jump to content



Photo
debian; chrome os; chromebook

  • Please log in to reply
33 replies to this topic

#16 Xerino

Xerino

    The Mouth

  • Joined: 09-January 04
  • Location: California
  • OS: Windows 8.1

Posted 24 October 2013 - 17:51

Or just save yourself the hassle and get "Chrubuntu" :)




#17 OP +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 24 October 2013 - 21:39

I have applied your update, and it works now. Do you think it would be wise to put the xserver packages on hold to prevent updates unless there's and update on your driver? I believe there's a way to create binary dependencies in deb packages so, in this case, if they were declared in your driver, no updates to xserver would be applies until there's a new version of your driver. I haven't done that, but I could investigate it for you if you want.

 

Thanks so much for your great work.

 

Regards,

 

Ignacio

 

I do not recommend putting xserver-xorg-core on hold. Xorg 1.15 will not be released, not to mention packaged, until early next year, and X receives security updates often enough to make unequivocally sticking with an older version potentially dangerous. I will update xf86-video-armsoc again when new versions of X are released. Although I had to make some minor code changes which have not yet landed upstream in this case, next time it will likely be as simple as recompiling the driver against the new Xorg ABI. APT (apt-get, aptitude, or your other front-end of choice) will give you the option to either remove the broken driver or stay upgrading the X server until the conflict is resolved when Xorg 1.15 is eventually pushed to Jessie. Therefore you can avoid breaking X at that point by not upgrading it for a few days until I upload the new driver and the conflict is automatically resolved.

 

First thing I noticed after login is that there seems to be no HW accelerated graphics. Playing video is quite painful, I haven't even tried setting pepperflash. Are you running it under the same conditions?

 

Thanks,

 

Ignacio

 

Graphics are accelerated, but you only have partial 3D acceleration. Unfortunately there is no support for the Mali T604 in Mesa, and ARM's proprietary DRI library (at least the one that ships with the Chromebook) only partially supports 3D acceleration. Chrome OS works around this limitation by drawing everything in an OpenGL window using the completely functional OpenGLES acceleration. If you are interested in more details, read Ubuntu Bug #1085596.



#18 OP +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 24 October 2013 - 21:53

Or just save yourself the hassle and get "Chrubuntu" :)

 

Although ChrUbuntu is an easy way to install Ubuntu natively on a Chromebook, it is not equivalent to my method. The principal difference is that ChrUbuntu is designed to install Ubuntu onto an external device (such as a flash drive or an SD card) so it can be dual-booted with Chrome OS, whereas my tutorial details how to install Debian (although it could just as easily be applied to Ubuntu) to the Chromebook's internal SSD, completely replacing Chrome OS. As far as I know, the tutorial I posted in the opening post is the only one of its kind. The method is not particularly easy, and could probably be automated similarly to ChrUbuntu. Therefore it is not intended for the casual user. Its primary advantage is that the OS will run much faster from the internal SSD than from a flash drive or SD card. However, like you noted, there are some serious downsides to consider.



#19 Ignacio

Ignacio

    Neowinian

  • Joined: 18-October 13

Posted 25 October 2013 - 07:12

I do not recommend putting xserver-xorg-core on hold. Xorg 1.15 will not be released, not to mention packaged, until early next year, and X receives security updates often enough to make unequivocally sticking with an older version potentially dangerous. I will update xf86-video-armsoc again when new versions of X are released. Although I had to make some minor code changes which have not yet landed upstream in this case, next time it will likely be as simple as recompiling the driver against the new Xorg ABI. APT (apt-get, aptitude, or your other front-end of choice) will give you the option to either remove the broken driver or stay upgrading the X server until the conflict is resolved when Xorg 1.15 is eventually pushed to Jessie. Therefore you can avoid breaking X at that point by not upgrading it for a few days until I upload the new driver and the conflict is automatically resolved.

 

 

Graphics are accelerated, but you only have partial 3D acceleration. Unfortunately there is no support for the Mali T604 in Mesa, and ARM's proprietary DRI library (at least the one that ships with the Chromebook) only partially supports 3D acceleration. Chrome OS works around this limitation by drawing everything in an OpenGL window using the completely functional OpenGLES acceleration. If you are interested in more details, read Ubuntu Bug #1085596.

 

 

Ok. Thanks so much for your assistance. Debian runs quite fine, and your guidelines are impressive. Although its performance is not superb, it is usable, and it is more flexible than running ChromeOS.

 

Thanks again,

 

Ignacio



#20 vlotho

vlotho

    Neowinian

  • Joined: 17-November 13

Posted 17 November 2013 - 14:40

hi xorangekiller

 

i have a problem with a "wget -q https://dl.dropboxusercontent.com/u/62647756/repos/apt/debian/keys/xorangekiller.asc -o- | apt-key add -" line

 

i get "gpg: no valid OpenPGP data found" !!



#21 vlotho

vlotho

    Neowinian

  • Joined: 17-November 13

Posted 17 November 2013 - 19:23

i've try gpg --import xorangekiller.asc and it seemed to work but I get errors during apt-get update



#22 OP +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 17 November 2013 - 21:34

hi xorangekiller

 

i have a problem with a "wget -q https://dl.dropboxusercontent.com/u/62647756/repos/apt/debian/keys/xorangekiller.asc -o- | apt-key add -" line

 

i get "gpg: no valid OpenPGP data found" !!

 

The GPG key I use to sign my repository has not changed, nor has its location relative to the repository. However, I notice that the command you quoted is not the same as the one that appears in my tutorial. You replaced the uppercase "O" at the end of the wget command line with a lowercase "o". Since wget options are case-sensitive, as is true of most utilities, it is not surprising that the command you quoted does not work. You are told that there is no OpenPGP data to be found because that is exactly the case. Try the following command (which is the same as the one which appears in the tutorial in my opening post) instead.

# wget -q https://dl.dropboxusercontent.com/u/62647756/repos/apt/debian/keys/xorangekiller.asc -O- | apt-key add -

i've try gpg --import xorangekiller.asc and it seemed to work but I get errors during apt-get update

 

Although you successfully imported my public key into your GPG keyring using gpg --import, that is not relevant to APT. APT keeps its own keys in /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d. Therefore apt-get is not able to verify the signing key of my repository in your case because APT does not have my public key. If you wanted to isolate downloading the key and adding it to your APT keyring into separate commands, you could do so as follows:

$ wget https://dl.dropboxusercontent.com/u/62647756/repos/apt/debian/keys/xorangekiller.asc
# apt-key add xorangekiller.asc
$ rm xorangekiller.asc


#23 vlotho

vlotho

    Neowinian

  • Joined: 17-November 13

Posted 18 November 2013 - 05:22

actually, I had not thought about the capital o :) . the key is imported. at the end of the command it says "ok", by cons in the update, I still have errors on the deposit "unstable".



#24 OP +Karl L.

Karl L.

    xorangekiller

  • Tech Issues Solved: 15
  • Joined: 24-January 09
  • Location: Virginia, USA
  • OS: Debian Testing

Posted 18 November 2013 - 05:38

It sounds like apt-key added the repo key to your APT keyring this time. The only thing it is supposed to print after a key has been successfully imported is "OK".

 

That said, I have absolutely no idea how to interpret you new problem. I will try to help you, but you need to be precise! Based on the resolution of your last issue, my advice is to double-check that you typed everything correctly. This is Linux. Case matters. Spacing matters. My guide has been tested numerous time. It is unlikely that it has any major flaws in its current incarnation. (Although software is revved, and I am only human; so I'm not so foolish as to claim my guide is absolutely bulletproof.)



#25 vlotho

vlotho

    Neowinian

  • Joined: 17-November 13

Posted 18 November 2013 - 06:06

ok, sorry, this is all my fault and my carelessness ... the problem is solved



#26 yourmate

yourmate

    Resident One Post Wonder

  • Joined: 21-December 13

Posted 21 December 2013 - 06:36

Hi, xorangekiller.

 

My Chromebook is put on Developer Mode and i have "crossystem dev_boot_usb=1" set in Chrome OS in order to be able to boot self-signed kernels from USB/SD media.

If i'll set up Debian using your partition scheme, will USB/SD boot (with Ctrl+U) still work?

 

I'm asking because i've already tried a scheme with Debian on eMMC having just two partitions (one with self-signed kernel, second with rootfs), and while i was able to boot into Debian (with Ctrl+D), the USB/SD boot got broken.

 

Thank you!



#27 nowede

nowede

    Neowinian

  • Joined: 22-December 13

Posted 22 December 2013 - 13:06

Excellent description, thank you.

I am writing this using my Chromebook, debian installed.

Maybe the preparation of the internal ssd can be shortened by the following script:

 

#!/bin/sh

target_disk=/dev/mmcblk0
cgpt create ${target_disk}
cgpt add -i 11 -b 64 -s 16384 -S 1 -P 5 -l RWFW -t "firmware" ${target_disk}
cgpt add -i 6 -b 16448 -s 1 -S 1 -T 15 -P 0 -l KERN-C -t "kernel"  ${target_disk}
cgpt add -i 7 -b 16449 -s 1  -l ROOT-C -t "rootfs"   ${target_disk}
cgpt add -i 9 -b 16450 -s 1  -l reserved -t "reserved"   ${target_disk}
cgpt add -i 10 -b 16451 -s 1  -l reserved -t "reserved"   ${target_disk}
cgpt add -i 2 -b 16452 -s 32768 -S 1 -T 15 -P 15 -l KERN-A -t kernel ${target_disk}
cgpt add -i 4 -b 49220 -s 32768 -S 1 -T 15 -P 0 -l KERN-B -t kernel ${target_disk}
cgpt add -i 8 -b 81988 -s 32768  -l OEM -t data   ${target_disk}
cgpt add -i 12 -b 114756 -s 32768 -S 1 -P 5 -l EFI-SYSTEM -t "efi" ${target_disk}
cgpt add -i 5 -b 147524 -s 4096  -l ROOT-B -t rootfs ${target_disk}
cgpt add -i 3 -b 151620 -s 28870622 -S 1 -P 5 -l ROOT-A -t rootfs ${target_disk}

cgpt add -i 1 -b 29022242 -s 1755069  -l STATE -t data ${target_disk}
sync

mkfs.ext4 ${target_disk}p3
mkswap ${target_disk}p1

Norbert



#28 nowede

nowede

    Neowinian

  • Joined: 22-December 13

Posted 22 December 2013 - 22:47

Just checked it and:

Yes, booting from an SD card still works.

 

Norbert



#29 esbeeb

esbeeb

    Neowinian

  • Joined: 01-January 14

Posted 01 January 2014 - 15:39

Karl L.,

 

Firstly kudos for your excellent work so far.  :D

 

I'd like to understand how booting works, after one has followed your instructions.  Am I right that:

  1. The default "verified" uboot bootloader is not used (nor is the alternate "non-verified" nv-uboot bootloader? For more details on nv-uboot, please see "Appendix A: Using nv-U-Boot on the Samsung ARM Chromebook":
    http://www.chromium....-arm-chromebook ).  It seems you somehow use "firmware-linux" and "firmware-libertas" instead.  I've never heard of those (as I'm only familiar with how GRUB works, on PC's).  What are those?  What do they do?
  2. "firmware-linux" and "firmware-libertas" somehow boots a "stock" linux kernel that you compiled and packaged yourself, called "linux-image-exynos5" (as opposed to "borrowing" and "signing" the ChromeOS kernel, which is what one must unfortunately do using the current instructions found on "InstallingDebianOn Samsung ARMChromebook":
    https://wiki.debian....g/ARMChromebook
  3. When future versions of your "linux-image-exynos5" are released (say, because there was an important security update released for the kernel), they'll "just work" (at boot time), when one installs them with "sudo apt-get update && sudo apt-get upgrade"?

If I'm correct on these 3 points, then how were you able to "get away with" not using the nv-uboot bootloader?  That is to say, why couldn't the Debian folks follow suit and boot their own stock linux kernels with "firmware-linux" and "firmware-libertas" like you do?

 

Note: The Debian folks are currently stuck on how to boot a stock linux kernel from nv-u-boot, as seen on
"InstallingDebianOn Samsung ARMChromebook":

https://wiki.debian....g/ARMChromebook


  "Three partitions are created on the disk. In time, the intention is that these be used for:
   - a copy of nv-uboot that is chainloaded by the standard firmware,
   - a /boot filesystem containing the standard (non-ChromeOS) kernel, read by nv-uboot,
   - the root filesystem.

  Currently nv-uboot is *not* used, and so the arrangement is:
   - a copy of the ChromeOS kernel that is loaded by the standard firmware,
   - a /boot filesystem that is used only to contain the ChromeOS kernel (which is not used during booting, just during the preparation of the previous partition),
   - the root filesystem."

 

I would appreciate any clarification, as you seem to understand these things really well.  GPT and "verified" bootloaders are tough to understand, especially when it comes to how to boot stock linux kernels.



#30 esbeeb

esbeeb

    Neowinian

  • Joined: 01-January 14

Posted 03 January 2014 - 14:15

Karl L.,

 

Your work is much appreciated.   :woot:   I write this posting from my new Debian Jesse install on my Samsung ARM Chromebook.

 

A few things could be filled into your procedure:

  • Before doing step 2.3, you didn't mention how to get the Chromebook connected to one's wifi network.  Here's how I did that (well, I'm pretty sure these were the minimal steps that succeeded):
    • ifconfig mlan0 down
    • ifconfig mlan0 essid MySSIDsNameHere key s:MyWifiPasswordHere
    • ifconfig mlan0 up
    • (wait about 15 seconds for the wifi authentication to work)
    • dhclient mlan0
    • (wait a few seconds for a DHCP lease to be assigned)
    • ifconfig mlan0
    • (you should now see a valid DHCP-assigned IP address for "inet addr" on the second line)
  • Before you can do step 2.3, gdisk needs to be installed on the Debian-formatted SD card.  I installed it with:
  • Later in step 2.6, when I tried to run the command "umount /mnt/rar/dev/pts", it wouldn't unmount, as it was "busy".  Nothing except a reboot could clear this up.

I also answered my own questions above as to how booting works:

  • You've left the default uboot "verified" bootloader in place.
  • Your package linux-image-exynos5 provides a kernel which will work with that bootloader
  • To get the bootloader to boot that kernel, the "update-chromebook-vboot" had to be run, which came from your package "chromebook-kernel-vboot"