MLD Bug - MLD |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0000082 | MLD | [All Projects] VDR | public | 2014-05-11 16:43 | 2014-06-29 18:42 |
|
| Reporter | skippy | |
| Assigned To | clausmuus | |
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| OS Version | | |
| Product Version | 4.0.1 | |
| Fixed in Version | | |
| Paket Name und Version | install |
|
| Summary | 0000082: individuelle Installation schlägt fehl |
| Description | Habe eine individuelle Installation auf meinen MLD-WoZi durchgeführt. Dabei habe ich eine Systempartition und eine Datenpartition ausgewählt und beide formatieren lassen. Install.log und Meldung im Webif zeigt nur, dass die Systempartition formatiert wird. Datenpartition wird nicht angefasst.
Das nachfolgende Booten liefert Kernel-Panic |
| Steps To Reproduce | Zur Reproduktion habe ich mir in einer VM eine Platte mit 2 Partitionen angelegt und ebenfalls eine individuelle Installation durchgeführt. Hier wird ebenfalls die Datenpartition nicht formatiert. Beim Starten von der Installation erhalte ich die Meldung, dass kein System gefunden wird.
Eine normale Installation in der VM funktioniert korrekt. |
| Additional Information | Install.log vom MLD-WoZi
==start installation==
==format disk sda1==
WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL
WARNING! - see 'http://btrfs.wiki.kernel.org [^]' before using
fs created label (null) on /dev/sda1
nodesize 4096 leafsize 4096 sectorsize 4096 size 9.77GB
Btrfs v0.20-rc1
------ done ------
==install system on sda1==
Create subvolume '/mnt/sda1/mld '
Removing package install from root...
------ done ------
==write bootblock on sda==
/mnt/sda1/boot/syslinux is device /dev/sda1
------ done ------
==Installation completed== |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2014-05-11 16:43 | skippy | New Issue | |
| 2014-05-11 16:43 | skippy | Status | new => assigned |
| 2014-05-11 16:43 | skippy | Assigned To | => Christian |
| 2014-05-11 18:32 | MegaX | Assigned To | Christian => clausmuus |
| 2014-05-11 19:40 | clausmuus | Note Added: 0000138 | |
| 2014-05-11 19:40 | clausmuus | Status | assigned => resolved |
| 2014-05-11 19:40 | clausmuus | Fixed in Version | => install_0-42 |
| 2014-05-11 19:40 | clausmuus | Resolution | open => fixed |
| 2014-05-11 22:16 | skippy | Note Added: 0000139 | |
| 2014-05-11 23:35 | clausmuus | Note Added: 0000141 | |
| 2014-05-12 06:34 | skippy | Note Added: 0000143 | |
| 2014-05-12 10:27 | clausmuus | Note Added: 0000144 | |
| 2014-05-12 17:08 | skippy | Note Added: 0000149 | |
| 2014-05-12 17:14 | clausmuus | Note Added: 0000150 | |
| 2014-05-12 17:15 | clausmuus | Note Edited: 0000150 | bug_revision_view_page.php?bugnote_id=150#r51 |
| 2014-05-12 20:24 | skippy | Note Added: 0000153 | |
| 2014-06-29 18:42 | MegaX | Status | resolved => closed |
|
Notes |
|
|
|
Den Fehler, dass sich das installierte System nicht booten lässt, konnte ich nicht nachstellen (hast Du nen 64Bit Image genommen?).
Den Fehler mit dem Formartieren der Datenpartition habe ich behoben. |
|
|
|
(0000139)
|
|
skippy
|
|
2014-05-11 22:16
|
|
Ja, ist die MLD 4.0.1 64-bit. Auf beiden Systemen (MLD-WoZi und VM) wird nun die Datenpartition formatiert. Auf der VM startet das System nach der Installation auch sauber. Auf der MLD-WoZi erhalte ich nach wie vor Kernel panic.
Fehlermeldung:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2)
CPU: 0 PID: 1 COMM: swapper/0 Not tainted 3.14.2.41 # 1
Danach folgen Hareware name mit Namen des Mainboards, der Bios Version und dann ein Call Trace, der mir nichts sagt.
Vielleicht hast du ja da noch eine Idee woran es liegen kann. Ist bei mir das System wo ich mehrere Partitionen mit unterschiedlichen MLD-Versionen habe und diese über Grub starte.
Falls dir nichts dazu einfällt, schließe einfach das Ticket, da die genannte Problembeschreibung erledigt ist. |
|
|
|
|
Du bootest also von USB? Möglicherweise ändert sich der USB Device Name nach dem Installieren. Du kannst ja mal schauen welches Device als root eingetragen wurde und ob das passt oder es mit ner anderem root Angabe versuchen.
Claus |
|
|
|
(0000143)
|
|
skippy
|
|
2014-05-12 06:34
|
|
Nein, in diesem Fall boote ich von einer eingebauten SSD (/dev/sda2). Wie kann ich erkennen, welches Device als root eingetragen wurde?
Ich werde auch noch mal meinen Grub-Eintag überprüfen und hier posten. Vielleicht habe ich da ja Mist gebaut. Geht aber erst heute Abend |
|
|
|
|
Ach so, dass geht um Deinen manuel erstellten Grub Eintrag. In dem Fall gehe ich fest davon aus, dass da nicht root=/dev/sda2 drin steht oder sda2 falsch ist.
Du kannst unter /boot/syslinux/extlinux.cfg nachschauen wie die Append Zeile aussehen sollte. |
|
|
|
(0000149)
|
|
skippy
|
|
2014-05-12 17:08
|
|
also ich kann keinen Fehler entdecken. Es lief ja auch mit der MLD 4.0.0, die vorher auf /dev/sda2 war. Ich habe lediglich die UUID angepasst. Der Eintrag unter /dev/sda5 funktioniert auch. Das ist meine MLD 4.0.0 die standardmäßig gebootet wird. Hier mal die Einträge aus der custom und die blkid,vielleicht fällt dir was auf:
menuentry "MLD-4.0.1-64bit" {
insmod part_msdos
insmod btrfs
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root c3f1d4c9-497a-4851-bc7e-5cec2354140e
linux /boot/kernel root=/dev/sda2
}
menuentry "MLD-4" {
insmod part_msdos
insmod btrfs
set root='(hd0,msdos5)'
search --no-floppy --fs-uuid --set=root 56a3a74f-e3bb-430d-afe5-f1752d5011ce
linux /boot/kernel root=/dev/sda5
}
root@MLD-WoZi:/home/juergen# blkid
/dev/sda1: LABEL="MLD-Boot" UUID="364b5cec-57e0-4a74-9194-26e57cf14ca7" TYPE="ext4"
/dev/sda2: LABEL="MLD-4.0.1-64bit" UUID="c3f1d4c9-497a-4851-bc7e-5cec2354140e" UUID_SUB="a4f74369-2fad-44c1-84ac-82b59f8c9c73" TYPE="btrfs"
/dev/sda3: LABEL="MLD-3" UUID="9f85c977-6d43-4c26-9129-dd85348565bb" TYPE="ext4"
/dev/sda5: UUID="56a3a74f-e3bb-430d-afe5-f1752d5011ce" UUID_SUB="816a13a1-be49-4e68-b36d-b996ffa92512" TYPE="btrfs"
/dev/sda6: LABEL="Daten" UUID="28941916-594e-40f0-bdaf-1e2aeab16eda" TYPE="xfs"
/dev/sda7: UUID="2b9f52e7-8b0d-4570-8e63-6fccb7151bca" TYPE="swap"
/dev/sdb1: UUID="5b6392ab-4706-44da-ba62-07cf4e079cd0" TYPE="xfs"
/dev/sdb2: UUID="2ac71ad6-d2bd-46d2-9c4e-d79b4e1a9f47" TYPE="ext4"
/dev/sdb3: UUID="8a9e0e32-a094-4b13-8b7f-f2f4edb21d60" TYPE="swap" |
|
|
|
(0000150)
|
|
clausmuus
|
2014-05-12 17:14
(edited on: 2014-05-12 17:15) |
|
Ich sehe da auch nichts offensichtlich falsches...
Hast Du mal geschaut, wenn Du /dev/sda2 mountest, ob das nen normales root filesystem zu sehen ist?
Das sollte ja so ähnlich aussehen wie bei ner 4.0.0 Installation.
|
|
|
|
(0000153)
|
|
skippy
|
|
2014-05-12 20:24
|
|
Ja, sieht gut aus:
MLD> mount /dev/sda2 /mnt/sda2
MLD> cd sda2/
MLD> ls -l
drwxrwxr-x 1 root root 624 May 11 21:58 bin
drwxr-xr-x 1 root root 206 May 11 22:00 boot
drwxrwxr-x 1 root root 4 May 11 21:59 data
drwxrwxr-x 1 root root 16 May 11 22:00 dev
drwxrwxr-x 1 root root 972 May 11 22:00 etc
-rwxrwxr-x 1 root root 1999 May 11 05:04 init
drwxrwxr-x 1 root root 100 May 11 04:35 lib
drwxrwxr-x 1 root root 40 May 11 05:04 lib64
drwxrwxr-x 1 root root 0 May 11 22:00 media
drwxrwxr-x 1 root root 8 May 11 22:00 mnt
drwxrwxr-x 1 root root 0 May 11 22:00 proc
drwxrwxr-x 1 root root 8 May 11 21:59 root
drwxrwxrwt 1 root root 300 May 11 21:59 run
drwxrwxr-x 1 root root 660 May 11 22:00 sbin
drwxrwxr-x 1 root root 0 May 11 22:00 snapshots
drwxrwxr-x 1 root root 0 May 11 22:00 sys
drwxrwxrwt 1 root root 298 May 11 22:00 tmp
drwxrwxr-x 1 root root 54 May 11 04:35 usr
drwxrwxr-x 1 root root 52 May 11 21:59 var |
|