☰

EC2-Volume wird nicht über fstab gemountet; manuelles Mounten erfolgreich

tag-icon • tag-icon mount fstab amazon-ec2
EC2-Volume wird nicht über fstab gemountet; manuelles Mounten erfolgreich

Ich habe eine Micro-Instanz mit Ubuntu 10.04 x86 (AMI ami-3e02f257). Sie hat das OS-Volume an /dev/sda1 angeschlossen und ein zweites Volume an /dev/sdf (gemeldet als /dev/sda1=vol-eaa0e982:attached:2011-03-08T17:17:42.000Z:false, /dev/sdf=vol-44a3ea2c:attached:2011-03-08T17:17:42.000Z:false).

fstab sieht folgendermaßen aus:

# /etc/fstab: static file system information.
# <file system>               <mount point>   <type>  <options>       <dump>  <pass>
proc                          /proc           proc    nodev,noexec,nosuid 0       0
LABEL=uec-rootfs              /               ext3    defaults        0       0
/dev/sda2  /mnt      auto  defaults,nobootwait,comment=cloudconfig  0  0
/dev/sdf   /mnt/osm  auto  defaults,nobootwait,comment=osmdata      0  0

Wenn ich neu starte, kommt /mnt/osm nicht online. Wenn ich es ausführe, sudo mount /dev/sdf /mnt/osmkommt das Volume sofort online. Dies funktionierte auf einer kleinen Instanz. Als ich nobootwaites entfernte, wurde die Instanz blockiert. Irgendwelche Vorschläge? Das Dateisystem muss online gehen, damit der darauf laufende Postgres-Cluster gestartet werden kann.

Antwort1

Haben Sie versucht, /dev/sda2 zu entfernen? Da es in der von Ihnen geposteten Blockgerätekonfiguration nicht definiert ist, könnte ein Problem vorliegen, da das Gerät nicht existiert. Ich bin nicht sicher, ob das Mounten beim Booten bei einem Fehler abgebrochen wird oder ob versucht wird, zusätzliche Geräte zu mounten. Wie von @richard-bentley erwähnt, verfügen EBS-gestützte Instanzen über keinen flüchtigen Speicher und dieser Teil des Befehls schlägt fehl.

Es ist zweifelhaft, dass das Problem irgendetwas damit zu tun hat, dass es sich um einen Mikrocomputer handelt, es sei denn, Sie sind von einer S3-gestützten Instanz zu einer EBS-gestützten Instanz gewechselt (was mit der Tatsache zusammenhängt, dass flüchtiger Speicher bei EBS-gestützten Instanzen nicht standardmäßig aktiviert ist).

Antwort2

Übrigens hatte ich dasselbe Problem auf einer kleinen Amazon Linux AMI-Instanz und es wurde durch die Option „nobootwait“ im fstab-Eintrag verursacht. Ich habe die fehlerhafte Option entfernt und die Installation beim Booten funktionierte einwandfrei.

verwandte Informationen