[Ubuntu 18.04] Verse VMware install heeft timeout bij boot

[Mastakilla]

Ik heb een paar dagen geleden Ubuntu 18.04 gedownload van de Ubuntu website en probeer deze als client te installeren in VMware Workstation 12.5.7 op mijn Windows 10 host. Tijdens de installatie heb ik alles op default gelaten, behalve dat ik LVM heb aangezet.

Bij het booten blijft Ubuntu echter hangen (34 sec) tussen
[sda] Assuming drive cache: write through
en
Gave up waiting for syspend/resume device

Ik heb reeds geprobeerd:
1) UUIDs plaatsen in /etc/fstab

code:

root@UbuntuVM:~# blkid
/dev/sda1: UUID="o2JaE4-1g3P-irfJ-9wAK-2fgt-no8P-8OnuRZ" TYPE="LVM2_member" PARTUUID="3063a1a1-01"
/dev/mapper/ubuntu--vg-root: UUID="121d8985-139d-4027-9716-3434e3e592ba" TYPE="ext4"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/mapper/ubuntu--vg-swap_1: UUID="2c893b15-9a8a-491e-8493-4504aa63e602" TYPE="swap"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"

root@UbuntuVM:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
UUID="121d8985-139d-4027-9716-3434e3e592ba" /               ext4    errors=remount-ro 0       1
UUID="2c893b15-9a8a-491e-8493-4504aa63e602" none            swap    sw              0       0

root@UbuntuVM:~# lsblk
NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0                   7:0    0 86,6M  1 loop /snap/core/4486
loop1                   7:1    0 12,2M  1 loop /snap/gnome-characters/69
loop2                   7:2    0  4,9M  1 loop /snap/canonical-livepatch/39
loop3                   7:3    0 45,6M  1 loop /snap/notepad-plus-plus/34
loop4                   7:4    0  1,6M  1 loop /snap/gnome-calculator/154
loop5                   7:5    0   21M  1 loop /snap/gnome-logs/25
loop6                   7:6    0  3,3M  1 loop /snap/gnome-system-monitor/36
loop7                   7:7    0  140M  1 loop /snap/gnome-3-26-1604/59
loop8                   7:8    0  3,7M  1 loop /snap/gnome-system-monitor/39
loop9                   7:9    0  2,3M  1 loop /snap/gnome-calculator/167
loop10                  7:10   0 21,6M  1 loop /snap/gnome-logs/31
loop11                  7:11   0 46,6M  1 loop /snap/notepad-plus-plus/37
loop12                  7:12   0   13M  1 loop /snap/gnome-characters/86
loop13                  7:13   0  140M  1 loop /snap/gnome-3-26-1604/62
sda                     8:0    0   30G  0 disk 
&#9492;&#9472;sda1                  8:1    0   30G  0 part 
  &#9500;&#9472;ubuntu--vg-root   253:0    0   29G  0 lvm  /
  &#9492;&#9472;ubuntu--vg-swap_1 253:1    0  976M  0 lvm  [SWAP]
sr0                    11:0    1 1024M  0 rom

2) Swap checken

code:

root@UbuntuVM:~# cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/dm-1                               partition   999420  1036    -2
root@UbuntuVM:~# swapon
NAME      TYPE      SIZE USED PRIO
/dev/dm-1 partition 976M   1M   -2

3) update-initramfs + reboot

code:

root@UbuntuVM:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
root@UbuntuVM:~#

Dit commando zorgde er wel voor "Failed to connect to lvmetad" verdween, maar de timeout is er nog steeds



Wat ik ook vreemd vind, is dat ik deze boot messages nergens kan terug vinden met volgende commandos:

code:

mastakilla@UbuntuVM:~$ journalctl -b0 --system _COMM=systemd | grep resume
mastakilla@UbuntuVM:~$ journalctl -b-1 | grep resume
mastakilla@UbuntuVM:~$ journalctl -b1 | grep resume
mastakilla@UbuntuVM:~$ journalctl -b0 | grep resume
mastakilla@UbuntuVM:~$ journalctl -b0 SYSLOG_PID=1 | grep resume
mastakilla@UbuntuVM:~$

Ook lijkt de timeout niet gedetecteerd te worden met volgende commandos

code:

mastakilla@UbuntuVM:~$ systemd-analyze blame | head
          5.502s plymouth-quit-wait.service
          2.320s systemd-udev-settle.service
          2.021s dev-mapper-ubuntu\x2d\x2dvg\x2droot.device
           809ms networking.service
           799ms fwupd.service
           732ms networkd-dispatcher.service
           683ms plymouth-start.service
           681ms ModemManager.service
           662ms NetworkManager.service
           644ms udisks2.service
mastakilla@UbuntuVM:~$ systemd-analyze critical-chain | head
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @10.189s
└─multi-user.target @10.189s
  └─kerneloops.service @4.921s +32ms
    └─network-online.target @4.918s
      └─NetworkManager-wait-online.service @4.640s +277ms
        └─NetworkManager.service @3.976s +662ms
          └─dbus.service @3.833s
mastakilla@UbuntuVM:~$

[Hero of Time]

Met LVM is UUID helemaal niet nodig, dat kan je dus weer gewoon terugdraaien. Het idee van het gebruik van de UUID is omdat de device node van partities/schijven met een normale indeling nog wel eens kon veranderen als je meerdere schijven hebt. Dat probleem heb je niet zo snel met LVM, tenzij je toevallig een schijf toevoegt van een andere installatie die dezelfde volumegroep en logische volumenaam bevat.

Dit probleem hoort natuurlijk niet, maar ik zou je toch willen adviseren om eens zonder LVM te werken, of iig om je swap er buiten te halen (schakel 'm desnoods even uit, hoef je niet direct een herinstallatie te doen).
Is er trouwens een specifieke reden waarom je voor LVM hebt gekozen in je VM?

[MAX3400]

Domme vraag maar 17.04 is pas toegevoegd in Workstation 14; ik neem dan ook aan dat 18.04 (als guest) pas in 14.x ondersteund wordt?

[Hero of Time]

Dat is gewoon VMware die zich indekt als iets niet zou werken, zoals de Guest Tools die niet compileren voor de kernel. Wil je daar geen gedoe mee hebben (terwijl de open-vm-tools het ook prima doen met VMware), dan pak je VirtualBox.

Maar het zal niet de reden van dit issue zijn vermoed ik zo.

[Mastakilla]

Als ik het goed begrijp zeg je dat UUIDs gebruiken niet nodig is, maar dat het ook geen kwaad kan. Mag ik ze gewoon laten staan? Of raad je echt aan om ze terug te vervangen?

Ik heb voor LVM gekozen omdat ik dat wat beter onder de knie heb, omdat we dit op het werk ook gebruiken. Het is ook gemakkelijk om FS groter te maken enzo. Liefst zou ik gewoon ook LVM blijven gebruiken...

Zal straks eens proberen of ik die Swap tijdelijk uitgezet kan krijgen.

VMware Workstation 12 herkent by default idd geen Ubuntu 18.04, maar dat zou op zich niet mogen uitmaken. VMware Workstation 14 kan ik jammergenoeg niet gebruiken omdat die voor geen meter werkt met mijn CPU (i7 920), maar zoals je zelf al opmerkt, herkent zelfs die Ubuntu 18.04 nog niet...

Ik gebruik, zoals Cannonical ook aanraad, gewoon open-vm-tools...

Enig idee hoe ik in de logs files ik die boot messages kan terug vinden? Kan ik ergens de verbose level nog verhogen? (heb nog niet zoveel ervaring met systemd)

[ Voor 21% gewijzigd door Mastakilla op 03-05-2018 09:50 ]

[Hero of Time]

Swap uitzetten is zo simpel als de entry in fstab weghalen of een comment voor zetten (laatste aan te raden ).

Meer informatie tijdens het booten is simpel: 'quiet splash' weghalen bij de boot opties. Dat kan dus eenmalig via het Grub menu en de entry bewerken gevolgd door F10 of ctrl+x, zoals onderaan het scherm staat.

[Mastakilla]

Heb intussen snapshot gerevert waar ik net de Ubuntu installatie + open-vm-tools installatie heb voltooid. (dus zonder UUIDs in /etc/fstab en initramfs-update enzo)

Heb vervolgens het volgende geprobeerd waarvan niets heeft geholpen (zelfs de "failed to connect to lvmetad" boodschap krijg ik niet meer opgelost)

* comment voor swap in /etc/fstab
* toch terug UUID geplaatst voor root FS in /etc/fstab
* update-initramfs -u
* quiet splash uit grub menu gehaald

Dit is een screenshot van de situatie nu:

Hij blijft hangen na "Begin: Running /scripts/local-premount ..."

edt:
ik wou enkele debug echos toevoegen aan dat local-premount script, maar

code:

root@UbuntuVM:~# cat /scripts/local-premount
cat: /scripts/local-premount: No such file or directory
root@UbuntuVM:~#

Is dat script generated-on-boot ofzo?

[ Voor 16% gewijzigd door Mastakilla op 04-05-2018 14:07 ]

[Hero of Time]

Dat script staat in de initramfs. Je moet het boot proces van Linux een beetje kennen om te weten hoe dit precies in elkaar steekt en wat er dus wanneer wordt gestart. Als je nog Windows 9x kent, of 3.11, dan kan je het een beetje vergelijken als eerst MS DOS starten voordat Windows wordt gestart. Er wordt dus eerst een basis stukje van de kernel geladen, de initrd (initial ramdisk) icm het initramfs (initial RAM file system). Die scant dan de hardware en laadt wat drivers om de kernel van de schijf te kunnen laden. Als dat eenmaal kan, zal wordt het initramfs gesloten en verandert / naar je harde schijf.

Wil je het script dus aanpassen, dan moet je op zoek naar waar het op je schijf zelf staat die tijdens update-initramfs wordt toegevoegd.

[Mastakilla]

Enig idee hoe ik "set -x" en "set +x" daar ergens in kan krijgen?
Of enig idee wat de timeout veroorzaakt (blijkbaar dus niet de swap)?

[Hero of Time]

Zoals gezegd, script zelf zoeken. Maar je kan ook met Google zoeken hoe je meer informatie krijgt tijdens het booten naast het weghalen van quiet en splash.

[Mastakilla]

Ik ben "down the rabbithole" gegaan en heb er een 'set -x' kunnen tussen wringen:

Het gaat wel degelijk om de swap:
/dev/mapper/ubuntu--vg-swap_1: UUID="2c893b15-9a8a-491e-8493-4504aa63e602" TYPE="swap"

Zelfs als ik hem in /etc/fstab uit commentarieer, dan nog blijft dit script op die UUID hangen. Dus helemaal staat ie dus nog niet uit.
Maar liever dan mijn swap uitzetten, zou ik graag het probleem met mijn swap gewoon oplossen

Hieronder wat meer de details...

Iets voor de timeout start Ubuntu:
/usr/share/initramfs-tools/scripts/local-premount/resume
(Ik heb de volgende belangrijke stappen in bold gezet)

#!/bin/sh

echo "start resume"
set -x
PREREQ=""

prereqs()
{
echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac

if [ -z "${resume}" ] || [ ! -e /sys/power/resume ]; then
exit 0
fi

. /scripts/functions
. /scripts/local

PAGE_SIZE=4096
if [ -x /bin/getconf ]; then
PAGE_SIZE=$(getconf PAGESIZE)
fi
export PAGE_SIZE

if ! local_device_setup ${resume} "suspend/resume device" false; then
exit 0
fi

DEV=$(readlink ${resume})
DEV=/sys/class/block/${DEV##*/}/dev
if [ -r "$DEV" ]; then
read MAJMIN < "$DEV"
fi
if [ -z "$MAJMIN" ]; then
exit 1
fi

if [ "${resume_offset}" -ge 0 ] 2>/dev/null; then
offset_option=$((${resume_offset} * ${PAGE_SIZE}))
SWAPTYPE=$(blkid -p -O ${offset_option} "${resume}" -s TYPE -o value)
MAJMIN="${MAJMIN}:${resume_offset}"
else
SWAPTYPE=$(blkid -p -o value -s TYPE "${resume}")
fi

case "${SWAPTYPE}" in
swsuspend|s1suspend|s2suspend|ulsuspend|tuxonice)
if [ -x /bin/plymouth ] && plymouth --ping; then
plymouth message --text="Resuming from $resume"
fi

echo "${MAJMIN}" > /sys/power/resume
;;
esac

In volgende file staat de functie local_device_setup:
/usr/share/initramfs-tools/scripts/local --> local_device_setup()
Daar geraakt Ubuntu tot het wait-for-root commando (dat ik nog niet heb terug gevonden)

# $1=device ID to mount
# $2=optionname (for root and etc)
# $3=panic if device is missing (true or false, default: true)
# Sets $DEV to the resolved device node
local_device_setup()
{
echo "start local device setup()"
local dev_id="$1"
local name="$2"
local may_panic="${3:-true}"
local real_dev
local time_elapsed
local count

# If wait-for-root understands this prefix, then use it to wait for
# the device rather than settling the whole of udev.

# Timeout is max(30, rootdelay) seconds (approximately)
local slumber=30
case $DPKG_ARCH in
powerpc|ppc64|ppc64el)
slumber=180
;;
*)
slumber=30
;;
esac
if [ ${ROOTDELAY:-0} -gt $slumber ]; then
slumber=$ROOTDELAY
fi

case "$dev_id" in
UUID=*|LABEL=*|/dev/*)
FSTYPE=$( wait-for-root "$dev_id" $slumber )
;;
*)
wait_for_udev 10
;;
esac

# Load ubi with the correct MTD partition and return since fstype
# doesn't work with a char device like ubi.
if [ -n "$UBIMTD" ]; then
modprobe ubi mtd=$UBIMTD
DEV="${dev_id}"
return
fi

# Don't wait for a device that doesn't have a corresponding
# device in /dev and isn't resolvable by blkid (e.g. mtd0)
if [ "${dev_id#/dev}" = "${dev_id}" ] &&
[ "${dev_id#*=}" = "${dev_id}" ]; then
DEV="${dev_id}"
return
fi

# If the root device hasn't shown up yet, give it a little while
# to allow for asynchronous device discovery (e.g. USB). We
# also need to keep invoking the local-block scripts in case
# there are devices stacked on top of those.
#
# in ubuntu, we should never actually enter this loop as wait-for-root
# above should waited until the device appeared.
if ! real_dev=$(resolve_device "${dev_id}") ||
! get_fstype "${real_dev}" >/dev/null; then
log_begin_msg "Waiting for ${name}"

while true; do
sleep 1
time_elapsed="$(cat /proc/uptime)"
time_elapsed="${time_elapsed%%[. ]*}"
time_elapsed=$((time_elapsed - local_top_time))

local_block "${dev_id}"

# If mdadm's local-block script counts the
# number of times it is run, make sure to
# run it the expected number of times.
while true; do
if [ -f /run/count.mdadm.initrd ]; then
count="$(cat /run/count.mdadm.initrd)"
elif [ -n "${count}" ]; then
# mdadm script deleted it; put it back
count=$((count + 1))
echo "${count}" >/run/count.mdadm.initrd
else
break
fi
if [ ${count} -ge ${time_elapsed} ]; then
break;
fi
/scripts/local-block/mdadm "${dev_id}"
done

if real_dev=$(resolve_device "${dev_id}") &&
get_fstype "${real_dev}" >/dev/null; then
wait_for_udev 10
log_end_msg 0
break
fi
if [ ${time_elapsed} -ge ${slumber} ]; then
log_end_msg 1 || true
break
fi
done
fi

# We've given up, but we'll let the user fix matters if they can
while ! real_dev=$(resolve_device "${dev_id}") ||
! get_fstype "${real_dev}" >/dev/null; do
if ! $may_panic; then
echo "Gave up waiting for ${name}"
return 1
fi
echo "Gave up waiting for ${name} device. Common problems:"
echo " - Boot args (cat /proc/cmdline)"
echo " - Check rootdelay= (did the system wait long enough?)"
if [ "${name}" = root ]; then
echo " - Check root= (did the system wait for the right device?)"
fi
echo " - Missing modules (cat /proc/modules; ls /dev)"
panic "ALERT! ${dev_id} does not exist. Dropping to a shell!"
done

DEV="${real_dev}"
}

[ Voor 186% gewijzigd door Mastakilla op 06-05-2018 00:15 ]

[Hero of Time]

Het 'wait-for-root' commando is een functie in het script, of van een eerder uitgevoerd script of ander bestand dat uitgelezen is.

Waar je ook aan moet denken is het feit dat Ubuntu 18.04 net uit is. En het is algemeen bekend dat Canonical Ubuntu releases uitbrengt ongeacht de staat van het geheel. Je zou nu heel diep kunnen graven voor een oplossing terwijl het gewoon een keiharde bug is. De standaard installatie gebruikt immers geen LVM.

Ik heb met Debian ook eens gehad dat de Testing installatie geen LUKS kon terwijl het wel een optie was. Het opzetten ervan is zo simpel als een partitie maken, daar een LUKS volume van maken, passphrase toekennen en het gaat de partitie voorbereiden. Dat laatste werd dus niet gedaan, dus hoewel de installatie zonder verdere problemen afrondde, had ik een niet-startend systeem vanwege de mislukte LUKS configuratie.
Het zou mij daarom niet verbazen dat je tegen iets vergelijkbaars aan loopt met Ubuntu.

Wil je een variabele verwijderen, en dat is de ondersteuning van VMware, dan gooi je dat eraf en installeer je VirtualBox. Worst case installeer je Ubuntu op je hardware zelf, maar ik heb zo'n vermoeden dat je tegen dezelfde issues aan gaat lopen.