Random crng init done raspberry

Random crng init done raspberry

I have been using a PI3B + with a Kingston USB disk for several months to run Jeedom without any problem.

I decide today to update the Pi in update and upgrade. Everything goes perfectly during the installation. Except that restarting is the blocking!

I then connect a screen to see what happens: the log remains stuck on «random: crng init done». No key on the keyboard moves the process forward (only CTRL + ALT + DEL causes the Pi to reboot).

Some useful details:

— I disconnected everything (except the SSD obviously) to avoid a «conflict» with connected elements;
— I waited a long time (> 1h) just in case;
— Everything is well powered on mains, no overheating, etc.

I hope now that you can have an idea to get me out of there because I do not want to reinstall everything when everything worked quite well!

Thank you in advance, I’m counting on you!

Re: random: crng init done

In my experience this is one of the last messages to print out before the login prompt appears (normally.)

In other words this message has nothing to do with your issue.

Attach a screen, boot and see what messages the system prints. It might be busy trying to mount a network resource, checking a filesystem.

Re: random: crng init done

Here is a screenshot of the log.

Re: random: crng init done

from the last thread about this, seems to be a corrupt card thing, possibly a specific download version. Maybe try re-downloading with current Buster (or checking your download against the checksums) and re-flashing?

Источник

Random crng init done raspberry

Re: Boot hang after «random: crng init done»

I was getting this when experimenting with NFS boot — and it usually meant that the system couldn’t find rootfs.

Re: Boot hang after «random: crng init done»

Re: Boot hang after «random: crng init done»

Re: Boot hang after «random: crng init done»

The fact that the message says «crng init done» suggests the fault is with something else it is trying to start afterwards. Try with «initcall_debug=1» on in cmdline.txt, and then see what the last few messages say.

Re: Boot hang after «random: crng init done»

(what u changed was that last 06 digit at the end of the root part, that was previously 02)

Thanks in advance

Re: Boot hang after «random: crng init done»

Re: Boot hang after «random: crng init done»

At boot, the kernel waits for mouse movements to initialize the random number generator.
/quote]

Ugh! that seem a valid explanation: I am running headless and HAVE NO MOUSE NOR KEYBOARD.

Pluging a mouse releases the boot process. But that is’nt the purpose of a headless machine!

Installing haveged works!

Re: Boot hang after «random: crng init done»

Re: Boot hang after «random: crng init done»

Languages using left-hand whitespace for syntax are ridiculous

DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors — are all on my foes list.

The use of crystal balls and mind reading is prohibited.

Re: Boot hang after «random: crng init done»

i have the same trouble trying installing Kally on my PI 3 B+.

I change my cmdline.txt like this :

i use this img «kali-linux-2019.1-rpi3-nexmon-64» flashing buy «balenaEtcher» after being format by SD Card formatter.
My Sd card is : scanDisk Ultra 16GB micro SD HC1

I tryed to press enter / move my moose / nothing happened. I don’t find anything working on internet.

Re: Boot hang after «random: crng init done»

Re: Boot hang after «random: crng init done»

The kernel output «random: crng init done» isn’t an issue. It’s only the information that the random number generator is initialized, which happend usually happend very late at boot process.

In the most described cases the rootfs won’t get mounted, but this is hard to say because of the lack of real helpful information like dmesg.

Источник

Random crng init done raspberry

I’m having the same issue with latest Raspbian O/S Lite on SSD and a Waveshare 3.5inch RPi LCD (A).

RPi 3B+ boots fine off the SSD. When I load the drivers for the 3.5″ LCD, boot fails and I see the «random: crng init done» error.
I’ve edited cmdline.txt to read:

root was /dev/mmcblk0p2. Still no boot, however once I press Enter, I can run some commands, ie cd, ls, df etc.

At a loss where to go next.

Re: random: crng init done

No, you aren’t. The output on your screen is very different to the picture the OP posted.

As mentioned in the first reply above, the message «random: crg init done» is an informational message to say the boot has initialised the random number generator successfully.
Your problem seems to be that the kernel can’t run a valid init program for your system. The important lines (those shown, at least) are

You are now in a recovery shell and should be able to type some basic commands to find out what is wrong with your system.

I’d start with the mount command, df and ls.

Re: random: crng init done

No, you aren’t. The output on your screen is very different to the picture the OP posted.

As mentioned in the first reply above, the message «random: crg init done» is an informational message to say the boot has initialised the random number generator successfully.
Your problem seems to be that the kernel can’t run a valid init program for your system. The important lines (those shown, at least) are
.
You are now in a recovery shell and should be able to type some basic commands to find out what is wrong with your system.

I’d start with the mount command, df and ls.

Thanks for the info.
I did try df & ls but was stuck after that, hence the post. It was beyond my level where to go next.

Mount point was the issue. Even though I changed the initial root=/dev/mmcblk0p2 to sda2 in cmdline.txt, as per other posts, boot didn’t progress further. I was lost.

Looked at another RPi I have using SSD, I saw root=PARTUUID=d0aa9494-02. Hmm, different. I reimaged the current SSD and took note of root=PARTUUID which was 043b6de5-02

Next, seeing as though I know it boots fine before installing the Waveshare 3.5″ LCD, I took a look at it’s install script. Lo and behold, just before it issues a reboot, it copies over a generic cmdline.txt written for SDcards. It happens to contain root=/dev/mmcblk0p2. So I commented that line out in the script. Prior to reboot, I edited cmdline.txt to include the LCD parameters but retain root=PARTUUID=043b6de5-02.
Fingers crossed, issued the reboot. RPi booted all the way and the LCD works. Much happiness

Источник

V 9.2.x hangs with «random: crng init done»

I have tried several versions of 9.2.x (.6 / .5. / .4). All hang with the message random: crng init done» . Before that the message «random: fast init done» lasts about 2 minutes.

I have tried different SD cards (all 32GB), and a 2GB USB stick. I have also tried different power supplies.

The V9.95.1 (Matrix) boots and works fine. However, I want to use Kodi V18.

Hardware: Raspberry4 with 2GB

Who can help me?

Edited 3 times, last by DoXer ( Apr 14th 2021 ).

The log line is just a red herring, there is likely something else wrong.

Are you doing a clean install of 9.2.x for RPi4 onto an sdcard? Or was this a «downgrade»?

Yeah, could be driver confusion due to downgrade. Do a fresh install.

DNB music-addicted finger drummer.

It`s a fresh install. All tries, SD-card and USB-Stick.

I used LibreElec-USB-Creator, but also RaspberryPi-Imager.

I haven’t seen that crng error before. Perhaps a hardware failure?

Try Rufus for Windows to image the SDcard/USB stick.

Also try Raspberry Pi OS or Ubuntu 20.10, just to see if the thing works okay.

Sorry, didn’t mentioned it. I also tried newest Raspbian. Keep in mind, LibreElec MATRIX boots succesfully.

Same issue with Rufus to write the SD-Card.

Do you overclock?

DNB music-addicted finger drummer.

No modifications or tweaks, I only removed «quiet» from config.txt.

Which bootloader version do you have installed? Check / upgrade it to latest from working OS as described here.

We need more info. Activate debugging at GUI, reboot, login by SSH and post the resulting link of the pastekodi command.

DNB music-addicted finger drummer.

Login with ssh is not possible, because the system hangs . I have no login, no ssh.

Which bootloader version do you have installed? Check / upgrade it to latest from working OS as described here.

I have the latest bootloader installed. This was done with an Image based on Kernel 5. All the hangs on booting are with images based on Kernel V4.

Don’t you have any bootable device connected to USB port?

I would try to disconnect anything from your RPi except display and try to boot.

Check / share the bootloader config — maybe there’s a boot preference incompatible with older firmware (which is in older LE image). If this is the case, perhaps it could be possible to replace the RPi firmware in your older LE with the working firmware from the working LE image.

Источник

Linux kernel hang at crng init done #306

Comments

Rusack commented Sep 13, 2018

I’m trying to install OP-TEE and TF-A on the Raspberry Pi 3 (model B), therefore I used the manifest file for the rpi3 and the repo command (Didn’t specify the release or anything, just took the last one). The build went fine, I then installed the result on the micro SD following instructions of the make img-help output. My problem is appearing at the linux kernel boot, it hangs forever after random : `crng init done , I’m connected by UART.
I’m joining the build log as well as the boot log.
build.log
boot.log

The text was updated successfully, but these errors were encountered:

gkarop commented Sep 13, 2018

I have a similar issue. I’m using a Raspberry Pi 3 (model B, V 1.2, 2015) and release branch 3.2 ( -b 3.2.0 ). I also had no problems with build, installed OP-TEE following the instructions on make img-help and I get the output to the screen through HDMI. The first time I boot Pi it is stuck in crng init done as @Rusack mentioned previously; see the screenshot below:

If I power off and then power on again the Pi it is stuck in the following screen (every time apart from the first boot it is stuck in the following screen):

I also tried rootfs.cpio.gz that @jbech-linaro provided here:
#276 (comment)
but the result was exactly the same as above.

jbech-linaro commented Sep 13, 2018

And from the comments in #276 we haven’t done anything with the RPi3 B+ model (I still only have the old RPi3). So, I wouldn’t be surprised if it’s (still) an RPi3 B+ issue.

igoropaniuk commented Sep 13, 2018

@gkarop Seems the dhcp-client is the reason of this hang. Try to connect RPi3 to ethernet and see what happens next (I did have a similar issue)

Rusack commented Sep 13, 2018 •

I’m using a Rpi 3 model B v1.2 2015, that’s what is written on it.

Edit : It’s v1.2 actually

gkarop commented Sep 14, 2018

And from the comments in #276 we haven’t done anything with the RPi3 B+ model (I still only have the old RPi3). So, I wouldn’t be surprised if it’s (still) an RPi3 B+ issue.

@jbech-linaro In the past I tried in a RPi3 B+ where indeed it does not boot. Currently I’m using an RPi3 B model (the screenshots above are from the B one). Could it be something with the different versions? Mine is model B v1.2.

@gkarop Seems the dhcp-client is the reason of this hang. Try to connect RPi3 to ethernet and see what happens next (I did have a similar issue)

@igoropaniuk I tried with ethernet with no success; compared to the screenshots above I only get one more message saying «Link up» and then it is stuck there.

Is there a way to disable dhcp?

jforissier commented Sep 14, 2018 •

Is there a way to disable dhcp?

Quick and dirty way: delete this line in common.mk :

Edit: For a better fix, perhaps we should make this line conditional, default enabled for QEMU at least. But first try to understand why this udhcp thing is a problem for RPi3: shouldn’t the script just fail quickly if there is no network device or no DHCP server on the network?

gkarop commented Sep 14, 2018

Nothing changed. In my common.mk file it is already conditional so probably it was never called anyway:

jforissier commented Sep 14, 2018

@gkarop sorry I failed to notice you’re on 3.2.0. Current master does not have QEMU_USERNET_ENABLE anymore.

gkarop commented Sep 17, 2018

I have tried many different things in order to disable udhcpc but it always starts during boot. Any ideas? In which configuration files I should search in particular?

dmeignan commented Oct 30, 2018

Any news with this issue, I have the same problem with a Rpi 3 model B v1.2 2015.

jforissier commented Oct 30, 2018

@dmeignan should be fixed by #316

jedichen121 commented Oct 31, 2018

I just tried the build yesterday and I’m still hanging at the crng init done . I checked my local code and found that the changes in the newest commit were there. I’m also using Rpi3 and I’m not using UART but connected directly with HDMI. The following code in the #316 is not in my version of common.mk. Should I add it and try make again?

jbech-linaro commented Nov 1, 2018 •

So to summarize things that needs to be addressed and looked at into in the future.

  1. The core team doesn’t have any RPi3 model B+, we only have the first RPi3 revision (B).
    1.1 People are seeing various errors using RPi3 model B+. Most of them seems to be that it hangs during boot and crng init done is the final message seen.
  2. Using the first RPi3 revision, the core team have no issues building, booting nor running test.

To address «1», we (core team) need to buy a RPi3 model B and start debugging. We can do that, but we have the roadmap planned for several months a head of us with other things and features, which means that it could take a while until we have time to do proper debugging and testing with the newer RPi3 revision. So a faster way forward would be to help users having the issue to narrow down the problem (basically what we’ve tried in this thread).

Related, if and when I find time, I’ve planned to add the RPi3 to the automatic build, boot, test cycle initiated by GitHub commits (basically add a config for IBART). But with recent changes to the RPi3 boot (doing a more proper boot), it has become harder to deploy the files automatically. I think it still id doable, but just a bit more tricky. If I ever get to work on this, we should hopefully be able to rule out problems like this.

Regarding «2», we can re-test again to ensure that the first RPi3 revision still works. As mentioned yesterday in #296 (comment) 3.2.0 was tested OK by two independent developers and 3.3.0 released

2 weeks ago was also tested OK also, see OP-TEE/optee_os#2552 (comment)).

Источник

Adblock
detector