7

After installing the Ubuntu 19.10.1 64-bit server image for Raspberry Pi 4, installing kubuntu-desktop, and rebooting, the system hangs during boot up. There appears to be no way to get to the desktop GUI. (Note: I've tried every available desktop, although Kubuntu is my preferred one. The results are the same for all of them.) The steps to reproduce the problem follow.

Materials

  • Raspberry Pi 4B 4GB Model B with 1.5GHz 64-bit quad-core ARMv8 CPU (4GB RAM)
  • 32GB SD card
  • 500 GB external SSD
  • ubuntu-19.10.1-preinstalled-server-arm64-raspi3.img image file downloaded from https://ubuntu.com/download/raspberry-pi.

Steps to reproduce

  1. Download image file and burn to SD card using Balena etcher (format FAT32).
  2. Also burn image file to external SSD using Balena etcher (format EXT4).
  3. Attach/insert both storage devices to Raspberry Pi 4.
  4. Boot Raspberry Pi 4. After changing ubuntu user password, boot up succeeds with no issues. In fact, at this point, I can SSH into the RPi and do pretty much anything I want to do from the PuTTY terminal. It's only when I try to add a GUI that the whole thing starts to crash.
  5. Install Kubuntu desktop with sudo apt install kubuntu-desktop. No errors reported during installation. (Note: Performed these same steps for ubuntu-desktop, xubuntu-desktop, and a number of other desktops. All had the same results.)

  6. Rebooted Raspberry Pi with sudo reboot. Reboot occurred until it hung at [ 28.5791341] cloud-init[1547]: cloud-init v. 19.2-36. … At this point the system froze (Sorry for not having the full line at the point it froze. It's obviously on a different machine with a lot of strings letters and numbers, so copying and pasting is out of the question. It does report that cloud-init finished and the correct time for it finishing.

    The cloud-init process begins immediately following the snap application lxd.activate service starts successfully.

At this point the system hangs with the cursor on the line described in Item 6 above. I've tried pressing [Enter], entering Ctrl+C, and everything else I could think of; nothing will move the cursor or restart the process.

Of interesting note, at this point I can SSH (with PuTTY) into the Raspberry PI, successfully and can enter and execute all kinds of terminal commands with no problems. Thus, it's pretty clear that some process (cloud-init?) is hung, not the system.

Also, from the machine with SSH entry, I can do a sudo reboot, several times, and it will successfully go through the reboot process until it hits the same point where it hung before, at which point, it will hang again, just like before.

Note that I am using an external SSD for the operating system. Using this methodology, the system uses the 32-Gb SD card for the bootloader, then switches automatically to the 500-Gb SSD on sdb for operations. Ubuntu has done a great job of making this happen automatically. It used to be a horrible ordeal to get it configured and working. Anyone who would attempt to run a system off an SD card has got to be a foolhardy soul who takes delight in being beaten up by attempting to do so, especially since SSDs have gotten to be dirt cheap. (Even with that, the Raspberry Pi folks have made it difficult by being picky about which external drive controllers the RPi will recognize and accept. Fortunately, folks like James Chambers have given us lists of those that do work. In decades of working with external drives, I never, ever had any problems with any external drive until the RPi 4B. And we still must have the SD card for the bootloader instead of booting directly to the SSD — something which the RPi 3 did quite nicely. Talk about one small step for RPi, one enormous, gigantic leap backwards! But I digress.) I've used this functionality before. Just wanted to let you know that it does work.

Also, sorry about the ineffective use of tags. StackOverflow's rules regarding tags prevent me from using something like 19.10.1 instead of 19.10, a difference which is critically import in this issue. Ditto for a multitude of other tags.

Improve this question
2
  • FYI: The tags (esp. 19.10) are not an issue, but thanks for clarification & specifically mentioning 19.10.1. I am aware this was tested by a number of flavors (some time ago close to release time), but we're limited to hardware we have access to. Sean of Xubuntu was one of the first (bluesabre.org/2019/10/20/…); it likely won't have new information but it was tested & used for other flavors too (for testing and/or their own documentation).
    – guiverc
    Commented Feb 9, 2020 at 0:35
  • Hi @LarryTX check out nycdanielp answer and accept it, if it works for you too.
    – Benjamin Buch
    Commented Jul 3, 2020 at 19:15

4 Answers 4

Reset to default
4

I'm glad to see that someone else has experienced EXACTLY the same problem that I have! And here's the work-around I found--not a solution, but it gets Kubuntu working. When you get to the point where the system hangs, you can switch to another TTY. I believe the system starts in TTY1, which is supposed to be the one used for the graphical interface. You can switch to TTY2 by pressing CTL+ALT+F2, and you should get a login prompt. Login as Ubuntu, and when you get a prompt, execute "startx". This will bring up the Kubuntu desktop, and you are already logged into it. And I have to do this each time I boot up the system. I think this must be a bug in the Kubuntu installation routine, but I have yet to find a way around it. Sure would be nice if someone fixed it. There ought to be a file somewhere that you could insert the "startx" command and have it run at bootup, but I don't know enough about Ubuntu to do it.

Improve this answer
1
  • Hallelujah, @actor39! You (and your response) are truly marvelous! Admittedly, we need to have a better answer, but yours has turned an absolute disaster into something at least workable and somewhat usable.Just as important, when you've identified a workaround, it should make it easier to find a cause and fix the whole thing. It is very discouraging to hear that others have identified the issue, and Canonical hasn't fixed it yet. What's all this about *support* for this release. I'm reluctant to lay blame on Kubuntu because I found much the same issue with at least five other GUIs.
    – LarryTX
    Commented Feb 9, 2020 at 3:23
3

I just installed the latest 20.04 version and this exact same issue happened with Kubuntu and Lubuntu. Removing cloud-init does not solve the issue. Switching to TTY2 by pressing CTL+ALT+F2 does work and allows running startx.

However, the solution you probably are looking for is adding the following to /boot/firmware/syscfg.txt (or usercfg.txt):

dtoverlay=vc4-fkms-v3d

This loads the "fake" KMS framebuffer which improves desktop usage and fixes the boot sequence so it goes directly to desktop. Incidentally, this worked but it caused my 1080p display to underscan, which I fixed by adding an entry in syscfg.txt as follows:

disable_overscan=1

Improve this answer
3
  • Works for me (after I noticed that I had typed "cv" instead of "vc").
    – Benjamin Buch
    Commented Jul 3, 2020 at 19:13
  • Same here, Ubuntu 20.04 (64 bit) with kubuntu-desktop. With the dtoverlay in the answer it boots successfully into KDE. Thank you.
    – bob
    Commented Jul 4, 2020 at 18:03
  • Works perfectly!
    – DeooK
    Commented Aug 12, 2020 at 9:53
0

Thanks for this info. I thought maybe I need to set it to start in graphical mode, so from TTY2 mentioned above I issued:

$sudo systemctl set-default graphical

Then I rebooted and got stuck same place again. So I went the manual way :

$sudo systemctl set-default multi-user

Then I login and issue the startx command.

Improve this answer
0

I had the same issue. I just uninstalled cloud-init and kubuntu loaded up fine.

sudo apt remove cloud-init
Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .