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