coreboot December 2017

coreboot@coreboot.org

68 participants
177 discussions

Optiplex 790 now has preliminary support by coreboot
by Taiidan＠gmx.com 15 Jan '20

15 Jan '20

https://review.coreboot.org/21774 In case anyone else didn't notice - It is a sandy/ivy system with IOMMU. This is great and should help get coreboot in to the corporate user world.

2 1

Lenovo T410 Coreboot
by A. Veek 14 Dec '18

14 Dec '18

2 1

FOSDEM Hardware Enablement Devroom
by Paul Kocialkowski 04 Dec '18

04 Dec '18

A Hardware Enablement devroom will be taking place at FOSDEM this year, on Sunday 10 December 2017. This newly-created devroom is the result of 3 proposals that were merged together. It is co-organized by several individuals. The devroom covers all aspects related to hardware enablement and support with free software, including aspects related to boot software, firmwares, drivers and userspace tools and adaptation. Proposals for talks related to these topics are welcome and can be submitted until Sunday 26 November 2017 via the pentabarf interface. Short talks are encouraged over longer ones in order to cover a wide range of topics. The announcement for the devroom, that contains all the useful information, was published at: https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html Cheers and see you at FOSDEM! -- Paul Kocialkowski, developer of free digital technology and hardware support Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

3 3

Interested in offering motherboards for autotest
by Jeremy Banks 20 Jan '18

20 Jan '18

Hello, I have some older motherboards I'd like to offer as QA targets for autotest as described in the Testing section of Development Guidelines on the wiki.[1] They are older boards, ranging from Slot 1 to Socket AM3. Would the coreboot team have any interest in these, or are they too obsolete to serve as QA targets? Assuming there is interest, what is required for an autotest setup? The wiki says "a permanent connection to the net, a host system and some special circuitry," are required. How permanent of a connection is required? Is something like a cable or DSL line in the US sufficient, or is something closer to leased space at a datacenter facility needed? Are there any particular requirements of a host system that necessitate a particularly powerful system, or would a small single-board system like a Raspberry Pi suffice? Regarding the special circuitry: I assume this includes equipment for flashing the ROM chip on the motherboard under test, a means of controlling at least the motherboard's power switch and reset line, and something to monitor output from the board so to verify it did boot successfully (serial port?). Is this roughly accurate? Are there other bits of the special circuitry that I am missing, or specific brands/models of tools required to implement the special circuitry? Regards, Jeremy Banks 1. https://www.coreboot.org/Development_Guidelines#Testing

1 1

EARLY_CBMEM_INIT for Geode LX platforms
by Michal Zygowski 07 Jan '18

07 Jan '18

Hello Everyone, As a result of incoming 4.7 release many boards are going to be deprecated. We would like to support alix platforms which are based on Geode LX and yet not EARLY_CBMEM_INIT enabled. We have all hardware at hand and would gladly bring these platforms up to current standards. We saw that Kyösti Mälkki did a lot of good work for other AMD platforms and even offered to help with implementing EARLY_CBMEM_INIT on Geode. Unfortunately the thread died: https://www.mail-archive.com/coreboot@coreboot.org/msg50205.html Could You give us any tips where and how to start? AFAIK it is about calculating the top of RAM and recovering the cbmem on S3 resume (am I wrong?). I have already tried to implement it, but when trying to get timestamps with cbmem, it complains that it could not find timestamp table (did not even get error with cpufreq missing as this module occurs to be a problem on Geode). Has anybody maybe done some work yet? Best Regards, --- Michał Żygowski https://3mdeb.com | @3mdeb_com

3 2

Disabling ME >= 6.0 < 11 via the AltMeDisable bit
by Denis 'GNUtoo' Carikli 31 Dec '17

31 Dec '17

Hi, As I understand it: - For ME < 6.0, the ME firmware can be removed totally, and still have a functional computer. - For ME >= 6.0 (Nehalem) to ME < 11 (Broadwell), the All ME firmware can't be totally removed: the BUP module is required to have a functional computer. For such Firmware/Hardware versions the BUP does "Bringup (hardware initialization/configuration)"[1] - For ME 11, the following modules are required to have a functional computer: RBE, BUP, kernel and syslib. For such generation, setting the HAP bit only tells the firmware not to load extra code (At that point the kernel is already loaded). I've some questions regarding the above: - Is there more details than "Bringup (hardware initialization/configuration)" for what the BUP partition does for the ME >= 6.0 and < 11. - With the ME >= 6.0 and < 11, what does the AltMeDisable bit really do? Do we have some insights that tend to show that the execution is stopped, or not stopped? References: ----------- [1]https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf Denis.

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 30 Dec '17

30 Dec '17

Hello Philipp, Philipp Deppenwiese wrote: > There is already an easy solution. Just tell your customers that you will make the coreboot implementation open source (hw init). > They can load their own proprietary stuff afterwards as payload (binary) without having issues with the GPLv2. > Sure if they use SeaBIOS it's a problem (GPLv3) but there are tons of payloads out there. Our customers will never load their own payload. Our systems always boot to our own OS, which manages the measurement hardware and data processing side of the customer application. Our customers send relatively simple scripts to our systems that tell them how to manage the real-time, control, and signal processing portions of the application, while they typically have a relatively complex application-specific human interface application that runs on the host OS, typically operating under Windows, but sometimes operating under Linux (these few customers operating under Linux, obviously, will not have any trouble with GPL). Most customers want our system to “just work”. They send our system a PID() command, say, and it runs a PID loop for them until they tell it to stop. They do not dig down into the boot process or load a different OS. > coreboot makes things cost effective because we are all working together on the platform support. > Another good reason for not reinventing the wheel again :) > Even Siemens uses coreboot + SeaBIOS -> https://www.youtube.com/watch?v=tq4xSipCWEU > without having the "fear" of licensing issues. Sure they are not selling it to end users. On a quick look at the Siemens website for this product, this definitely looks like a good example of a product that matches what we do quite well, though I suspect they aim at much bigger customers than we do. With a few minutes spent looking, it is not at all clear to me how Siemens handles their GPL responsibility and whether they attempt to provide compliance for their customers or not. > If you want to make it easy for them. Upstream open source as much as possible. > If it is already there people will stop asking your customers for the source code! > Also if they use a custom payload without GPL code they don't need to open source it! We will definitely push any changes we make back to Coreboot or SeaBIOS to accept or reject. Best Regards, Ian

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by Lewis, Ian (Microstar Laboratories) 30 Dec '17

30 Dec '17

Hello David, David Hendricks wrote: Ø Did you actually need to change coreboot or SeaBIOS? If so, how extensive were the changes? I am guessing that the boot firmware isn't considered to be part of the high-value IP of the product - that is presumably in your OS. No. We have made no changes. At the moment we do not even know how to build the required modules for the system. Personally, I would rather we did not have to know how to do a build, but I think we will need to so that we can validate that the source code matches the binary we distribute. Even once we do work out how to do a build, I very much doubt we will make any changes at all. If we do change anything in coreboot or SeaBIOS – or any other GPL licensed project for that matter, we will definitely release our changes back to the relevant project to accept or reject. Ø Your idea about using the "About" tab to inform the user about the licenses and where to find the code is good. It should cover your company even if the customer never reads it. If this is correct, and an About tab with all the relevant information about coreboot and SeaBIOS meets our – and our customer’s – licensing responsibility, then we clearly can do something that will work well for our purposes. And, the issue becomes purely one of engineering work and administration in production. Ø Like you say, the goal here should be to make it so that downstream customers don't need to think about this stuff. The nice thing is that if you act consistently with the spirit of the open-source licenses then this should all be simple for them and for your company as well, and you get to spend more time engineering and collaborating and less time worrying. Once I have an idea what I am talking about, I may spend less time worrying. Ø Just my $0.02. Please make sure to consult your company's legal department before acting on anything you read in this thread (or elsewhere) :-) :-> Ian

1 0

Re: [coreboot] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system
by David Hendricks 30 Dec '17

30 Dec '17

Hi Ian, Did you actually need to change coreboot or SeaBIOS? If so, how extensive were the changes? I am guessing that the boot firmware isn't considered to be part of the high-value IP of the product - that is presumably in your OS. If you can publish the coreboot and SeaBIOS code on your website (it could be a zip file or something) then things should be reasonably simple. Even better would be to add the mainboard support to upstream coreboot or fork upstream coreboot on github and then add your patches on top. Then downstream customers can then easily download the code and, if needed, modify and commit their patches to the same codebase as to be in compliance in the same manner as you. Your idea about using the "About" tab to inform the user about the licenses and where to find the code is good. It should cover your company even if the customer never reads it. You shouldn't need a clickthrough license or anything (gnu.org has a FAQ that covers that topic: https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html). Also, the "conspicuous" requirement should already be met with the license information that exists in the header of each source code file and/or a LICENSE or COPYING file. As Peter mentioned that is exactly how the requirement is met for large companies who work with open source software. Like you say, the goal here should be to make it so that downstream customers don't need to think about this stuff. The nice thing is that if you act consistently with the spirit of the open-source licenses then this should all be simple for them and for your company as well, and you get to spend more time engineering and collaborating and less time worrying. Just my $0.02. Please make sure to consult your company's legal department before acting on anything you read in this thread (or elsewhere) :-) On Fri, Dec 29, 2017 at 6:21 PM, Lewis, Ian (Microstar Laboratories) < ilewis(a)mstarlabs.com> wrote: > ron minnich wrote > > how are you different in this case from Motorola, who had to put their > linux source on a web site? companies resold motorola phones. Or the many > switch vendors who sell network switches that run coreboot/linuxbios? or > irobot, who use it still on the packbot? > > Or how are you different from just about every vendor that sells > embedded ARM boards that run u-boot? > We are, because of the nature of our customers, very different from all of > your example use cases, except perhaps the people who sell embedded ARM > boards. > > Motorola phone: They sell their product to people (well, companies) who > set out to make GPL licensed products, typically for a large market. The > customer of Motorola makes no modifications to the Motorola phone, or at > least no significant modifications. There is no difficulty for such a > prospective reseller of such a product to comply with GPL. There are lots > of sales to cover the initial costs. But, most importantly, the Motorola > reseller is typically not making a new product. They are reselling the > Motorola product, perhaps as a private label, to an end user who will > receive Motorola's packaging and notifications (at first boot, perhaps - I > do not actually know how). > > As far as I can see (well, guess), network switch purchasers are almost > always end users (corporate or personal). And, it is my guess - after > spending the past week and a half trying to understand GPL's implications - > that there are many, many small resellers of network switches in complete > systems that are out of compliance with GPL because they do not even think > about the issue. As a side note, our customers are a bit like this kind of > reseller of a complete system that happens to contain a network switch, > though the analogy is not great because the network switch is in some sense > a complete system, while what we make is not. Still, if I sell a network > installation to a small shop, and I fail to give the recipient of my system > that includes that switch the GPL license and a place to get the source > code, I am in violation of GPL. I do not want this to happen to my > customers. > > iRobot is making an end use product, not a product that someone else is > going to take and build into something very different from the iRobot > product. Again, a lot like Motorola and their phone. If NewEgg sells an > iRobot product, they just pass through the iRobot package - with everything > in it - so (I think, though I am not quite sure) they are in compliance as > long as iRobot was. I suspect that NewEgg just assumes that iRobot got > their licensing right. My reading of GPL is that NewEgg actually has their > own obligation under GPL separate from iRobot's, but I would guess they do > not worry about it much. They are not making anything. They are just > reselling. > > ARM boards that run u-boot: The target customer base is aiming to take > advantage of the ARM board to make a product at a low cost (typically), and > most of them are well aware of GPL and its implications. This is somewhat > like us. Some of the uses have very small markets - as most of our > customers do. But, we do not have a customer base that is aware of GPL and > intend to use it from the beginning. > > A typical customer of ours might sell 50 systems in a year and consider > that a very good year. They sell each system for a lot of money (typically) > and they are not spending a lot of time thinking about licensing. Most (a > guess) probably do not even have an in-house counsel, let alone a license > management department. > > Asking them to take on new licensing obligations is an impediment to > adoption of our product. How many of our customers already easily deal with > GPL, I do not know, but I doubt it is a big fraction. You may not see that > as a big issue, and if you were our customer it would not be a big issue > for you. But, many of our customers hardly even formally license their own > products to their customers; they go install them. My point is that our > market is not an end use market where the licensing almost does not matter > once the end user has the product in hand. And, it is not a big OEM market > where the licensing is a triviality. And, our market is not Makers, say, > who know - and want to be - buying GPL licensed products so that they can > hack around in them. > > Our market is for small OEMs - or OEMs who work inside big companies, but > with small customer bases, which is even worse because here there is a > legal department, but our customer has next to no chance of getting their > attention - who make low volume specialized products - an industrial > turbine monitoring system, say - that typically sell infrequently for > relatively high prices and they want our part of the system to just work > with as little thought as possible. Their focus is on their application > area. If we can help them without getting in their way, they may use us. If > we look like a nuisance, they will go elsewhere (maybe to an ARM board and > building their own hardware for measurement - but then it is not my job to > see that they properly handle GPL). > > Unlike someone selling an ARM board, that part of our code happens to be > GPL is of no interest to these customers at all (that is, it is not a > reason to adopt us, as it might be if we made ARM boards). And, licensing > is not something a typical customer of ours wants to think about (not that > the ARM board customer wants to either). The ARM board manufacturer, based > on a lot of experience on my part, only worries about their own compliance. > They do not worry about their customer's compliance as we do. > > If we can make it so that our customers do not have to think about it, > then there is likely not much of a problem. But, so far, it is not at all > clear to me that we can reach that level of transparency. > > To try to clarify: I do not want to just comply with GPL. I easily see how > to do that by now. I want to make it so that my customer does not have to > think about it when they sell their system. If I try to make them think > about it, I am about certain that will be a reason to not use our product. > You might not believe that, but I do. The issue is one of marketing and > selling, not of engineering or even law. > > > Also, why do you mention GPL V3? Coreboot is 2 or later. > > What about the many systems that run all kinds of GPL V2 embedded > software? What's different between you and them? > The module we are using uses both Coreboot (GPLv2) and SeaBIOS (GPLv3). > > > What I'm trying to say is that problem seems to have been solved. I get > the feeling you are new to dealing with this question, and are trying to > solve it yourself, without talking to people who have already solved it? > I am not trying to solve the problem by myself. I did not just read the > GPL license and try to determine its implications. > > I have been, for the past week and a half, reading materials produced by > people who do understand GPL and have successfully used it. I have looked > for products like ours where such licensing has been employed where the > customer base was developers who are not open source developers. I have yet > to find a good match, by which I do not mean to imply there is not one > around. > > I am on this group exactly to learn what our obligations are and what we > need to do to make a product that would work for our customer base using > GPL licensing. > > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] G505s with Coreboot unable to run any version of Qubes
by Emil Novik 30 Dec '17

30 Dec '17

Thanks ! With the help of Awokd I managed to boot each version by using "xen-pciback.hide=(PCI address of the discrete GPU)" and the small grub fix for 3.2. I was planning on using 4rc3 but the VM setup on first boot always fails to create sys-net because of a libxenlight error. I can still start my session but no internet access, same error each time I try to start sys-net and no VM manager to be found. So I decided to use 3.2 and it works like a charm, just needs some more ram and all will be perfect :) --- Emil Novik -------- Original Message -------- On Dec 30, 2017, 21:44, Ivan Ivanov wrote: > Hi Emil, thank you very much for your report. > Regarding Qubes 3.2 : at the Qubes HCL list I wrote: > > "after Qubes R3.2 installation it cant boot - cant reach GRUB Boot Menu > because MBR (or GRUB) is corrupted. Use grub2-install to fix it (read more) > Everything else is OK " > > https://groups.google.com/forum/#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ > > If you fix your GRUB as described ^^^ you may be able to finally boot Qubes 3.2 > Please test it and let me know the results > > Live 3.1 was buggy, full 3.1 would have worked. Haven't tested 4.0 - > can't speak about it > > Best regards, > Ivan > > 2017-12-28 1:19 GMT+03:00 Emil Novik via coreboot : >> Hey, I'm having some heavy trouble getting my laptop to run Qubes and I >> first thought I was having issues with the OS. But after digging into the >> logs I managed to get(crashes too early during boot to get any persistent >> logs, had to write most by hand) it feels more like an issue with my >> Coreboot built. >> >> So there are the details : >> - G505s with integrated HD 8650G + discrete R5 M230 graphics. >> - Coreboot 4.6-2477-g6ab3edac3c-dirty with processor microcode patch >> (change-ID: Ibbfee47ce1d5081640d6924e2b12f5213a7fcadb). >> - Runs Debian Stretch fine. >> - Fails to start Qubes 3.2 / 4.0 rc3 / Live 3.1. >> - I added the vgabios.rom for the integrated card with menuconfig and the >> one for the discrete card with cbfstool. >> - Coreboot.rom, .config and full make output as attachment. >> >> >> Some more error data I gathered from coreinfo's Bootlog : >> >> Failed to enable LTR for dev = PCI: 01:00.0 >> Failed to enable LTR for dev = PCI: 02:00.0 >> ... >> I2C: 01:50 missing read_resources >> I2C: 01:51 missing read_resources >> PNP: 00ff.1 missing read_resources >> ... >> Warning: Can't write PCI_INTR 0xC00/0xC01 registers because >> 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL >> Warning: Can't write PCI IRQ assignments because 'mainboard_pirq_data' >> structure does not exist >> ... >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187 >> ASSERTION ERROR: file >> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776 >> ... >> Manufacturer: ef >> SF: Detected W25Q32 with sector size 0x1000, total 0x400000 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> Manufacturer: ef >> SF: Detected W25Q32 with sector size 0x1000, total 0x400000 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425 >> ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 309 >> ... >> EEPROM not found >> EEPROM not found >> EEPROM not found >> EEPROM not found >> EEPROM not found >> EEPROM not found >> EEPROM not found >> ... >> I2C: 01:50 (unknown) >> I2C: 01:51 (unknown) >> ... >> APIC: 11 (unknown) >> APIC: 12 (unknown) >> APIC: 13 (unknown) >> PCI: 01:00.0 (unknown) >> PCI: 02:00.0 (unknown) >> PNP: 00ff.0 (unknown) >> >> >> "..." are parts I didn't write down as they didn't show any obvious >> errors(but I'm bad at seeing them) and it would take me a loooong time to >> write down the full log as I can't export it as far as I know, if you need >> any more information from it, I can write down any part missing. >> >> Output of "cbfstool coreboot.rom print" after I added the optionrom for the >> R5 M230 discrete graphic card : >> Name Offset Type Size Comp >> cbfs master header 0x0 cbfs header 32 none >> fallback/ramstage 0x80 stage 129247 none >> config 0x1f9c0 raw 263 none >> revision 0x1fb00 raw 582 none >> payload_revision 0x1fd80 raw 239 none >> apu/amdfw 0x1fec0 raw 131072 none >> fallback/romstage 0x3ff00 stage 320556 none >> cmos_layout.bin 0x8e3c0 cmos_layout 1164 none >> pci1002,990b.rom 0x8e8c0 optionrom 61952 none >> fallback/postcar 0x9db40 stage 13268 none >> fallback/dsdt.aml 0xa0f80 raw 9435 none >> img/coreinfo 0xa34c0 payload 102712 none >> img/nvramcui 0xbc640 payload 141628 none >> fallback/payload 0xdefc0 payload 67370 none >> payload_config 0xef740 raw 1611 none >> pci1002,6665.rom 0xefe00 optionrom 32768 none >> (empty) 0xf7e80 null 3112984 none >> s3nv 0x3efec0 raw 32768 none >> (empty) 0x3f7f00 null 31192 none >> bootblock 0x3ff900 bootblock 1424 none >> >> What happened when I tried to boot each version of Qubes : >> >> Live 3.1 : >> mce: Unable to init device /dev/mcelog (rc: -16) >> radeon 000:04:00:0: Invalid ROM contents >> radeon 000:04:00:0: Invalid ROM contents >> [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM >> radeon 000:04:00:0: Fatal error during GPU init >> [TTM] Memory type 3 has not been initialized >> SQUASHFS error: squashfs_read_data failed to read block 0x5cb75d68 >> SQUASHFS error: Unable to read data cache entry [0x5cb75d68] >> SQUASHFS error: Unable to read page, block 0x5cb75d68, size af0 >> SQUASHFS error: Unable to read data cache entry [0x5cb75d68] >> SQUASHFS error: Unable to read page, block 0x5cb75d68, size af0 >> EXT4-fs error (device dm-0): ext4_find_entry:1289: inode #41642: comm >> plymouthd: reading directory lblock 0 >> (Hangs at the Qubes graphical loading screen, with loading bar full.) >> >> 3.2 (Install looked fine) : >> Hangs at "Booting from Hard Disk..." in SeaBIOS on every try >> >> 4.0 rc3 : >> [ FAILED ] Failed to start Load Kernel Modules. >> ... >> [ OK ] Reached target Basic System. >> (Hangs for about 10secs, followed by 5s of black screen) >> BUG: Unable to handle NULL pointer dereference at (null) >> (followed by a lot of output likely concerning the error and quickly back to >> boot) >> Sadly too much output and disappearing too fast for me to get anything out >> of it if all I can do is read and type to export it. Tried Ctrl+S/Ctrl+Q to >> "pause" it but nope, also checked that the laptop should not reboot in case >> of kernel panic but it still does... >> >> Thanks to anyone that could help me find what's wrong and how to fix it :) >> >> --- >> Emil Novik >> >> >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot @coreboot.org>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2017