[opensuse-arm] openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2017.01.13-Build4.1.raw booting from usb-hdd/thumb drive without SD-Card
Hello All, let me first thank all those of you who made the above mentioned image possible. To me, it is the first image since at least October 2016 that ist booting on my rpi3 without any problems. The only thing not working is wifi. But that was to be expected (as it sports kernel 4.9), as Andreas Färber already said on this list. So, Thank you and keep up the good work. As most of you may already know it is possible to boot an rpi3 without SD-Card from usb (hdd or thumb drive) directly since August 2016, following the instructions given in the link below: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd... I tried that and it works without problems using Raspbian on both, an hdd and a thumb drive. Since my rpi3 is now unlocked and able to boot from usb I tried to make it boot with openSUSE using the image in the subject and copying bootcode.bin und start.elf from here https://github.com/raspberrypi/firmware/tree/next/boot to /dev/sda1/efi on my usb-hdd and - alternatively - to my usb thumb drive, replacing the original files on it. To make a long story short: It works! ...sort of (more about that later). It is possible to boot openSUSE-aarch64 on an rpi3 without SD-card directly from usb. And now we come to the "sort of" part of the boot process. - Grub2 appears and loads the kernel and initrd - all kinds of boot messages appear about services that were started and targets that were reached. But then the system hangs indefinitely with the following line: "A start job is running for dev-sda2.device (xys/no limit)" I spent the last two weeks trying to figure out what the problem is and how to solve it but did not find a solution. Here is what I found out and tried so far: 1. The message originates from systemd-fstab-generator a) To me it is not clear, though, why the system boots to this point and stops here. Since /boot on /dev/sda2 is found, services are started and targets reached, why is it a problem to find /dev/sda2.device? b) It does not matter how partition names are given to sda2. No matter if the name is derived from uuid, id, block device, anything else, the boot process stops here. 2. I tried to circumvent systemd-fstab-generator by a) adding fstab=0 or "no" to the kernel command line to prevent it from generating this line from my /dev/sda2 fstab entry. This is ignored by systemd-fstab-generator, the problem persists. b) adding "x-systemd.device-timeout=10" to the /dev/sda2 line of fstab. This is ignored by systemd-fstab-generator, the problem persists. c) renaming the file to systemd-fstab-generator.nil in /usr/lib/systemd/generators and creating an new initrd without it. The system still hangs at the same point but without the start job message. My questions are - Why does the system hang with the above message and won't boot on? - How can this problem be resolved? Any kind of help is appreciated. Best regards, Freigeist -- On a long enough timeline the survival rate for everyone drops to zero... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25/01/2017 19:20, Freigeist wrote:
Hello All,
let me first thank all those of you who made the above mentioned image possible. To me, it is the first image since at least October 2016 that ist booting on my rpi3 without any problems. The only thing not working is wifi. But that was to be expected (as it sports kernel 4.9), as Andreas Färber already said on this list.
So, Thank you and keep up the good work.
As most of you may already know it is possible to boot an rpi3 without SD-Card from usb (hdd or thumb drive) directly since August 2016, following the instructions given in the link below:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd...
I tried that and it works without problems using Raspbian on both, an hdd and a thumb drive.
Since my rpi3 is now unlocked and able to boot from usb I tried to make it boot with openSUSE using the image in the subject and copying bootcode.bin und start.elf from here
https://github.com/raspberrypi/firmware/tree/next/boot
to /dev/sda1/efi on my usb-hdd and - alternatively - to my usb thumb drive, replacing the original files on it.
To make a long story short: It works! ...sort of (more about that later). It is possible to boot openSUSE-aarch64 on an rpi3 without SD-card directly from usb.
And now we come to the "sort of" part of the boot process.
- Grub2 appears and loads the kernel and initrd - all kinds of boot messages appear about services that were started and targets that were reached.
But then the system hangs indefinitely with the following line:
"A start job is running for dev-sda2.device (xys/no limit)"
I fixed that one last weekend :). The usb driver wasn't included in the initrd: https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base&rev=517 Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25/01/17 19:29, Alexander Graf wrote:
On 25/01/2017 19:20, Freigeist wrote:
"A start job is running for dev-sda2.device (xys/no limit)"
I fixed that one last weekend :). The usb driver wasn't included in the initrd:
https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base&rev=517
Alex, thanks for your reply. I forgot to mention that I already rebuilt the initrd with all usb modules listed by lsmod by placing them in /etc/dracut.conf.d/raspberrypi_modules.conf and it doesn't work. Even building a monster initrd with mkinitrd -A didn#t work. Or are you talking about something else here? If so, where - in which image-repo or aarch64/oss-repo - can I find an image with your fix or a fixed package and how is it called? Concerning the latter I am pretty much clueless right now. -- On a long enough timeline the survival rate for everyone drops to zero... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25/01/2017 21:16, Freigeist wrote:
On 25/01/17 19:29, Alexander Graf wrote:
On 25/01/2017 19:20, Freigeist wrote:
"A start job is running for dev-sda2.device (xys/no limit)"
I fixed that one last weekend :). The usb driver wasn't included in the initrd:
https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base&rev=517
Alex, thanks for your reply. I forgot to mention that I already rebuilt the initrd with all usb modules listed by lsmod by placing them in /etc/dracut.conf.d/raspberrypi_modules.conf and it doesn't work. Even building a monster initrd with mkinitrd -A didn#t work.
Or are you talking about something else here?
No, that's basically what I'm talking about. I'm surprised, as it did work for me :).
If so, where - in which image-repo or aarch64/oss-repo - can I find an image with your fix or a fixed package and how is it called?
It's built inside OBS, but not published because we have failing OpenQA tests right now. The easiest way to fetch the current image is to run the following command: $ osc getbinaries openSUSE:Factory:ARM JeOS:JeOS-raspberrypi3.aarch64 images aarch64 I do have to admit that I didn't verify the end resulting image. I changed it locally on a Leap based image and then transferred the change into the Tumbleweed image description. I also booted straight from USB, so the first boot step was already running on USB. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25/01/2017 21:55, Alexander Graf wrote:
On 25/01/2017 21:16, Freigeist wrote:
On 25/01/17 19:29, Alexander Graf wrote:
On 25/01/2017 19:20, Freigeist wrote:
"A start job is running for dev-sda2.device (xys/no limit)"
I fixed that one last weekend :). The usb driver wasn't included in the initrd:
https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base&rev=517
Alex, thanks for your reply. I forgot to mention that I already rebuilt the initrd with all usb modules listed by lsmod by placing them in /etc/dracut.conf.d/raspberrypi_modules.conf and it doesn't work. Even building a monster initrd with mkinitrd -A didn#t work.
Or are you talking about something else here?
No, that's basically what I'm talking about. I'm surprised, as it did work for me :).
If so, where - in which image-repo or aarch64/oss-repo - can I find an image with your fix or a fixed package and how is it called?
It's built inside OBS, but not published because we have failing OpenQA tests right now.
The easiest way to fetch the current image is to run the following command:
$ osc getbinaries openSUSE:Factory:ARM JeOS:JeOS-raspberrypi3.aarch64 images aarch64
I do have to admit that I didn't verify the end resulting image. I changed it locally on a Leap based image and then transferred the change into the Tumbleweed image description. I also booted straight from USB, so the first boot step was already running on USB.
Actually now that you mention it, there were some hickups with missing persistent device names that I didn't look into further. As workaround, try to explicitly say root=/dev/sda2 (or whatever the partition is) on your kernel command line from grub and modify /etc/fstab to only reference /dev/sdX. names as well. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 25/01/17 21:59, Alexander Graf wrote:
On 25/01/2017 21:55, Alexander Graf wrote:
On 25/01/2017 21:16, Freigeist wrote:
On 25/01/17 19:29, Alexander Graf wrote:
On 25/01/2017 19:20, Freigeist wrote:
"A start job is running for dev-sda2.device (xys/no limit)"
I fixed that one last weekend :). The usb driver wasn't included in the initrd:
https://build.opensuse.org/package/rdiff/openSUSE:Factory:ARM/JeOS?linkrev=base&rev=517
Alex, thanks for your reply. I forgot to mention that I already rebuilt the initrd with all usb modules listed by lsmod by placing them in /etc/dracut.conf.d/raspberrypi_modules.conf and it doesn't work. Even building a monster initrd with mkinitrd -A didn#t work.
Or are you talking about something else here?
No, that's basically what I'm talking about. I'm surprised, as it did work for me :).
If so, where - in which image-repo or aarch64/oss-repo - can I find an image with your fix or a fixed package and how is it called?
It's built inside OBS, but not published because we have failing OpenQA tests right now.
The easiest way to fetch the current image is to run the following command:
$ osc getbinaries openSUSE:Factory:ARM JeOS:JeOS-raspberrypi3.aarch64 images aarch64
I do have to admit that I didn't verify the end resulting image. I changed it locally on a Leap based image and then transferred the change into the Tumbleweed image description. I also booted straight from USB, so the first boot step was already running on USB.
Actually now that you mention it, there were some hickups with missing persistent device names that I didn't look into further.
As workaround, try to explicitly say root=/dev/sda2 (or whatever the partition is) on your kernel command line from grub and modify /etc/fstab to only reference /dev/sdX. names as well.
Alex
Thanks alot Alex, it is working now after applying another workaround. To sum up what I tried: 1. Writing the tumbleweed image from above directly to a thumb drive and booting from that one did not work for me. The system hung in an endless loop: Grub2 menu -> kernel -> initrd -> EFI stub -> grub2 menu. 2. Installing the old fashioned way by copying the installed system to a usb hdd and only referencing standard device names did not work at first try. The result was a hang during boot with: "A start job is running for dev-sda2.device" like described above. 3. The workaround was to edit /usr/share/grub2/grub-mkconfig_lib comment out the following lines # if fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; then # hints="`"${grub_probe}" --device $@ --target=hints_string 2> /dev/null`" || hints= # echo "if [ x\$feature_platform_search_hint = xy ]; then" # echo " search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}" # echo "else" # echo " search --no-floppy --fs-uuid --set=root ${fs_uuid}" # echo "fi" # fi and recreate grub.cfg without *any* references to uuids. After that the pi3 booted from usb hdd and thumb drive. My conclusion is that some component (grub2?, systemd?, something else?) does not react favouably to uuids - or a mix thereof with device names - in grub.cfg or there is a problem with persistent device names as you already pointed out. -- On a long enough timeline the survival rate for everyone drops to zero... -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (2)
-
Alexander Graf -
Freigeist