onderka.com

Debian auf der Linkstation Live

Hinweis: Die Seite "Debian auf der Linkstation Live" ist vor mehr als einem Jahr geschrieben oder zuletzt editiert worden und unter Umständen veraltet oder nicht mehr korrekt.

Dank fjen jetzt mit Debian 7.

Während ältere Linkstations neben dem U-Boot Loader noch den Kernel und anderes im Flash haben, hat die Linkstation Live nur noch das U-Boot im Flash. Dieser Bootloader lädt dann von der ersten Partition der Platte Kernel und Ramdisk nach.

Die Standard-Einstallungen sind:

  • Kernel: sda1:/uImage.buffalo
  • Ramdisk: sda1:/initrd.buffalo

Debian kann aus dem Rettungsmodus der LS heraus installiert werden, oder man beginnt die Installation von Debian auf einer neuen, frischen Platte – In meinem Fall einer 2TB Hitachi HDS722020ALA330. Die originale Platte kann nach Ausbau gesichert werden.

Unter „Debian GNU/Linux lenny rootfs image v0.3.2“ auf linkstation.agrimm.de ist eine Anleitung zu finden, nach der ohne das Gehäuse zu öffnen Lenny installiert wird. Das funktioniert tadellos, getestet und für gut befunden. Wenn man die Sache jedoch das erste Mal macht, ist es sehr handlich, einen Linux-PC mit SATA-USB-Adapter in greifbarer Nähe zu haben, glaubt mir… Ich beschreibe hier die „Aufzucht“ einer neuen Platte und die Installation ohne Rettungs-System, Telnet und apc_commander, sondern mit Ausbau der originalen Festplatte und Vorbereiten der neuen an einem Linux-PC.

Grundlagen

Es wird angenommen, dass die Festplate der LS am PC angeschlossen /dev/sdb ist, benötigt werden lediglich ein paar Dateien, die alle im Text verlinkt sind.

Öffnen der Linkstation

Bei Yasunari Yamashita ist in wenigen Bildern zu sehen, wie das Gehäuse geöffnet wird. Das Gehäuse der LS-Revisionen V1-V3 ist mehr oder weniger identisch. Zusammenfassung:

  • Wahlweise Lüfter entfernen, dazu Schraube auf der Oberseite herausdrehen und Lüfter herausziehen, Kabel abstecken
  • An der Unterseite entlang der Gehäuse-Naht mit einem Cutter durch die Aufkleber schneiden
  • Spätestens hier sollte man merken, dass die Gewährleistung/Garantie erlischt, und ich keinerlei Verantwortung für Euer Vorgehen übernehme!
  • Die 2 Clips vorsichtig nach innen drücken zum Aushängen
  • Hälften trennen, Rest zerlegen, Platte ausbauen, an einen PC anschliessen oder beiseite legen und eine frische SATA-Platte an den PC klemmen

Sichern der Festplatte

Das Sichern der Original-Platte und Übertragen der 1. Partition 1:1 ist nicht nötig, auch wenn oft geschrieben wird, die Partition #1 sei auf jeden Fall und uuuuuuunbedingt zu klonen oder auf die neue Platte zu zaubern. Meine LS-CHL-V2 mit 1TB-Platte hatte eine GPT-Partitionstabelle auf der Platte, wie anscheinend viele der neueren LS – Und? Es läuft. Auch mit Debian auf einer Platte mit MS-DOS-Partitionstabelle. Ohne Hexerei und Klonen.

parted/gparted kann mit GPT-Tabellen umgehen, wo fdisk versagt.

Die Partitionen der Buffalo-Installation sind wie folgt:

Verwendet man die original-Platte weiter, sollte man mit Acronis True Image o.ä. zuerst ein Voll-Backup machen, um den Ursprungs-Zustand wieder herstellen zu können. Alternativ dazu kann man die Platte am PC unter Linux mit z.B. dd sichern.

Partitionieren und Dateisysteme

Das System benötigt zumindest eine /boot und eine root-Partition. Es ergibt sich damit etwas in der Art:

Anlegen von

sdb1, primär, mit 100MB, ext2/3/4, bootbar (schadet nicht)
sdb2, primär, mit je nach Bedarf 4-10GB, ext2/3/4
sdb3, primär, als Swap
sdb4, primär, ext2/3/4, mit dem Rest – bei mir knappe 1TB

mkfs.ext3 /dev/sdb1 -L BOOT/boot formatieren
mkfs.ext3 /dev/sdb2 -L ROOTroot formatieren
mkswap /dev/sdb3 -L SWAP – Swap erstellen
mkfs.ext3 /dev/sdb4 -L DATA/data formatieren

mount /dev/sdb2 /media/sdb2root mounten

mkdir /media/sdb2/boot – Verzeichnis für /boot erstellen
mkdir /media/sdb2/data – Verzeichnis für /data erstellen

mount /dev/sdb1 /media/sdb2/boot/boot mounten
mount /dev/sdb4 /media/sdb2/data/data mounten

Die Parameter für das Root- und das Daten-Dateisystem anpassen, 100 reservierte Blocks und Filesystem-Checks nur alle 171 bzw. 169 Tage sind OK:

tune2fs -i 171 -c 0 -r 100 /dev/sdb1
tune2fs -i 171 -c 0 -r 100 /dev/sdb2
tune2fs -i 169 -c 0 -r 100 /dev/sdb4

Root-Dateisystem auspacken

Im Ordner, in dem sdb2 (root) gemountet ist, wird ein Debian-„Tarball“ und danach der Inhalt von /boot und /lib/modules entpackt.

„Isch hab da ma watt voorbereitet“: Einen Tarball und Kernel+Module sowohl für die Linkstation Live V1 als auch für die V2 mit Kernel 2.6.22.7 (v1) bzw. 2.6.22.18-88f6281 (v2):

Andere Debian-Tarballs für ARM9-Systeme sind z.B.:

Auspacken

Kernel Für Linkstation Live V1 / Kernel 2.6.22.7:

Für Linkstation Live V2 / Kernel 2.6.22.18:

Damit ist das System installiert und die restlichen Anpassungen können gemacht werden:

Anpassungen

Zumindest folgende Anpassungen sollten auf der Partition sdb2 vorgenommen werden:

  • Löschen von etc/udev/rules.d/70-persistent-net.rules, sodass eth0 der richtigen MAC-Adresse zugeordnet wird
  • Editieren von etc/network/interfaces, anpassen der Netzwerk-Konfiguration
  • Editieren von etc/hostname
  • Editieren von etc/ntp.conf, bevorzugte(n) NTP-Server eintragen
  • Editieren von etc/apt/sources.list, Auswahl des bevorzugten Debian-Mirrors
  • Editieren von etc/fstab – Dateisystem-Typen überprüfen, z.B. xfs oder ext3 für /dev/sda6 einsetzen, je nach verwendetem Dateisystem

Achtung: Auf meiner LS v2 ist das aktive Netzwerk-interface eth1, das habe ich jedoch erst nach ca. 12x neu installieren bemerkt… Man sollte sich also gleich angewöhnen, eth0 und eth1 zumindest auf DHCP zu stellen!

Wenn man schon dabei ist, sollte man zusätzlich gleich die Einstellungen für die Ethernet-Devices egiga0 und egiga1 einfügen, manche Kernel verwenden diese Device-Namen für Marvell Gigabit-Controller, und wenn man einmal einen eigenen/anderen Kernel probiert, sollte das LAN auf jeden Fall gestartet werden können.

/etc/network/interfaces

Boot

Nach Unmounten der Partitionen mit umount /dev/sdb?, Abstecken und Einbau der Platte in die Linkstation sollte diese jetzt erfolgreich booten und man kann sich per SSH anmelden. Auf ping reagieren die Original-Kernel von Buffalo nicht unbedingt, also im Zweifelsfall mit nmap oder Angry IP-Scanner das Netz durchforsten oder die Logs des DHCP-Server ansehen.

Das root-Passwort meiner Filesystem-Images lautet root.

Passwörter gleich mit passwd ändern…

Einstellungen

Ein wenig Kosmetik ist noch nötig, damit alles rund läuft:

Die Zeitzone mit dpkg-reconfigure tzdata einstellen, mit apt-get update und apt-get upgrade das System auf den neusten Stand bringen, danach mit aptitude/apt-get nach Belieben Software installieren.

blstools statt micro-evtd installieren und konfigurieren

blstools wird für die Kommunikation mit dem Kurbox/Linkstation Controller benötigt und steuert die LEDs, USB, Lüfter und fragt (wenn vorhanden) die Buttons ab. blstools benötigt hddtemp und smartmontools, beides bereits im Image enthalten.

Ich bevorzuge blstools statt micro_evtd. Falls es nachträglich aktualisiert oder auf einer anderen Linkstation installiert werden soll:

Das Skript /etc/init.d/lsmonitor hat in der aktuellen Version 0.2.0 anscheinend einen Fehler beim Auslesen der Festplatten-Temperatur: Die Zeile 52,

mußte ich durch

ersetzen.

USB ein-/ausschalten

Das USB-Subsystem inclusive Stromzufuhr der USB-Buchse kann deaktiviert werden. Vor Anstecken eines USB-Geräts muss USB mit /etc/init.d/usb start aktiviert werden, nach umounten eines Datenträgers kann USB mit /etc/init.d/usb stop wieder komplett abgeschaten werden.

Das sollte es schon gewesen sein. Die Linkstation verwendet noch den originalen „Buffalo“-Kernel, ein Tausch gegen einen selbstgebackenen ist von wechselndem Erfolg gekrönt.

Links

Fooboot

Mit fooboot, einem Wrapper-Skript für fw_printenv und fw_setenv, kann auf einfache Weise zwischen Booten von Platte („Normaler“ Kernel oder EM-System) und TFTP-Boot umgeschaltet werden: davy_gravy’s Verzeichnis mit fooboot-0.5.1.tar.gz und anderen nützlichen Dateien.

Foonas-EM

Ein nettes Rettungssystem, falls mal nixmehr geht, ist uImage_em_lspro_sda1kernel_sda2rootfs-setup:

Wenn man einer Linkstation diese Kombination aus Kernel und Ramdisk per TFTP von der Adresse 192.168.11.1 aus zur Verfügung stellt, hat man damit ein komplett lauffähiges System, das man mit Telnet erreichen kann (Login: root, Passwort: hydr0g3n) und mit dem man ohne Zerlegen der Linkstation ein Debian aufsetzen kann – Mehr Info hier.

Mehr zum Thema

Andere Seiten unter 'Linkstation Live (LS-CHL) V1, V2 und V3'

Ähnliches

Seiten und Einträge, gefunden nach Tags.

42 Kommentare

  1. Geprüft und für gut befunden *thumbs-up*

  2. Hi,

    ist bei deinem 2.6.22.18 Kernel zufällig mit CONFIG_SCSI_MULTI_LUN=y compiliert?

    Gruß,
    Nigg

  3. Hey,

    vielen dank für die tolle anleitung , bin gerade dabei debian auf einer 1.5 TB platte für die linkstation live zu präparieren.

    Hattest Du besondere Gründe, von XFS nach ext3 zu wechseln? Gibt es performance-unterschiede?

  4. Woher der 2.6.22.18 Kernel kommt weiss ich nicht mehr. Eine .config hab‘ ich leider auch nicht, so kann ich nicht sagen, ob SCSI_MULTI_LUN aktiviert ist. Wieso denn? Kartenleser oder was ähnliches?

    ext3 nehm‘ ich aus Gewohnheit, und da ich xfs noch immer nicht ganz traue. Sollte ich ihm nochmal ’ne Chance geben?

  5. hab ein externes Gehäuse für max 4 Hdds mit eSATA und USB. Die Linkstation erkennt leider immer nur die erste Platte im Gehäuse.

  6. Ich schau mal, ob ich die .config für meinen Kernel irgendwoher bekomme…

    Ed:

    So, hier wäre eine .config für 2.6.29.1 mit CONFIG_SCSI_MULTI_LUN=y.

  7. ich habe wieder Hoffnung, aber ich habe leider überhaupt keine Erfahrung im Kernel-selber-schrauben. Ich dachte eher die .config wäre weniger das Problem.

  8. Hi Stefan,

    du hast Recht, man sollte definitiv ext3 oder jfs
    verwenden. Mir war es nicht bekannt, aber xfs hat auf
    arm offenbar einige Probleme.

    Bei mir (LS-DHGL) führte XFS-formatierte root-partition in kombination mit neueren kernels zu einer reboot-Schleife.

    Nun läuft aber lenny + 2.6.29 auf meiner LS-DHGL 🙂

  9. so, kernel gebaut .. funzt natürlich nicht, boot-schleife oder so 🙂

  10. Das macht der 2.6.26 Kernel von davy_gravy (in den Links oben) bei mir auch, ohne irgendwelche Logs. Eine serielle Schnittstelle habe ich nicht, deswegen kann ich nicht sagen, woran es liegt.

    Ich weiss aber, dass die Kiste bootet: Sie ist kurz mit Ping zu erreichen, beim richtigen Timing auch per SSH. Aber sie startet eben auch (spätestens) gleich nach dem Login neu. Ich tippe auf Probleme mit dem Watchdog.

    Ich werd‘ wohl demnächst mal die serielle Schnittstelle rausführen und testen…

    Als Feedback-Umfrage… Wer von Euch hat denn mit meinem Tarball, Kernel und Modulen seine Linkstation zum Laufen bekommen?

  11. Sie läuft mit dem Kernel/Tarball von dir perfekt … nur eben ohne die oben genannte USB-Erkennung.

  12. Hi Stefan,

    nur als Anmerkung, da man leicht auf die Terminologie hereinfällt, ich habe eine „Linkstation Live V2“, das ist eine neuere LS-DHGL. Nicht zu verwechseln mit den Linkstation Live LS-CHL, die in 3 Versionen existiert.

    Die DHGL scheint nicht mit deinen Kernels zu laufen, obwohl es evtl. auch an anderen details gelegen haben kann.

    Jedenfalls läuft jetzt alles hervorragend mit dem 2.6.29.1er kernel und lenny root von davy_gravy verwendet, zusammen mit original
    u-boot.buffalo und deiner leeren initrd.

    Weiter Unterschiede, die für die DHGL vs CHL beachtet werden sollten: sda1 musste ich als ext2 mit 256 MB formatiert, 1 GB war dem DHGL-u-boot offenbar zuviel.

    Baue jetzt mal nen akutelleren Kernel (mal schauen ob’s 2.6.36 tut).

    Bei Interesse könnte ich auch mal ein tarball schnüren, den du zu deinen vorbereiteten CHL-firmwares gesellen kannst.

  13. Das is ja schonmal was ;P

    Ich hab heute mal einen USB-Kartenleser angesteckt (Mein 2.6.22.18-Kernel), es werden 4 Geräte gefunden lt. dmesg. Ich werd wohl Anfang nächster Woche doch mal nen neuen Kernel backen.

    Zu blöd, dass ich nicht wirklich weiss, woher mein Kernel kommt… Hab bissl die Übersicht verloren…

    Edit:

    Öh, zefix – Der 2.6.22.18-88f6281 ist ein original Buffalo-Kernel, klar.

  14. kann dmesg leider nich aufrufen:“program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO“

    Der Tarball war wirklich klasse und sehr sehr hilfreich. Aber das mit dem Kernel wäre ja sahne!

  15. Das Problem mit smartctl/smartmontools sollte mit 5.36 behoben sein, ist es aber wahrscheinlich nicht so ganz. Bis zu einem Debian-Update von smartmontools werden die Logs also wahrscheinlich weiter vollgemüllt werden.

    Funktionell läuft es bei mir, nur eben die Warnung, dass smartmotools/smartctl veraltete System-Aufrufe verwendet. Ich kompiliere jetzt mal smartmontools 5.40 „zu Fuß“.

    Edit:

    Nix, auch mit 5.40 „program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO„. Dann liegt’s wohl (auch) am Kernel.

  16. root@nas ~ # mount -t ntfs-3g /dev/sdb1 /data/disk1
    FATAL: Module fuse not found.

    ntfs-3g ist drauf, fuse ist wohl nicht dabei beim kernel?

  17. @anon: Ich habe eine LS-CHL-V2, die sich in /proc/buffalo/firmware auch so meldet:

    PRODUCTNAME=LS-CHL-V2(YURYAKU)

    Siehe hier. Von der ist auch der „Stock“ 2.6.22-18-Kernel.

  18. hm, scheint leider nichts zu nützen das Script, wenn der Kernel ohne das CONFIG_SCSI_MULTI_LUN-Flag compiliert wurde :/

  19. Hallo,

    wie sieht es mit einem Upgrade von Lenny auf Squeeze aus?
    geht das ohne die Kiste zu zerschiessen?

  20. Hab’s noch nicht probiert/für nötig gehalten. Aber wenn Du vor dem dist-upgrade das Filesystem an einem PC sicherst kann ja nix schiefgehen…

  21. Puh – 2 Tage bastel ich rum, und gerade wenn alles geht finde ich bei der suche nach dem blstools-fix diesen Post hier – perfekt zusammengefasst und schön zu lesen hier.

    Auf meinem CH1.0TL (PRODUCTNAME=LS-CHL (YURYAKU)) rennt nach meiner Bastelei der 2.6.31.8-svn22059 (armv5tel) kernel mit einem kompletten Lenny – wäre viel schneller gegangen mit deinem Post hier 🙂

    Mein Ziel ist es auf der Kiste noch OpenVPN als Client zum laufen zu bekommen – dazu brauche ich aber definitiv einen eigenen Kernel mit tun.o als modul – soweit korrekt?

    Grüße und ‚weiter so!‘ – S.

  22. Hallo,

    ich bin verwirrt und schaffe es einfach nicht von 2.6.31.8-svn22059 auf die 2.6.29.1 von davy_gravy oder irgend einen anderen Kernel zu Updaten. Module sind in /lib/modules, ich verändere einzig die uImage.buffalo von der aus deinem tar-Ball zur neuen Kernel-Version und schon bootet die Station nicht mehr. Logs gibt’s keine, auch kein Reboot, nada.
    Wie hast du / habt ihr es denn geschafft das hinzubekommen?

    Merci & Grüße

  23. Bei mir ist’s andersrum =)

    Wenn ich irgendeinen x-beliebigen Kernel mit Modulen nehme, sei es davy_gravy oder sonstwas, dann bootet die Kiste nimmer. Keine Ahnung was das ist…

  24. Ganz genau so ist das hier auch. Es funktioniert mit dem Standard-Kernel, mit keinem anderen.
    Es gibt keine Logs in keiner Form. Da wir den Standard uBoot verwenden auch keine möglichkeit an die Bootlogs zu kommen(?). Auffällig ist auch: sehr häufig in Foren ist die Boot-Ver. 1.09 mein System hat aber 1.10 – hier fand ich aber auch noch keinerlei Infos zu den Unterschieden. Serielle Schnittstelle habe ich hier leider nicht – envars kann ich auch nicht schreiben.
    Ich bin verwirrt! 🙂

  25. etwas hakt bei mir(LS-CHLv2,1 TB,einrichten per debian-Laptop):
    ich wollte ich das root-Filesystem(/dev/sdb2) auf 10G vergrössern,und musste dazu die dahinterliegenden partitionen löschen. Beim Neuanlegen sagt Gparted, dass GPT Partition Table keine extended Partitions zulässt.
    Habe jetzt sda1 (boot) mit 1 G, sda2 (root) mit 10G, sda3(swap) mit 1G und sda4 für den Rest. Brauch ich denn überhaupt extended Partitions?

  26. Um sda5 anzulegen, welche als Swap verwendet wird, muss man eine erweiterte Partition verwenden – als primäre Paritionen kann man nur 1-4 anlegen. Wie im Text geschrieben benötigt man jedoch – zumindest bei mir – keine GPT-Partition.

  27. Hi,

    ich habe seit kurzem ein Linkstation Live und überlege das Debian draufzubügeln.

    Ich habe beim Datentransfer ~16MiB/s und das im gbit netzwerk. Normalerweise habe ich ~60MiB/s.

    Ist das mit dem Debian immernoch so langsam?

    Als Mediaserver würde ich FireFly oder MediaTomb nutzen wollen und als Bittorrent Client Torrentflux. Mute ich der Linkstation damit zuviel zu?

    Gruß
    D3f3kt

  28. Einen uPNP-Server habe ich nicht am Laufen, ich verwende Twonky auf meinem HP X312-NAS – Aber Torrentflux läuft einwandfrei.

    Mit der verbauten CPU und der Hardware generell (SATA, RAM, LAN) wirst Du aber nichts über 15-20MB/s erwarten können.

    Das X312 macht unter Linux mit dem 4-Kern-Atom und Software-RAID ca. 85MB/s R/W.

  29. @Stefan, danke für die Info.

    Dann geht das Ding zurück. Hätte nicht gedacht, das die 400MHz CPU so stark den Datendurchsatz senkt.

  30. Ich teste morgen nochmal den Durchsatz!

  31. Hi, hier die Antwort auf meine mail an Buffalo bezgl. der Datenrate von nur 16MB/s.


  32. Sehr geehrter Herr XXXXXXXX,

    vielen Dank für Ihre Email.

    Die LinkStation Live LS-CHL ist eine NAS aus dem untersten Preisbereich. Um diesen halten zu können, ist hier eine 400 MHz starke CPU verbaut, deren Leistung ausreicht, um die NAS im klassischen heimischen 100MBit-Netzwerk zu betreiben.

    Leistungsstärkere Geräte wären die LinkStation Pro LS-XHL mit einem 1,2 GHz starken Prozessor oder die neue LinkStation Pro LS-VL mit einem 1,6 GHz starken Prozessor. Beide LinkStation Pro liegen jenseits der 42 MByte/s schreibend in einem Gigabit Netzwerk.

    mit freundlichen Grüßen,
    best regards

    Joerg Andreas
    Sales Engineer Central Europe
    BUFFALO TECHNOLOGY

  33. Moin,
    Das mit der Geschwindigkeit stimmt so nicht.
    Ich habe die Firmware 1.10 am laufen (noch nicht verändert).
    CIFS= 20 MB/s
    FTP= 38 MB/s
    Dies kommt natürlich immer auf die Grösse der Datei an.
    Gruss

  34. Klar kommt es auf die größe der Datei und vor allem das Protokoll an – man sieht schon, dass FTP viel weniger Overhead hat.

    38MB/s habe ich auch mit FTP oder NFS nicht geschafft, das sieht doch garnicht mal so schlecht aus!

  35. Moin Stefan,

    Hab gestern meine LS-CHL mal nach deiner Anleitung auf Lenny bringen wollen, aber leider hat es nicht so ganz hingehauen 🙁
    (Boot-Cycle)

    Wenn ich das richtig verstanden habe, dann haben wir beide zumindest die gleiche Version.
    LS-CHL – rotes interface – 64 MB Ram – Kernel von Haus aus 2.6.22.18
    Meine Firmware war allerdings 1.10 und BOOTVER=0.09
    /proc/buffalo/firmware meldete sich auch als LS-CHL und nicht wie bei dir mit LS-CHLv2
    Ausserdem habe die 1TB und nicht die 2TB Version.

    Nun hänge ich aber in irgendeiner Boot-Schleife. Linkstation blinkt blau, lüfter geht an, nach 15 sek geht der lüfter aus, und kurze zeit später auch die LS. Dann beginnt das Spiel von vorne…

    Was ich gemacht habe:
    (erstmal viel rumgespielt, bis ich mich entschlossen habe deine Version zu nutzen ;-))
    Habe aber nix an den Partitionen geändert. Nur Debootstrap etc.

    1. Platte ausgebaut und an einen Linux pc geklemmt
    2. dein image rootfs nach sda2
    3. sda1 mit ext3 formatiert
    4. dein image v2 Kernel 2.6.22.18 nach sda1
    5. fstab editiert, da sda2 und sda6 xfs sind

    die Datei etc/udev/rules.d/70-persistent-net.rules existiert übrigens bei mir nicht..??

    Hab also nicht die Partitionsgrössen geändert.. scheint aber genügend platz gewesen zu sein..

    Die Boot Schleife hängt doch irgendwie damit zusammen, dass er kein uImage bzw. keinen Kernel findet.. Aber das ist doch vorhanden..??

    Macht ext2 zu ext3 eigentlich einen Unterschied in der fstab? Sind doch eigentlich kompatibel..

    Danke und Gruss
    Duffy

  36. Moin,
    nur noch mal der vollständigkeit halber…
    Nachdem ich mit dem Punkt „Partitionieren und Dateisysteme“ fertig bin, kann ich doch mit dem Punkt „Root-Dateisystem auspacken“ weitermachen. Oder?
    Du lieferst ja eigentlich alles mit ..
    Gruss

  37. Moin,
    habe die Firmware 1.37 mod 1 installiert und bin dann nach deiner Anleitung vorgegangen. Nun hat es funktioniert..
    Danke dafür

  38. Du hast die Shonk 1.37-mod1 geflasht und danach die Platte nach Anleitung am PC bearbeitet?

    Ich habe keine Ahnung was die Firmware ändert, aber es muß ja etwas mit der Partitionierung zu tun haben, wenn Du die Inhalte gelöscht und die Archive entpackt hast.

  39. Moin,
    ja genau.

    also die Partitiontable habe ich mit sicherheit nicht angefasst .. will ungerne sda6 wieder draufschaufeln müssen 🙁
    Das einzige was ich gemacht habe, ist mkfs auf sda1 und sda2. Dieses wird die Firmware wohl auch ausführen..
    Ich hatte dann irgendwo gelesen, dass diese schleife entsteht, wenn boot nicht gelesen werden kann.

    Was nun allerdings sehr mehrwürdig ist:
    Ein tftp mit der 1.10 oder foonas-em lässt die box nur dauerhaft blau blinken.
    Irgendwie sind meine partitionen wohl versaut, so dass diese systeme nicht starten können 🙁 hatte auch mal was mit ner inode von 128 gelesen.. ??

    Werde wohl doch mal meine partitionstabelle komplett neu machen müssen. Vielleicht startet dann auch endlich foonas-em?
    Oder hast du eine idee woher das dauerblinken (also ewiger startvorgang) kommen könnte?

    Gruss

  40. Seelenteufel666

    Schade das hier nicht auch noch ne Erklärung zu finden ist wie man ein Kernel Update macht. Das fehlt hier noch total. Durch die Beschreibung habe ich meine LS-CHL v2 auf Debian bekommen aber leider fehlt mir die Funktion ein Kernel Update zu machen vielleicht gibt sich hier nochmal jemand die mühe.

    Sonst aber super anleitung

  41. Hallo zusammen, hat jemand vielleicht einen Hinweis, wie ich zeitgesteuertes Runterfahren/Aufwachen hin bekomme. Oder zumindest für den Anfang: einen sauberen Shutdown über script.
    Grüße

Seite Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Captcha * Time limit is exhausted. Please reload CAPTCHA.