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: [email protected]
To contact the owner, e-mail: [email protected]
