Acer CB5-311 with 1366x768 resolution

[rwalking]

Hello all,

I have been trying the nyan-big targeted Ubuntu ready made image file with my Acer Chromebook 13 but I get only white flickering displayed during boot then a black screen. I understand this is due to my Japanese model CB5-311 having a lower resolution (1366x768) to those CB5-311 which are sold elsewhere. I think the machine is otherwise the same in all respects regarding the Tegra K1 chipset. At least I get past boot and see something which is the furthest I have got so far!

I wonder if anyone here has any insights what would be required to change the display resolution? Can I modify the existing files on my SD card image or is this more involved? I tried modifying the file /etc/X11/xorg.conf.d/01-modesetting.conf to add: Option "PreferredMode" "1366x768" but this seems to not be the whole story and is overwritten by the system upon boot.

Thanks in advance, Rob

[hexdump0815]

hi rob,

does the u-boot prompt at least work? and afterwards you do not get any more display output or do you get the usual boot log but nothing when xorg is starting? you might also look in the later postings of this thread https://archlinuxarm.org/forum/viewtopic.php?f=49&t=12185 for hints and inspiration and you may try to give some drm and/or edid parameters like mentioned in the "forcing modes *" sections at https://wiki.archlinux.org/index.php/Kernel_mode_setting a try ...

good luck - hexdump

[rwalking]

Hello,

Thanks for the suggestions!

Well, I can only assume u-boot is working. I cannot clearly see any text. I don't get any beeps after pressing Ctrl-U so it seems the signing is as expected by Chrome-OS firmware and it proceeds to boot. All I can see is that the screen should contain white on black. Then after 9 seconds the screen stops flickering and goes black. I can only assume this occurs when xorg starts.

The arch install mainline I have been studying for sometime but no great victory as yet. I tried the procedure detailed (below link) a few times and it boots without firmware complaint but gives also a black screen but not even a flicker on screen: https://github.com/ldesousa/gnu-linux-on-acer-chromebook-13

I believe this may also be due to the different screen resolution....

I am hoping there may be some simple procedure to divert the output to HDMI which should be in common with the full-HD Acer CBR-311. Then other options will emerge.

From some other forum suggestions I also added the file : /boot/config.txt containing: hdmi_force_hotplug=1 hdmi_drive=2

But it seems to not enable HDMI output. I suspect as this file was not formerly present this is not the mechanism where this is defined in this system. I understand it would work for a raspberry pi.

I also tried editing at the end of /etc/lightdm/lightdm.conf adding:

xrandr --output eDP-1 --primary --mode 1366x768 --rate 60

This seemed to modify the style of flicker I see and add more colour. I am not sure where to set also the color depth which needs to be 24 bits.

I'll take a look at your link which is new to me.

Many thanks,

Rob

[rwalking]

Hi all,

Following the advice I received on Kernel mode setting I had another try to alter the graphics setup to suit the Japanese Acer CB5-311-H14N. I am totally new to this but had a go. Although it still did not fix the display I am reasonably confident the following should have worked. So I am posting here in the hopes of further enlightenment!

I extracted an edid using this procedure from within my existing ubuntu booted using crouton:

Used program "get-edid" to extract the edid for the display. Then used parse-edid on the resulting binary to make a readable text file.

https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/sysutils/busybox/scripts/getedid

Then used this program to convert the Modeline data from parse-edid output into an actual edid file:

https://github.com/akatrevorjay/edid-generator

Then I edited the files inside the debian binary which I had burned to my SD card. Following advice from many sites:

I put the new edid binary inside /lib/firmware/edid/filename.bin

I used filename: 1366x768.bin

Inside the boot partition, I edited line 3495 of config-5.4.35-ntg-cbt+

which has:

CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

And changed it to:

CONFIG_DRM_LOAD_EDID_FIRMWARE=y

I appended to the existing bootargs inside /extlinux/extlinux.conf to point to the new edid file:

drm_kms_helper.edid_firmware=edid/1366x768.bin I tried the above first and then also the below version:

drm_kms_helper.edid_firmware=LVDS-1:edid/1366x768.bin video=HDMI-1:D

But neither seems to change the display setup so I think I must still be missing something. The second drm_kms_helper.edid-firmware setting I put together from looking at the below link

https://libreelec.wiki/custom_edid

So to summarize, I feel close but no cigar yet. From my present level of understanding (admittedly limited) I guess that the existing image which I downloaded from:

https://github.com/hexdump0815/imagebuilder/releases/tag/200526-01

Loads the display setup from the dtb file for the entire board:

dtb-5.4.35-ntg-cbt+/tegra124-nyan-big.dtb

So I guess another approach would be to find the appropriate dtb for this version of CB5-311. Although Crouton seems to have no problem installing Ubuntu on this machine there seems to be no mention on Chromium projects of the different resolution version of machine (see below).

https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-cb5-311-chromebook-13

I will keep thinking. Thanks in advance for any further insights - Rob

[hexdump0815]

hi rob,

sorry for the late reply. i think your system seems to fail already at the u-boot stage i guess, as you should see a u--boot menu on the screen first - as this seems to not be the case for you it looks like u-boot cannot initialize the screen properly neither. there are two things you might try coming to my mind: first - how much memory do you have - 2 or 4gb? if 2, you might try to build u-boot following https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/readme.cbt and omit these two lines https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/misc.cbt/lpae-and-spectre-mitigation.patch#L9-L10 ... the second thing would be to start experimenting without u-boot, i.e. building a kpart format kernel, which you dd directly onto the first chromeos kernel partition ... here are some old notes from me to build such a kernel: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/blob/master/readme.cbt#L29-L37 - you'll have to adjust some paths, all the files needed should be in the misc.cbt dir next to that readme and the cb-tools you may take from the chainloading repo mentioned above ... for the kernel sources to use better use https://github.com/hexdump0815/linux-mainline-tegra-k1-kernel as this is tested to be working at all at least on my model (some kernels do not work at all) and if you have 2gb only you might play around with removing https://github.com/hexdump0815/linux-mainline-tegra-k1-kernel/blob/master/config.cbt#L354 ... but all this is just wild guessing ...

good luck and maybe post updates here in case you find something out - hexdump

update: looks like i even left the kpart kernel build parts in the new readme with still wrong paths it seems https://github.com/hexdump0815/linux-mainline-tegra-k1-kernel/blob/master/readme.cbt and the files needed seems to be in misc.cbt in this repo too ...

[tenJirka]

I know it is long time past your problem, but I found this. I think that screen size isn´t problem here. I succefuly boot from the SD card on cb5-311 with 1366x768 screen without any trouble. I don´t know why your chromebook didn´t, but it´s probably not becouse of screen size.

But, exactly the same behavior of screen I got, when I tried to flash the image to USB and boot from it. It just flickering and than show just black screen. Also the diod on the USB dont shine anymore, so I thing the booting failed.

I would like to boot from USB, becauseI can use ssd, which is faster than card, but at this time, I´m not able to do that.

[hexdump0815]

@stehji - oh this is good news ... i think for your use case you might simply boot from sd card and then run the rootfs from usb - you'll just have to adjust the root= parameter in the extlinux.conf file and the fstab on the root filesystem accordingly and it should work.

best wishes and good luck - hexdump

[tenJirka]

@hexdump0815 It doesn't seem to be working, I deleted 16M partition with uboot and kernel partition from USB to prevent booting from it and then i changed root partition uuid (on the USB) to prevent mismatch when booting. Then I edited extlinux.conf in the SD card and fstabs. I tried write the partiion uuid to extlinux.con and after that even /dev/sda4. When I press crtl+u, it do the same, when I tried to boot from USB and then it stay black screen forever. I tryed what will happend, if i don´t connect the usb and result was the same. So i think there is some problem with locating root partition on the USB? It looks like the USB ports isn´t even powered if the screen flisckering ends and the screen go black. Is it possible?

I swiched the extlinux.conf back and concentrate on the light on the flash disk (and on the ssd adapter too) a found, the diod goes black when the flickering gone and light up after the kernel modules is loaded, so it even cant bee mounted, because they are without power. I think.

I forgot to mention it earlier, when i boot from the sd, the screen is flickering for 10 sec, than go black for 4 or 5 secs and then light up with system booting up.

[hexdump0815]

maybe first rry to get full sd card booting working again (its always easier to debug form the working end), then maybe create an mbr partition table on the usb drive (that should not be consiered by the boot loader - be sure to completely erase the usb drive before or at least the beginning and the end of it as gpt partition tables have a backup copy at the end of the disk which might confuse things) and then switch the root partition in the extlinux of the sd card and the fstab on the usb disk and see if it boots this way.

it could be that some usb stuff is initialized too late, but i guess the initrd should have everything required in it, but maybe it does not.

the flickering and short black pause of the screen on boot are normal.

good luck and best wishes - hexdump

[rwalking]

Hi all,

This is encouraging news that 1366x768 resolution CB5-311 can boot the image. To stehji, if I may ask, are you burning the straight image from hexdump0815 project to the SD card? Or is a separate step necessary to add "signing" to get it to boot in the chromebook? Is developer mode setting required under chrome OS? Sorry it's been a while....

So far I just tried writing the image directly to my SD card under a separate intel linux machine in the following manner:

sudo dd if=chromebook_nyanbig-armv7l-debian.img of=/dev/mmcblk2 bs=1M conv=fsync

However it seems not immediately booting. But I forget the steps necessary to get this to boot. I have not looked at this in some time I'm afraid. A few notes on how you are burning and booting the image would be much appreciated! Thanks in advance,

Rob

[hexdump0815]

@stehji - it looks like there is some special xusb.bin firmware required for the usb3 controller to work well - maybe this one is somehow missing in the generated initrd image and thus using usb as root fs does not work ... i have put it onto my list of things to check and will try to have a look at it, but it might take some time ... in case you have any update regarding this issue meanwhile i would be happy to hear about it here :)

[tenJirka]

Hello @rwalking Yes, I burned the straight image from hexdump0815 to the SD card. I used the balena etcher instead of dd, but that shouldn matter. Now i´m using windows on my pc, so etcher was the easyiest way. And also yes, on chromebook you have to enable developer mode and also the USB booting. It is described here: http://dev.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-cb5-311-chromebook-13 Than i just inserted the SD, power off, turn on, pres ctrl + U and wait. After about 10 sects will linux start loading.

Good luck Jirka

[hexdump0815]

@stehji - it looks like your not working usb rootfs is really related to the /lib/firmware/nvidia/tegra124/xusb.bin firmware missing in the initrd image - i noticed this too when building tegra-xhci not as a module while trying to get v5.10 working ... if you have some time and energy it would be cool if you could try to add that firmware and see if you get usb rootfs working this way - a good starting point might be: https://wiki.debian.org/DebianInstaller/NetbootFirmware

[tenJirka]

@hexdump0815 I´a m bit confused now. Because I decompressed the initrd.img file and the /lib/firmware/nvidia/tegra124/xusb.bin was there. So, what does this mean? Did I misunderstand how you mean it? (Sorry, my english isn't really good, i know)

[hexdump0815]

oh - i did not expect this - this is strange - then it should actually work ... ok - will have to look deeper into this whenever i find some time

[hexdump0815]

@stehji - in case you have a spare sd card around, it would be nice if you could give my new experimental nyan image a try from https://github.com/hexdump0815/imagebuilder/releases/tag/210314-01 and let me know if it works for you with the non-full hd screen ... does your nyan have 2 or 4gb ram btw.?

a lot of thanks in advance and best wishes - hexdump

[tenJirka]

@hexdump0815 I have bad news. It doesn´t boot up. I tried the same flash procedure like before, but I get the same result like when I was booting from USB or like rwalking.

[hexdump0815]

@stehji - can you please describe in more detail the exact result of trying to boot, i.e. do you see anything on screen or nothing at all, will the display backlight be on or off - if you get something on the display, do you see u-boot output then? you had it working before when booting an older image from me on that system - right?

[tenJirka]

@hexdump0815 yeah, sorry. After the flickering end I dont see anything on screen. It is completly turned off, without any backlight. The preveus release from 26/05/2020 is working fine on that system. Earlier I also tried the script from master release, which is making images, and these work for me also. And I also tried swithing to 5.4.84 kernel and it worked too. But this beta image don´t. I would like sent more info, but i don´t know why it doesnt boot.

[hexdump0815]

@stehji - thanks for the info ... you said that you used the script from master branch - does it mean that you can and are building images yourself (that would be very good)? do you still have chromeos on the chromebook on emmc? if yes: is it updated to the latest version (just to be sure we have the latest firmware etc. on it)?

for me the new image was booting fine, so we need to find out why it does not work for you. can you maybe try to dd the first partition (i.e. u-boot) of the working sd card to the first partition of the non working one? if its unclear how, please let me know and i can describe it. are both sd cards you are using of the same brand? - i had on other chromeboos the effect that booting works with one card and not with another ...

the difference between old and new is that they have a slightly different partition layout (two 32m kernel partitions instead of one 16m one) and maybe i did rebuild he u-boot between them.

[tenJirka]

@hexdump0815 I used the script once and it worked, after that I did´t need to use it again. But yes, i can build the image myself. I have and I´m using the latest stable version of chrome os (77.0.3865.120) for my model which is CB5-311-T23S (I don´t know if it is same for full hd version).

I tried to dd the partitions (dd if=/dev/sda1 (the firt partition from the old image, from usb) of=/dev/mmcblk1p1 (to SD card)) but it didn´t change anything. (If I did it wrong, please let me know, I´m not used to use dd very much.) I also tried to edit the extlinux.conf - the rootpart from LABEL to PARTUUID, but it also didn´t help.

[hexdump0815]

@stehji - looks like someone else also had problems to get the new image booting well, so i'll have to look into this and hopefully will prepare a new image soon

[hexdump0815]

@rwalking - in case you tried the 200526-01 debian image, then please give the ubuntu image of that version a try - i just had a report that the debian one did not work for at least one user - the ubuntu image from 200526-01 worked in that case, so maybe it will work for you too?

[hexdump0815]

@stehji @rwalking - a new image is ready, based on v5.10.25 - for me it works perfectly fine, only the console sometimes remains blank, but x11 is starting well and visible after about 1-2 minutes ... would be nice if you could give it a try (there is no hurry to do so)

https://github.com/hexdump0815/imagebuilder/releases/tag/210321-01

[rwalking]

Hello all. Thank you for your updates. To @hexdump0815, I tried the latest release image and I find the same result as @stehji. Therefore I think I want to try the same release as @stehji when I can find where this is. Until today I did not look at different releases.

I have had some confusion setting my chromebook again in developer mode but think I am back on track now. I followed the initial steps here:

https://dev.chromium.org/chromium-os/developer-information-for-chrome-os-devices/acer-cb5-311-chromebook-13

However to add to the above link (maybe for others who have same issue as I just did) I now remember you need to login at the terminal as chronos otherwise the commands will not work.

1. enable dev mode.
2. Upon reboot, no need to login, just press ctrl-alt and forward arrow to go to terminal after reboot
3. login as chronos
4. sudo enable_dev_mode_usb_boot (The command: sudo chromeos-firmwareupdate --mode=todev appears to not work on this chromebook)
5. reboot by pressing power key only
6. it should have exclamation mark screen with "OS verification is OFF"
7. press ctrl and U to boot from USB

I am confident it is then booting the USB, I want to try the earlier image now.

Cheers - Rob

[rwalking]

By the way, is there an already made binary for the nyan release on 26/05/2020 or do I need to build it? @stehji did you use Ubuntu or Debian? I am not so familiar with where to find things on Github yet. Thanks in advance!

[tenJirka]

@rwalking yeah, there already is prebuild image: https://github.com/hexdump0815/imagebuilder/releases/tag/200526-01 And I´m using ubuntu, acutally i did´t even try debian. Good luck!

[tenJirka]

@hexdump0815 I tried the lastest beta image and it still isn´t booting up. But this time, sreen goes off after flickering, and than after just a second it bright up (black) again, but nothing showed. Then the backlight will stay on for ever, but nothing else. I was wainting about 10 mins, if the x11 will start, but no. I thought if it wasn´t just prolem with incompatible screen, so I connect the SD to my PC to check logs, but in the /var/log directory aren´t any logs from boot procedure, any errors from lightdm or gdm3. I found only logs from apt, which was created when image was creating. So it probably isn´t just screen problem.

Now I noticed you asked me about SD card before, I overloked it before, sorry. I´m using samsung evo plus 128 GB, it should be class 10. I did´t try another one, because I have only more of these for my raspberry, and the another SDs which I have is class 4, and it is too slow for running system.

[hexdump0815]

@rwalking - the link from above is correct - please try to test the ubuntu image as for someone else the debian one did not work, but ubuntu worked

@stehji - this is really strange - can you maybe try one of those class-4 sd cards even if they are too slow? they are at least good enough for doing a/b testing with different sd card types :) ... what kind of sd card are you using for your working setup with the old image? ... btw. 128g cards might be problematic as i guess the nyan will not support anything larger than 32g, but on the other side u-boot seems to boot

my booting usually looks like this: a) working console: u-boot comes up and showing its menu after some screen flicker, short moment of black screen then console output starts ... b) non working console (happens randomly): u-boot comes up and showing its menu after some screen flicker, afterwards screen remains dark for about 1-2 minutes and then x11 (lightdm) is visible on the screen

[rwalking]

Hello all, I can finally report a booting linux from the SD card!

I can get to the login screen and see terminal clearly while booting after some initial screen flashes at early start. The one which I had success with is the Ubuntu of 27th May 2020 like @stehji . The Debian of the same release date does not boot. So very exciting, finally there is some hope of this nice machine being something other than a google infested brick! Thanks guys for your insights.

Just another hopefully trivial question - how do I actually login?! - Cheers

[rwalking]

Please disregard the last question - I see password is "changeme" after RTFM. So far it looks really nice! Thank you for all your efforts with this project : )

[hexdump0815]

@rwalking - this is good news indeed ... did you maybe also tried my latest image from a few days ago as well?

[rwalking]

@hexdump0815 , yes I will give the latest Ubuntu a try when I get the chance. At present I notice headphone socket does not switch sound over, and keyboard needs to re-map as well as special function keys like volume. But it is looking good. I was also reading this page where it is mentioned headphone jack and keyboard under an Arch linux case:

https://www.tbi.univie.ac.at/~ronny/acer-cb5-311.html

When I run the command: pacmd list-sinks I do not see the list of ports as in above link example, though possibly setup is completely different in Ubuntu case? Sound through the speakers and everything else works great.

[rwalking]

Hello, I can report latest release image seems to boot to black screen as before after initial flashes. Wondering if this is Ubuntu or Debian not clear to me. Let me know if there is anything that would be useful to look at such as logs on the SD card.

[hexdump0815]

@stehji @rwalking - i think you both now have a working 5.4 version - could you maybe try to unpack that kernel tar.gz (https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/releases/tag/5.10.25-stb-cbt%2B) in / and create an new additional /boot/extlinux/extlinux.conf entry for it and see if that will boot fine or not? this would help to find out if the problem with the latest image is more with the image or with the kernel ... this kernel should happily coexist with the existing 5.4 kernel, so there is no risk to break the running system

@rwalking for the proper audio setup some further tweaking of the ucm2 files for the nyan-big in /usr/share/alsa/ucm2 is most probably required

[rwalking]

@hexdump0815 another question if i may. For the booting image I tried to make the root partition larger (I only had half a gigabyte free) on another Intel machine using gparted, however unexpectedly (to me!) it does not boot after this operation. Is it required to re-run the generation script to re-make the image to do this? In the scripts it mentions it can only be re-run on the same architecture so I take it to mean I can't do it on my Intel lubuntu machine. Considering using my raspberry pi 4B instead.

I will have a look at your kernel question as soon as I am able. Cheers

[hexdump0815]

@rwalking - the old image should have a script to extend the root fs in /root - just run it on the booted system and it should extend the root fs ... in the latest images this script is in /scripts now

[tenJirka]

@stehji @rwalking - i think you both now have a working 5.4 version - could you maybe try to unpack that kernel tar.gz (https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/releases/tag/5.10.25-stb-cbt%2B) in / and create an new additional /boot/extlinux/extlinux.conf entry for it and see if that will boot fine or not? this would help to find out if the problem with the latest image is more with the image or with the kernel ... this kernel should happily coexist with the existing 5.4 kernel, so there is no risk to break the running system

Hello, i´m sorry for really long delay, I had a lot of work, school and another thinks to do, and didn´t have enought time. But today i tried the 5.10 kernel with the old image and it didn´t boot. Boot process was exactly same, like when I tried to boot the newest image. So it seems like the kernel is the problem.

[hexdump0815]

the long delay is not a problem at all ... i did some more tests recently and i think the problem are some boot order/dependency/timing issues around the drm system ... i got xorg working reliable even with 5.10 if i disable CONFIG_DRM_FBDEV_EMULATION, but then there is no console and not vt's anymore ... the problem seems to be the probing order of the tegra drm driver and the fbdev drm emulation, one way around it works and the other way around not - with 5.4 i'm alwys getting the proper order, with 5.10 its sometimes so and sometimes so ...

[hexdump0815]

i was able to get a 1366x768 model with 2gb ram myself, so i should hopefully be able to debug this one a bit more in detail now :)

[hexdump0815]

@rwalking @stehji - i have built a new image, which should work with both the 2gb and the 4gb version - the 4gb version should work out of the box and for the 2gb another u-boot image needs to be dd'ed to the first partition after writing the image to the sd card ... on the 2gb version u-boot seems to not be able to initialize the display yet, so there is nothing to see from u-boot, but it works and will boot the kernel properly (one can even blindly select a kernel when entering the number at the right time :) ) ... i went back to the v5.4 kernel for now as the display/drm initialization is too unreliable right now for v5.10 and newer ... here is the new image and it would be nice if you could give it a try and let me know if it works for you: https://github.com/hexdump0815/imagebuilder/releases/tag/210613-02

[tenJirka]

Hi @hexdump0815 . I tried the image. U-boot works (I have the 4GB, so I didn´t do anything with it) and kernel load, but the system will not boot up. For some reason the boot will stuck on "Waiting for root device LABEL=rootpart...". Something strange is happening with the disk parts when the system is booting. I will try edit the extlinux.conf later and modify it from LABEL to partition uuid and try that. But for now the ubuntu will not boot up out of the box.

P. S. I tried your 5.4.125 kernel yesterday and it work really well for me. So I think, if i edit the extlinux.conf, it will boot.

[tenJirka]

@hexdump0815 so i tried it but it didn´t help. I got "---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,4) ]---" Is posible, it have something to do with change filesystem from ext4 to btrfs?

[hexdump0815]

@stehji - this sounds very strage - can you please try to write the 4g u-boot image to the first partition? i did test boot the image with the 2g u-boot successfully on the 2gb chromebook and then the one with the 4g u-boot successfully on the 4gb chromebook ... what you see sounds like the kernel is written as kpart image to the first partition, which should not happen due to the scripts ... i'll download the image and test it directly on my 4gb chromebook too ... thanks for the feedback

[tenJirka]

@hexdump0815 - so i tried what you wrote and the result doesnt change. Is there any easy way how to edit your script to make ext4 partition instead of btrfs? I would like to try that. Like I said before, now I´m using the 5.4.125 kernel with the image from 26/05/2020, upgraded to ubuntu 21.04 withou any bigger issues (a had to disable novuea).

[hexdump0815]

@stehji - i just downloaded my latest nyan image from https://github.com/hexdump0815/imagebuilder/releases/tag/210613-02 , wrote it straight to an sd card and booted it on the 4gb nyan and it booted fine (only that even with the v5.4 kernel the text console sometimes still seems to stay blank) ... it is very easy to build the image with ext4 rootfs: just change this line to ext4 - https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_nyan/partition-mapping.txt#L2 ... then the framework will create an image with an ext4 root fs - i have just tested this to work perfectly fine for the spring chromebook where i currently have to use an old legacy chromeos kernel without good btrfs support as mainline is not yet ready for it

[tenJirka]

@hexdump0815 - it´s really interesting. Well I will try to make image with ext4 in next days and i will inform you. Thanks for help.

When you mentioned the text console is staing blank sometimes for you, it isn´t hapening on my chromebook with 5.4. It always show. Just fact, i dont know if it means something.

[hexdump0815]

@stehji - thanks for testing ... the blank console seems to be a timing issue due to parallel probing of the drm drivers - i guess there is some dependency missing and they are makeing this probing more and more async in mainline ... due to the timing nature it might vary even between different devices - on the same chromebook 5.4.125 is running with stable console if i run it from emmc :)

[tenJirka]

@hexdump0815 - hello again. I think I have some really interesting news, at least for me. So, i created and image myself (your script is excelent, thank you for it) with ext4 instead of btrfs and writed it to the SD card. The firt boot with original extlinux.conf on bootpart ended like before: "Waiting for root device LABEL=rootpart...". So i edited the extlinux.conf with partition uuid insted of label and this time it worked. Ubuntu booted up just fine. That mean 2 thinks. Booting with root=LABEL=... in extlinux.conf don´t work for my chromebook and the brtfs filesystem either. I don´t know why, but I can´t imagine another reasons why it is working with ext4 and partition uuid.

[hexdump0815]

@stehji - it will not work with root=LABEL if no initrd is used (as LABEL would be evaluated in initrd only) and the same would explain why it would not work with btrfs (in my current kernels i have enabled btrfs=m and thus it needs initrd to mount root) ... the question is why it is not using the initrd on your chromebook assuming you are using the default image setup with a u-boot kpart image in the first partition (which then would load the initrd) ... the only explaination i might find is that you maybe have an older buggy bootloader (depthcharge) which fails to load the usually larger initrd image and boots then without it ... does your extlinux.conf look like this? - https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_nyan/extra-files/boot/extlinux/extlinux.conf ... things to watch out for would be "noinitrd" on the cmdline or maybe you use some other dtb, which defines it in the chosen bootargs?

[tenJirka]

@hexdump0815 - extlinux.conf looks exactly like yours. I edited online the root=... . So the problem shouldn't be there.

I don't know which version of bootloader do I have on my Chromebook and I've never listened about updating it. Is it possible? I have latest stable beta version of chrome os on the Chromebook (if it have something to do with it)