search

hexdump0815 / imagebuilder

velvet os - simple script framework to build ubuntu 22.04 lts jammy (in older versions also 20.04 lts focal) and debian 12 bookworm (in older versions also 11 bullseye) bootable usb / sd card images for some arm and intel devices - lots of prebuilt images as well
GNU General Public License v3.0
295 stars 44 forks source link

chromebook_snow: problem: Image boots but then tries to netboot #63

Open Martyn575 opened 2 years ago

Martyn575 commented 2 years ago

Hi,

I don't understand this and i didn't get any clarification from reading the md files, so i thought i'd ask.

I've got a Samsung XE303C12. I downloaded the bullseye image, write it to a USB flash drive. Booted off it.

It immediately began looking for a network interface. I got about 20 ethernet errors, and then it dropped me into some weird shell, and I don't know what this shell is. it doesn't seem like a linux shell, is it busybox or something? I have no idea? Because i don't recognise what it is, it's hard for me to get further information on what it is and how to use it.

So then rebooted it eventually (reboot / shutdown / halt) weren't recognised commands, so i found "reset" which rebooted the system. I plugged in an ethernet dongle and booted off the USB drive.

It immediately started to try and boot off a network server?

Is all of this expected behaviour? This seems really odd.

Is there some way to boot linux normally off the USB drive and get like an installer or something?

Well done on getting something bootable, i've been working with other linuxes for days and all of them have failed, usually because for various reasons files have been lost, and links to key files are broken, or things have stopped working over the years, or command parameters have changed.

Martyn575 commented 2 years ago

Solution:

Okay got it, the system was configured to boot from the MMC [SD card] rather than the USB, it's now booting up linux.

I just wrote the image to an SD card instead of a USB drive.

Now i just need to work out why systemd keeps segfaulting.

"condition check resulted in set up additional binary formats being skipped" Segfault. I'm guessing in fuse. SystemD helpfully decided to stop everything. Damn you systemd. "systemd: freezing execution"

Tried the ubuntu one, kernel panic.

This was on the latest version: https://github.com/hexdump0815/imagebuilder/releases/tag/220619-01

Also the shell was u-boot.

hexdump0815 commented 2 years ago

the errors look strange - i tested the images on my snow at least and they booted fine ... maybe the sd card is broken? do you have a chance to test it with another one? its always best to avoid no-name sd cards as i saw a lot of problems with those in various situations

btw. i also got those netboot problems from u-boot when the image was not properly written to the sd card or the bootloader could not read it properly - it looks like this device is quite picky about sd cards ...

good luck and best wishes - hexdump

Martyn575 commented 2 years ago

Failure: The test that was doing was with a brand new SanDisk Ultra 64GB Class 10 UHS 1 card. (C10, XC 1, A1, U1 64GB). This was a micro SD card in an adaptor, and it was consistently causing kernel panics and systemd freezing execution errors. I had opened this about 3 days ago and like all my flash was bought from a store (I've learnt the hard way in the past that Chinese counterfeit everything), and i'd been trying to use Arch on it, but due to broken links etc, missing files and broken kernels i was unable to, so it may have had some artifacts on there.

Failure: I then tried a Kingston 8GB Class 4 SDHC. This seemed to kernel panic a bit less but had timing issues with systemd and various kernel stuff. I can't remember what was on this card previously.

Failure: I then tried a Sandisk Ultra 30MB/s Class 10 SDHC 1 16GB, and that refused to boot at all, either flashed with dd / cat from linux or from Rufus under windows. It just consistently dropped me into a u-boot shell. Examining this card even though i had installed the image on it with rufus / cat, previously it had been an iso style filesystem. So maybe there was an artifact on there.

Failure: I had a second identical Sandisk Ultra 30MB/s Class 10 SDHC 1 16GB, to the previous. I was curious about the data artifact possibility, so this time i dd'd the entire sd card with zeros, before catting off the image to the sd card. This also failed to boot, and dropped me into a u-boot shell. It wouldn't even attempt to boot.

Success: I then tried a Sandisk Ultra 80MB/s Class 10, SDHC 1, 16GB card. Under debian it started to boot, but then it had the usual systemd crashes and eventual lockup. However under ubuntu it did actually start up and i got a gui after about 10-15 minutes. It asked me to enter the password. I did. It then loaded up a different gui, which was black with a mouse cursor on the screen, then it threw a framebuffer error on the screen, and x restarted. It was stuck in a loop like this. I couldn't stop the cycle so i powered off.

I booted up ubuntu again, and this time it didn't attempt to display the gui and eventually was dropped into terminal login prompt. Now i've to figure out how to install linux from the live cd linux prompt (since the installer / gui didn't load).

Anyway just leaving this here for information in case anyone else finds this useful.

Martyn575 commented 2 years ago

Update: the following subsequent 2 boots from the successful sd card lock up. It seems these SD cards get very easily corrupted.

Martyn575 commented 2 years ago

I'm so sorry to bother you, but do you happen to know which SD card you used when you successfully tested the system?

hexdump0815 commented 2 years ago

hi @Martyn575 - while reading this one thing comes to my mind: i once came across an old snow chromebook (must have been one of the first ones - you usually can see the manufacturing date on the label on the backside) and never got that one working stable with mainline linux - it was working stable with a chromeos based kernel ... i tried to find the reason for this and even compared parts of the kernel sources between chromeos and mainline and looked at the commit history of the chromeos kernel for fixed errata (this one: https://github.com/hexdump0815/linux-mainline-and-mali-generic-stable-kernel/commit/20342da0140d8bb69e6a362c8066e9517a2a975a is from back then) but did never get it really working stable with mainline and never found out what the problem really was ...

maybe give the legacy kernel a try - i just added a small section of how to use it here: https://github.com/hexdump0815/imagebuilder/blob/120a2db44ecd5e9b6abde8a8dc6d340580e118a2/systems/chromebook_snow/readme.md?plain=1#L60-L67

hexdump0815 commented 2 years ago

typo in the unpack cmdline - it should be: tar xzf boot/extra/kernel-chromebook_snow-legacy.tar.gz

Martyn575 commented 2 years ago

Hi @hexdump0815. I think i may have bought your old chromebook. Did it have a carbon fiber trackpad and lid?

Anyway i dd'd the kernel and shoved the card in, it booted up immediately with no issues whatsoever, it's booted up, it's not hemorrhaging stack traces and kernel errors, it boots quickly and efficiently.

There's been no kernel panics, no systemd lockups. I can't thank you enough :)

hexdump0815 commented 2 years ago

@Martyn575 - it was just a regular one, nothing special about it and i think there most probably were quite a few of those "special" snow chromebooks ... i guess it was some first production batch which had some hardware problems which were somehow worked around in the chromeos kernel ... there was even an updated ec firmware to fix some early hw problems, so i even updated that and it did not help, so looks like there were even several hw problems with snow ...

the snow chromebook was one of the very first ones and it looks a bit like they were still in the process of learning how to get chromebooks done well at that time ...

happy to hear that you have at least a working system now - i'll add a note about this problem with early snow chromebooks now that its kind of proven that there seem to be multiple of those around ... i think mine was from end of 2012 according to the production label

best wishes - hexdump

hexdump0815 commented 2 years ago

note added: https://github.com/hexdump0815/imagebuilder/commit/c209af1a2b0b2919a827e0db4b1a42f3be2240b5

now that i remember it: back then i even tried to disable the higher cpu frequencies, disabled one cpu core, disabled cpu frequency scaling at all, disabled the mali gpu completely and nothing helped - it must be some very complex bug somewhere deep inside ...

hexdump0815 commented 2 years ago

... just found my old notes - just for completeness, so that it is documented somewhere:

my snow was from october 2012 and this is about the one hw problem i found mentioned: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/release-R89-13729.B-chromeos-3.8/arch/arm/mach-exynos/bitfix-snow.c

things i tried without success:

update: this is the list of potential fixes in the chromeos kernel which might be related - searched in: https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/heads/release-R90-13816.B-chromeos-3.8/arch/arm/mach-exynos

more unlikely:

Martyn575 commented 2 years ago

Okay that's incredibly helpful, thank you. It's running stably so far. It's the difference between night and day honestly.

This one is marked January, 2013 model code: XE303C12-A01UK.

That A01UK, sounds pretty ominous.

I have to say there's something really nice about these machines though. It reminds me of the acorn risc pc laptops that we always wished existed back in the day :) It's also really nice that these things run cold too and don't need any airholes.

I can't thank you enough :) Okay so the next thing i need to do is fix this server, because in one of the 50 sd card images i made, I accidently "missed" and dd'd my boot partition on my server. That's fine, i'm old enough to know not to keep any data on /dev/sda ;)

Next step is installing on the hard drive... that's something i will have to research carefully. I'm guessing the firmware expects stuff in strange places on the hard disk...

Thanks again :)

Martyn575 commented 2 years ago

Update for anyone reading this: the install procedure above downgrades the kernel to 3.10.

For working networking etc (recommended) you'll also need to the 3.10 kernel modules, else you wont be able to update anything. These are found in the file:

kernel-chromebook_snow-legacy.tar.gz

Extract this, then your kernel modules are to be found in:

./lib/modules/3.10.38-cos-r91

So you'll need to copy this entire directory to your /lib/modules/ directory:

sudo cp -r ./lib/modules/3.10.38-cos-r91 /lib/modules/
sudo reboot

When the system returns you'll have working networking etc.