[Sammelthread] ZFS Stammtisch

[zapopost]

Ein LSI Logic 1048 z.B. kann keine Platten über 2TB, daher kann es an der Emulation liegen. Versuche doch auch hier den Paravirtual.

Ich fand die Idee ganz spannend, leider kann ich Paravirtual nicht auswählen, wenn im ESXi als OS Solaris 11 eingestellt ist.
Habe dann alle anderen verfügbare Varianten durchgetestet: wenn ich die Platte an den (virtuellen) SATA Controller hänge, wird die Platte in napp-it richtig erkannt.

Aber danach hat napp-it wiederholt eine kernel panic geworfen und sich auf die Nase gelegt. Passiert z.B. immer dann, wenn ich in der GUI Smartinfo aufrufe.

=> Leider läuft das System dann nicht mehr so stabil das ich es produktiv einsetzen kann.

Update:
Kernel panics mit dem SATA Controller treten auch nach einiger Dauer im laufenden Betrieb auf

 

[tekken321]

Hallo, ich wollte mir demnächst einen Server(NAS,Cloud,diverse VM) ins Haus stellen (Dell T30,Host Proxmox), da ich allerdings mehr wie 4 HDD's anschliessen möchte, werde ich wohl noch ne Adapterkarte für mehr SATA-Anschlüsse einbauen. Nachdem ich nun einiges über ZFS gelesen habe, dürfte es ja eig. egal sein wenn ich ein RaidZ2 mache,wobei dann Platten intern und über die Adapterkarte amgeschlossen sind,oder?Gibt's da eventuell noch was zu beachten?

Vielen Dank schonmal

Grüße tekken321

Gesendet von meinem SM-G935F mit Tapatalk

 

[MrDeluxe]

Hab den HBA H310 damals geflasht. Die PCIe Karte habe ich zur virtuellen Maschine über PCI Passthrough durchgereicht. Da gibt es dann nichts weiter zu beachten.

 

[Swivel]

Hi,

wie kann ich denn die Snapshots von Napp-it auf einen externen Laufwerk bzw in ein anderen pool speichern?
Meine Idee ist eigentlich dass ich (ja ich weiß, dass man das nicht macht) einen zweiten Pool erstellt und dort die Snaps hin speichert. Später dann auf eine externe Festplatte.

zweite Kurze Frage:
Sollte ich später zu meinem z1 pool einen mirror hinzufügen, wird das ein Raid10 und erst dann gefüllt wenn der z1 voll ist?

 

[gea]

!:
ZFS ist ein CopyOnWrite Dateisystem bei dem bei jeder Änderung eines Datenblocks dieser neu geschrieben wird. Der alte Stand wird zum Überschreiben freigegeben oder bei einem Snap eingefroren. Snaps sind also immer Bestandteil eines Dateisystems.

Kopieren kann man Snaps via ZFS Replikation zu einem anderen Dateisystem oder per normalem Datei-Kopieren.

2.
Wenn man ein weiteres vdev hinzufügt so ist das zweite vdev zunächst leer. Bei jeder Änderung wird aber ZFS die Änderungen verstärkt auf des freiere vdev schreiben.

Ein z1 um einen Mirror ergänzen geht zwar, ist aber eher unüblich. Normalerweise bleibt mann bei einem vdev-Typ also mehrere mirrors (Raid-10) oder mehrere Z1 (analog Raid 50)

 

[Swivel]

!:
ZFS ist ein CopyOnWrite Dateisystem bei dem bei jeder Änderung eines Datenblocks dieser neu geschrieben wird. Der alte Stand wird zum Überschreiben freigegeben oder bei einem Snap eingefroren. Snaps sind also immer Bestandteil eines Dateisystems.

Kopieren kann man Snaps via ZFS Replikation zu einem anderen Dateisystem oder per normalem Datei-Kopieren.

2.
Wenn man ein weiteres vdev hinzufügt so ist das zweite vdev zunächst leer. Bei jeder Änderung wird aber ZFS die Änderungen verstärkt auf des freiere vdev schreiben.

Ein z1 um einen Mirror ergänzen geht zwar, ist aber eher unüblich. Normalerweise bleibt mann bei einem vdev-Typ also mehrere mirrors (Raid-10) oder mehrere Z1 (analog Raid 50)

Okay, super Erklärung wieder Also lieber noch eine Platte kaufen und ein z1 zum Pool hinzufügen.


Wenn ich die Snaps via ZFS Replikation exportiere .... ist es dann möglich, wenn ich ein ZFS System habe ohne ECC RAM , dass die Dateien fehlerhaft geschrieben werden können und unbrauchbar werden? (es geht wirklich nur um die snaps)

 

[besterino]

Du kannst dafür wunderbar eine externe USB-Platte nehmen: anstöpseln, Pool („simple“, also keine Redundanz) kreieren, replikations-Job für gewünschtes (bereits vorhandenes) Dataset mit gewünschten Einstellungen (Anzahl Snaps, Haltezeit usw.) erstellen, replizieren (Job laufen lassen), dann Pool auf USB-Platte exportieren, Disk abziehen, fertig.

Beim nächsten Backup-Run Platte wieder dran, Pool importieren, Job laufen lassen, exportieren, abziehen, fertig.

Ein „one-Disk“ Backup reicht m.E., wenn du nicht allzu große Datenmengen ins Backup hauen musst und du z.B. eine gewisse Redundanz bereits auf dem Primär-Pool hast - dann ist das nur „worst case“ Schutz wenn die Hauptkiste abfackelt, einen Stromschlag wegbekommt oder sonst physisch so richtig einen abkriegt. Daher sollte allerdings auch die USB-Platte möglichst räumlich weiter weg liegen.

Lüppt 1A (mit Solaris 11.3 plus Nappit).

 

[layerbreak]

Das sollte direkt gehen
- Zertifikat updaten
- omnios repo abmelden
- neues 124 ce repo anmelden
- updaten per pkg update
- reboot

vgl auch seite 6
http://www.napp-it.org/doc/downloads/setup_napp-it_os.pdf

Entschuldigung, dass ich jetzt erst antworte. Ich hatte Deine Antwort schlicht und einfach übersehen.

Update von OmniOS r151022 auf OmniOSce r151024 hat so wie von dir beschrieben, ohne Probleme funktioniert.
Dank deiner obigen PDF und dem Updateguide von OmniOSce.

Dank Bootenvironment eh kein Problem

Stimmt mit eins der Feature auf das ich in keinem Falle mehr verzichten will.

 

[Turboschnecke]

Was sagt mir folgender Fehler auf der OmniOS Console nach einem Reboot:
scsi: /pci@0,0/pci8086,1901@1/pci1000,3020@0 (mpt_sas0)

Es ist ein Supermicro X11SSM-F Board und zwei M1015 Controller, die ich auf IT geflashed habe. mpt_sas0 ist wahrscheinlich ein Controller. Aber was sagt die Meldung? Beide Controller leuchten, wenn die Kiste angemacht wird.

Edit: Ich hatte erst 6 Platten (ST8000DM002) drin. Da habe ich dann nach und nach die Platten in Napp-It angezeigt bekommen. Hatte Sie wohl nicht richtig in die Schächte gesteckt. Da kam der Fehler meistens nach nem Cold Boot. Nach einem Reboot war der dann weg. Jetzt habe ich 6 weitere Platten (ST8000DM004) dazugesteckt und jetzt kommt der Fehler sekündlich. Reboot bringt auch nix. In den Trays leuchten alle Lampen, wo Platten drin sind. Wie kriege ich nun raus, was kaputt ist?...

 

[gea]

Einfach alle Platten entfernen und booten.
Wenn OmniOS ohne Platten sauber bootet scheint die Basishardware zu funktionieren.

Dann Platte um Platte per hotplug hinzufügen, jeweils kurz warten bis die Platte erkannt wird (Menü Disks oder format). Wenn das System plötzlich hängt hat man eine Problemplatte.

 

[Turboschnecke]

Es gehen die 6 neuen alleine und die 6 alten alleine. nur alle zusammen bewirkt eine flut an aborted commands und diesem scsi error. Netzteil zu schwach? Ist ein BeQuiet Dark Power 11 Pro 550W.
Aber dann probiere ich das mit den Platten nochmal

Edit: Es gibt eine Platte, die hoch T und H Werte in der IOSTAT Spalte hat. Was ist das? Sobald die Platte draussen ist, bootet alles... In einem anderen Slot gesteckt, geht auch alles... Ist der Slot in der Backplane defekt?

 

[Trambahner]

Auf die Optane (280er U2) bin ich gespannt im Pool, meine kommt diese Tage.

 

[gea]

. Ist der Slot in der Backplane defekt?

Das oder eins der Kabel.

 

[Turboschnecke]

Hab die Platte jetzt einfach mal woanders reingesteckt.
Jetzt habe ich ein anderes Problem: Wie funktioniert das mit dem SMB Zugriff? Habe den Pool jetzt importiert. Habe den SMB Dienst aktiviert, aber wie gebe ich das jetzt so frei, dass ich wieder drauf zu greifen kann über SMB? Unter ZFS Filesystems taucht der Pool auf. Aber ich kann ihn nicht direkt freigeben. Off/On gibt es erst für unter Ordner, aber ich seh da die Ordner nicht, die ich unter FreeNAS angelegt hatte. Unter FreeNAS gab es den Pool "Storage". Dann habe ich dort eine Freigabe erstellt, die ich SMB genannt habe. Und darin habe ich dann verschiedene Ordner angelegt. Und da würde ich gerne wieder landen. Aber unter Napp-It taucht das nicht auf? Es gibt den Pool Storage, den ich nicht freigeben kann. Daneben gibt es noch ein paar ".system" Ordner und einen Jails Ordner, der auch noch von FreeNAS kommen müsste. Aber wo ist der Rest? Unter Used ist auch nur der direkte Pool belegt, beim Rest ist nur Kleinkram drin.
Bin ich zu doof?

 

[gea]

FreeNAS nutzt SAMBA als SMB Server. Den gibt es für jedes Linux/Unix unabhängig vom Dateisystem. SAMBA weiß also nichts von ZFS sondern gibt einfach Ordner frei - egal ob einfacher Ordner oder ZFS Dateisystem. SAMBA hat damit den Vorteil dass man Shares unabhängig von ZFS verwalten kann aber den Nachteil dass ZFS Snaps als Windows "Vorherige Version" nicht so einfach out of the Box tut und dass die ganze Rechteverwaltung auf Unix/Linux Rechten basiert. Unter FreeNAS kann und sollte man auf dem Pool zwar auch ZFS Dateisysteme für Userdaten anlegen, muss das aber nicht. Man verliert allerdings die einfache Zuordnungen von Solarish bei dem eben alles (Shares, Snaps, Eigenschaften) in ZFS integriert ist.

SAMBA gibt es unter Solaris zwar auch, Oracle/ Illumos nutzt (und pflegt) aber einen eigenen kernelbasierten SMB (und NFS) Server und der ist voll in ZFS integriert und nutzt Windows ntfs artige ACL mit Vererbung. Shares sind hier eine Eigenschaft eines ZFS Dateisystems. Man kann also die Shares von SAMBA (wenn es sich da um einfache Ordner handelte) nicht direkt nach Solaris und den freien Solaris Forks übernehmen.

Der einfachste Weg ist, sich zunächst eine ZFS Struktur überlegen und dann eins oder mehrere ZFS Dateisysteme anlegen. Anschliessend die Dateien die momentan als einfache Ordner direkt unter dem Pool liegen in diese ZFS Dateisysteme verschieben. Das kann per Console und mv oder per Midnight Commander geschehen, alternativ von Windows aus mit WinSCP. Anschliessend alle ACL Rechte zurücksetzen bzw neu setzen (Kann aus Windows als user root geschehen). Alternativ an der Console SMB für den Pool kurzzeitig einschalten. Später sollte man das ausschalten weil man den Pool selber (ist auch ein ZFS Dateisystem) lediglich als Container und zum Setzen von Vorgaben für die enthaltenen Dateisyste nutzen sollte.

Anschliessend kann man diese Dateisysteme einfach per smb=on freigeben. Alle SMB Eigenschaften sind in ZFS integriert (siehe Menü Services > SMB > Properties). Die Konfigurationsdateien von SAMBA gibt es nicht.

 

[Turboschnecke]

Tausenddank! Das habe ich verstanden
Jetzt muss ich nur noch mit WinSCP klarkommen^^

 

[gea]

oder auf der Console bzw. in napp-it im cmd-Feld folgendes eingeben
zfs set sharesmb=on Storage

Das aktiviert SMB für den Pool Storage.
Dann per SMB als root anmelden und Dateien verschieben.

WinSCP + Putty sind dennoch die Tools der Wahl um Unix aus Windows komfortabel zu nutzen.

 

[Turboschnecke]

Gibt es bei den Usernames eine Längebeschränkung? Hab nur den Fehler bekommen, dass der Benutzername zu lang sei (9 Zeichen hat der Name). Auf der Übersichtsseite war der Benutzer dann aber da, aber ich kann ihn bei den ACLs als Benutzer nicht wählen. Da gibt es nur root und meinen zweiten Benutzer.

 

[gea]

Unix war ursprünglich auf 8 Zeichen beschränkt. Aktelle Systeme erlauben längere Namen, teilweise wird das aber angemeckert da manche "Alt-Tools" damit Probleme haben. Für einen normalen SMB Filer sollte das aber kein Problem sein.

Man muss den Benutzer aber ein Passwort setzen da dadurch auch ein SMB Passwort angelegt wird - Vorraussetzung dass man ihn per SMB nutzen kann

 

[Turboschnecke]

Ich habe den Benutzer mit Passwort eingetragen und beim Hinzufügen kam dann die Meldung, dass der Benutzername zu lang ist. Aber wenn er in der Liste auftaucht, hat es funktioniert? Dann probiere ich es nochmal mit dem Passwort setzen, ob der Nutzer dann bei den ACLs auftaucht.

Edit:
Nachdem ich im Usertab nochmal ein PW gesetzt habe, taucht der Benutzer jetzt auf. Danke!

 

[gea]

Nach zwei Tagen im Storagelab

Sync write Performance mit Plattenpools + Optane: mehrere hundert MB/s
mit sync = disabled > 1GB/s

Solaris (Original ZFS v.27) massiv schneller als OmniOS (Open-ZFS)
sowohl auf den Pools wie über SMB, insbesondere auch bei sync-write und Plattenpools

Kann jemand mit Solaris und eventuell OmniOS die Werte (Windows, >=10G, SMB bzw iSCSI mit AJA, Crystal oder ATTO) grundsätzlich bestätigen. Die Ergebnisse sind teils zu gut um wahr zu sein! Ich weiss zwar dass Solaris richtig schnell ist aber sync write unter SMB mit einem Plattenpool und Optane 900P Slog von 1.6 GB/s scheint mir trotz überragendem RAM caching von Solaris heftig. (oder SMB mit 2 GB/s ohne sync )

siehe 5.
http://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf

 

[Trambahner]

Sollte ich mir da anfangen, um das Laufwerk "d6" Sorgen zu machen? Die Smart-Werte zeigen nichts Auffälliges. Hab nun mal das Kabel erneuert und auf Sitz geprüft.
Welche Files das betraf, kann man nicht auf die Schnelle rausfinden (BSD)?

Edit: Sind wohl Kontaktprobleme bei den Sata-Kabeln; hatte beim "rumkabeln" nun auch vereinzelte Ausfälle anderer Laufwerke. Sch.... billige Stecker, warum mussten auf dem X10SL7 auch einfache Sata-Buchsen am SAS2308 sein statt SFF-8087 o.ä.

# zpool status zhgst
  pool: zhgst
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: [url="http://illumos.org/msg/ZFS-8000-9P"]ZFS-8000-9P[/url]
  scan: resilvered 1.50M in 0h0m with 0 errors on Wed Dec 20 12:57:41 2017
config:

NAME              STATE        READ WRITE CKSUM
  zhgst             ONLINE       0     0     0
    raidz2-0        ONLINE       0     0     0
            gpt/d1  ONLINE       0     0     0
            gpt/d2  ONLINE       0     0     0
            gpt/d3  ONLINE       0     0     0
            gpt/d4  ONLINE       0     0     0
            gpt/d5  ONLINE       0     0     0
            gpt/d6  ONLINE       0     0     5

 

[Trambahner]

Es wird skuril. Oder zumindest für mich eher unverständlich.

Ich hatte nun das Backup von gestern (von Server1 (Supermicro X10SL7) nach Server2 (Dell T20) per NC und ZFS send/receive) Datei für Datei mittels Binärvergleich vergleichen lassen. Hat natürlich einige Stunden gedauert. Vergleich via SMB-Shares. Beide Maschinen sind ESXI-AIO mit FreeBSD 11 als Nas.
ZFS sagt auf beiden Maschinen "ok, keine Probleme".
Gegen Ende des Vergleichens schmeisst Freecommander auf einmal lauter Unterschiede in den Dateien. Haufenweise in einzelnen Files. Auch bei solchen in einem 2. Durchlauf, die beim 1. Durchlauf schon als identisch gelistet wurden. Erst Unsicherheit, doch langsam leichter Anflug von Unsicherheit und nahender Verzweiflung.
Weitere ZFS send/receives von Server1 nach Server2 werden mit Hinweis auf Checksum-Fehler in den Streams sofort abgebrochen.

Angst um die Datenbestände steigt: "was ist der richtige Stand"...."OMG"....
Nun, als senden und receiven wir Snaps innerhalb der gleichen Maschine (Server1). ????? geht?????? Interessant.
Server2 (Dell) komplett heruntergefahren und neu durchgestartet.

Und nun: keine Unterschiede in den Files wenn ich sie wie vorher binär vergleiche. Alles scheint ok.
Auf der einen Seite bin ich froh: alles wohl konsistent. Aber wie kann sowas auf einmal kommen? Ram-Defekt im Server2? Der hat ECC und bei so starken Problemen würde die Kiste wohl stehenbleiben/abstürzen. Netzwerk-Problem? Evtl. in Zusammenhang mit dem ESXI? IMO könnens nur diese zwei sein, denn der Pool ist ja offenbar clean und ZFS würde nach meinem Kenntnisstand ja auch keine korrupten Files ausliefern.
Irgendwie trau ich nun der Kiste2 bzw. deren Installation nicht mehr wirklich und würde wirklich gern rausfinden, was da war.


Aber zumindest: ZFS hatte immer recht ("No known data errors") und wohl offenbar richtige Daten. Während der User Phantome jagte.

 

[MrDeluxe]

Hallo,

ich habe Napp-IT frisch auf einem virtualisierten OmniOS installiert (2vCPUs qemu64, 8GB RAM). Nach der Installation bin ich auf <serverip>:81 und klicke auf login mit dem Firefox v57, nun passiert gar nichts mehr und ich lande auf einer Fehlerseite mit dem Fehler "Nullgrößenantwort".
prstat zeigt mir, dass die Kiste total überlastet ist:

3259 napp-it 6180K 4168K run 19 10 0:00:01 2.4% perl/1
3237 napp-it 6348K 4340K run 23 10 0:00:01 2.2% perl/1
3211 napp-it 6076K 4064K cpu1 24 10 0:00:01 2.1% perl/1
3255 napp-it 5708K 3692K run 28 10 0:00:01 2.0% perl/1
3232 napp-it 6084K 4076K run 19 10 0:00:01 2.0% perl/1
3296 napp-it 5684K 3656K run 18 10 0:00:01 2.0% perl/1
3241 napp-it 6396K 4388K run 29 10 0:00:01 2.0% perl/1
3265 napp-it 5972K 3964K run 19 10 0:00:01 1.9% perl/1
3270 napp-it 5980K 3972K run 26 10 0:00:01 1.8% perl/1
3228 napp-it 6052K 4044K run 19 10 0:00:01 1.8% perl/1
3291 napp-it 5684K 3656K run 19 10 0:00:01 1.7% perl/1
3275 napp-it 5708K 3696K run 19 10 0:00:01 1.6% perl/1
3250 napp-it 5804K 3796K run 29 10 0:00:01 1.6% perl/1
3284 napp-it 5660K 3632K run 19 10 0:00:01 1.5% perl/1
3282 napp-it 5684K 3656K run 19 10 0:00:00 1.5% perl/1
12 root 9852K 8496K sleep 59 0 0:10:57 1.5% svc.configd/18
3277 napp-it 5684K 3656K run 19 10 0:00:00 1.5% perl/1
3293 napp-it 5684K 3656K run 19 10 0:00:00 1.5% perl/1
3267 napp-it 5804K 3796K run 19 10 0:00:01 1.5% perl/1
3246 napp-it 2476K 1712K run 29 10 0:00:01 1.4% svcs/1
3273 napp-it 5708K 3692K run 19 10 0:00:01 1.4% perl/1
3262 napp-it 5684K 3664K run 19 10 0:00:01 1.4% perl/1
3286 napp-it 5684K 3656K run 29 10 0:00:00 1.4% perl/1
3289 napp-it 5708K 3692K run 19 10 0:00:00 1.4% perl/1
3279 napp-it 5724K 3704K run 24 10 0:00:00 1.3% perl/1
3258 napp-it 2296K 1156K run 29 10 0:00:00 1.2% ps/1
3304 napp-it 5384K 3240K run 29 10 0:00:00 1.1% perl/1
3299 napp-it 5304K 3164K run 29 10 0:00:00 1.0% perl/1
2821 root 4700K 3364K cpu0 59 0 0:00:04 1.0% prstat/1
3302 napp-it 5344K 3196K run 29 10 0:00:00 0.9% perl/1
3269 napp-it 2296K 1156K run 29 10 0:00:00 0.9% ps/1
3306 napp-it 5328K 3184K run 29 10 0:00:00 0.8% perl/1
3309 napp-it 5336K 3188K run 29 10 0:00:00 0.7% perl/1
2998 napp-it 8236K 6248K sleep 29 10 0:00:04 0.6% perl/1
3006 napp-it 8236K 6248K sleep 29 10 0:00:04 0.5% perl/1
3312 napp-it 5192K 2440K run 24 10 0:00:00 0.5% perl/1
2924 napp-it 9196K 7248K sleep 29 10 0:00:06 0.5% perl/1
3315 root 4616K 2532K sleep 39 0 0:00:00 0.4% sleep/1
268 root 7920K 4716K sleep 59 0 0:01:48 0.4% nscd/32
12499 root 3772K 2356K sleep 59 0 0:04:13 0.3% bash/1
1 root 2696K 1772K sleep 59 0 0:00:47 0.3% init/1
Total: 116 processes, 500 lwps, load averages: 40.20, 19.39, 7.80

Schließe ich die Verbindung zu Napp-IT ist alles wieder in Ordnung. Die Host CPU ist nicht die stärke (E-5502 mit Passmark 1375 Punkten) aber das Napp-IT so viel Ressourcen der CPU verbraucht, dass es nicht mal startet, hätte ich nicht erwartet.

Falls sich gea diesem Post widmen sollte: Warum hast du auf Perl gesetzt?
ix-slogan-big

 

[gea]

Bei mir liegt prstat bei 0.1 bis 0.3 (virtualisiertes OmniOS unter ESXi) wenn acc und monitoring aktiv sind.

Last erzeugt zunächst der Webserver.
Das ist aber minihttpd. Es gibt kaum einen der weniger Last macht.

Last wird hauptsächlich durch die Hintergrunddienste Acceleration und Monitoring erzeugt. Die setzen fortlaufend Systembefehle ab. Das geschieht zwar aus Perl heraus, die Last wird aber nicht durch Perl erzeugt. Am einfachsten die mal ausschalten (Topmenü acc und mon, neben Logout).

Warum Perl
Es gibt zwar bessere Scriptsprachen für einen Webserver. Napp-it ist allerdings primär ein System-Management-Tool das Systemprogramme aufruft und auswertet. Dafür ist Perl perfekt geeignet. Auch ist es bei Unix immer dabei und muss nicht extra installiert werden. Zudem beherrscht Perl sauberes Datei Filelocking. Bei PHP wäre ich da schnell auf SQL angewiesen um sauberen concurrent access zu erlauben.

 

[MrDeluxe]

Ich komme leider nur bis zur Login-Seite (admin.pl). Wenn ich auf erstmalig auf Login klicke bleibt er hängen mit der oben gezeigten Auslastung. Ich müsste also die Acceleration und Monitoring per CLI deaktivieren, nur wie?

 

[gea]

entweder den evalkey in /var/web-gui/_log/appliance.log löschen

oder zwei Dateien anlegen z.B.
touch /var/web-gui/_log/accelerate_off
touch /var/web-gui/_log/monitor_off

dann napp-it neu starten
/etc/init.d/napp-it restart

ansonsten mal format aufrufen.
Das macht napp-it auch als erstes nach dem Login um die Platten zu ermitteln. Vielleicht hängt das System an dieser Stelle.

 

[MrDeluxe]

Hat nix gebracht.

root@OmniOS:~# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
0. c1d0 <QEMU HARDDISK=QM00001-QM00001-0001-12.00GB>
/pci@0,0/pci-ide@1,1/ide@0/cmdk@0,0
Specify disk (enter its number): 0
selecting c1d0
NO Alt slice
No defect list found
[disk formatted, no defect list found]

Ich würde dann mal das OmniOS neu aufsetzen und Napp-IT erneut installieren.

 

[McStarfighter]

@gea:

Ich habe mir jetzt mehrfach auf einem Proxmox napp-it 17.12 installiert und die Web GUI war dann auch immer erreichbar. Nach einem Reboot hingegen sind napp-it und die Proxmox Web GUI nicht mehr aufrufbar (connection refused).
Führt napp-it beim ersten Reboot noch irgendwelche Änderungen durch, die am Ende beide Web GUIs zerschießen können?
Erreichbar ist der Server an sich (Putty, WinSCP, WebGUI von Emby Server, portainer, TVHeadend), nur eben nicht die beiden!

Bin da ziemlich ratlos!

 

[VirtuGuy]

Läuft der "pveproxy" Service? Hast du ggf die Proxmox Firewall nach der Installation aktiviert?