Debian GNU/Linux

Debian 7.4 alatt a napokban frissítődött a CHROMIUM v.35-re , és érdekes módon nem hajlandó érzékelni a billenyűzeten a "í" -nek megfelelő nyomógombot, bármilyen billentűzetkiosztásban.
Nálatok is ez a jelenség megjelent, mi lehet a megoldás ? Megvárni a v.36-ot ? :)
(Ezt a hozzászólást "Iceweasel" alól írom itt hibátlan)
Ugyanezen a gépen windows7 alatt a CHROME v.35 nem mutatja ezt a hibajelenséget.

Raspberry Pi board, Raspbian linux, Huawei E303 USB modem.

Ha kézzel indítom (pon gprs), akkor megy klasszul, órákig, napokig, nincs vele gond.

Ha viszont automatikusan szeretném indítani, pl. /etc/network/interfaces vagy /etc/rc.local esetleg cron-ból,
akkor a csatlakozás létrejöttekor azonnal lefagy az egész, és az alábbi hibaüzenetet kapom:

Unable to handle kernel NULL pointer dereference at virtual address 00000014

Egyszerűen nem értem a dolgot, ha parancssorból indítom, akkor pedig megy rendesen.

Próbáltam másik számítógép USB portjáról táplálni, azután egy 5V - 26A -es táppal is, de mindig ugyanígy lefagy, mert pár helyen táp gondokat írtak, hasonló hiba esetén. Bár furcsa, hogy mi a különbség ha a rendszer induláskor vagy cron-ból illetve ha én parancssorból indítom, mármint táp ügyileg.

A Bluetooth fehér folt a számomra - ez az első próbálkozásom.
Első lépésben, azt szeretném elérni, hogy a Linux boxomat (semmi különös) bluetooth -on át elérjem, XP klienssel (egyenlőre) - szeretnék egy vezeték nélküli konzolt beállítani. Ráadásul NEM akarok semmilyen ablakozós felületet, tiszta parancssor, minden sallang nélkül.
Rengeteg google -zás után, ahol a legtöbb cikk arról szól hogyan csatoljak fel a gépre ezt-azt a következőkre jutottam:
Szükséges csomagok: bluez és a python-gobject
Telepítés után, ha bedugom a dongle-t szó nélkül feláll a szerkezet :)

$hcitool dev
  hci   "mac address"

Ahhoz, hogy a box scannelhető legyen (a windows kliens gépről) két kipróbáltan működő parancs is van:

#hciconfig hci0 piscan
#dbus-send --system --dest=org.blez /org/bluez/hci0 org.bluezAdapter.SetMode string:discoverable

Én az elsőt használom - kicsit egyszerűbbnek tűnik :)
Hosszas keresgélés után megtaláltam mivel tudok a saját gépemnek pin kódot "csinálni":
$bluetooth-agent --adapter hci0 1234 "mac address"
Ha ezek után XP alól scannelek, látja a gépet ("hostname"-0) és itt megrekedtem :(
Úgy tűnik, regisztrálni kell a soros kommunikációt mint szolgáltatást:
$spdtool add --channel=n SP
Ennek dacára, he benézek a scannelés eredményébe NEM látom hogy lenne soros port szolgáltatásom, a "#hciconfig -a" kimenete "Networking" és "Telephony" - ami megfelel az XP által jelzetteknek.
Elindítottam a soros bluetooth soros portot is:
$rfcomm listen /dev/rfcomm0 n
(az n a csatornaszám - ez sem igazán világos miért is kell de legyen)
Ha (valamelyik cikk alapján) az XP -n elindítom a hyperterminált a (egy másik azonos típusú USB -vel felszerelve) beállítva a bluetooth által létrehozott virtuális portot (com6) akkor elvileg, ha kiadok egy ilyet:
$echo "teszt" > /dev/rfcomm0
annak meg kellene jelennie a terminálon - semmi nem történik, sőt a Linux kijelenti hogy "NO such a device" - de ez sem igaz, mivel:
$ls -la /dev/rfcomm?
crw-rw--T root dialup /dev/rfcomm0
(a "T" -még nem tudom hova tenni)
Másik szimptóma, hogy a hyperterminál "csatlakoztatásakor" nincs autentikáció kérés - ha scan ablakban XP rákattintok a "Dialup vlmi" akkor kérte - beírtam, de a státusz továbbra is "Not connected".
Rengeteg cikket megnéztem, de nem találok más beállítani valót - ez is kicsit szokatlan, hogy ennyire nincs ez a szolgáltatás beállításhoz valami segéd script - mintha ezt csak GUI felől használnák :(
Mi kellhet még?

Sziasztok!

A mai napon elvegeztem egy "beallitasok visszaallitasa muveletet" a zentyal szerverunkon , mert a postfix olyan szinten megorulkt , hogy mar kibirhatatlan volt , nem lehetett bejelentkezni a fiokokba , illetve minden masodik levelet kuldott csak el.

Sajnos a beallitasok visszaallitasa utan azt tapasztaltam , hogy elvesztek a levelek a fiokokbol , gyakorlatilag egy fiok levelei sem maradtak meg a visszaallitas elottrol , holott en nem rendszer visszaallitast csinaltam , csak a konfig fileokat allitottam vissza egy 2 nappal korabbi allapotra , erre most /var/vmail konyvtarban a felhasznaloi fiokok merete minimalisra csokkent , viszont a szabad hely a szerveren ugyanannyi maradt mint a visszaallitas elott volt.

Aa kerdesem az lenne , hogy szerintetek van esely arra , hogy vissza tudjam allitani a leveleket , es ha igen akkor , hogyan kellene nekikezdenem , vagy ez mar halott ugy , es torodjek bele , hogy elveszett több ezer levél.

ui: biztonsagi mentes van , de sajnos csak heti szinten , es igy csak a multhet csutortoki leveleket tudom visszaallitani , ami több ezer levél elvesztését jelentené.

Bármi eszetekbe jut legyetek szivesek leirni , az állásom múlik rajta! :(

Előre is köszönöm a segítséget!

A címben említett telefont szeretném használni kis netbookomon, mely a legfrissebb Debian-t futtatja. Van-e valakinek tapasztalata működik ez?
Milyen dokumentációk vannak, akár angol nyelven? Telepítendő csomagok, konfig fájlok, stb?
Köszönöm.

Friss alap Debian 7 rendszer. Konzolból telepítettem a Gnome-ot. Hozzáadtam a magyar nyelvet a localeshez. Gnome alatt viszont a rendszerbeállítások belül az us billenytyűzeten kívül mást nem lehet hozzáadni. Ugyanez a helyzet, ha XFCE-t telepítek.

Abba a problémába futottam bele, hogy alapból csak TLS/SSL-en engedem az SMTP azonosítást, de most szükség lenne egy dinamikus IP-s hoszt miatt egy a nem ssl-es azonosításra. Rögtön kapott egy extra portot ez a funkció, de az auth_advertise_hosts -al képtelen vagyok összehozni és már elfogyott a gugli is.

Itt járok (extraport az egy normál pozitív egész szám :) ):

auth_advertise_hosts = ${if or { \
{ eq{$tls_cipher}{}{}{*} } \
{ eq{$interface_port}{extraport}{*}{} } \
}{yes}{no} }


Erre ezt a hibát kapom, pedig többször végignéztem: "failed to expand ... missing } at end of condition inside "or" group". Mindezt nem induláskor, hanem már miután elindult és jönnének be a levelek.

Olyat találtam, aki ACL-ből oldaná meg, de azt nem érzem túl szép megoldásnak és a további ACL-eket kerülném.

Sziasztok!

Valaki megátkozta ezt a gépet, mert vonzza a problémákat :-(

Első felvonás az volt, hogy nem ment a hálókártya gigabiten. A hálózat fali aljzatának cseréje megoldotta.

Most két dologgal nem bírok:

1. Beletettem egy Addonics ADSA3GPX1-2E 2 eSATA II PCI-Express kártyát, de az lspci, lshw, dmesg parancsok kimenetében nem lelem. Sőt a BIOS és a HP Insight Diagnostics programja sem látja, csak annyi bejegyzést találtam, hogy "PCI-E Slot1 Available". Nincs semmi különbség dmesg-ben, syslog-ban, lsmod-ban, ha bent van a gépben a kártya vagy nincs. Ha betöltöm a sata_sil24 modult - mely elvileg ezt a kártyát hajtja -, akkor sincs semmi változás.
2. Az update-initramfs -u parancsra olyan initrd.img-t generál, melyről nem bootol be.

Update 2014.05.17. 21:45:

1. Ez a kérdés továbbra is fenn áll, mivel nem értem, hogy miért nem működik a kártya a gépben.
2. A második kérdésre a megoldás:
   A telepítés kezdetén expert install-t választottam és az alap rendszer telepítésénél az initramfs-tools beállításánál azt az opciót választottam, hogy "targeted initrd" legyen az alapértelmezett.
   Ennek hatására a /etc/initramfs-tools/conf.d/driver-policy file-ba a MODULES=dep bejegyzés került, mely felülírja a /etc/initramfs-tools/initramfs.conf-ban beállított értéket. Ezt a sort kommentbe téve vagy MODULES=most-ra átírva az update-initramfs hatására bekerültek - sok egyéb modul mellett - az ata modulok is a létrejövő initrd image-be, mely így majd négyszerese lett, de a terrás háttértárolók világában a 3MB vagy 11MB nem okoz problémát. A lényeg, hogy a hiányzó modulok bekerültek az initrd.img-be és bebootol a gép, nem kell tartanom attól, hogy egy kernelfrissítést követően valamikori reboot után nem indul el a Debian.

   Széljegyzet a margóra: Érdemes a /etc/initramfs-tools/update-initramfs.conf-ban az alapértelmezett backup_initramfs=no bejegyzést yes-re megváltoztatni, így automatikusan készül mentés az initrd.img-ről.

Update 2014.05.18. 16:00:
Megfordult a fejemben, hogy elhalálozott a kártya és nem is működik, de kipróbáltam a kártyát egy desktop gépben és ott szépen teszi a dolgát. Azt hiszem, hogy holnap felhívom a HP-t és kérek tőlük egy kis supportot.
Ha szerintük sem megy, akkor használom majd az USB 3-as csatlakozókat, a tervezett eSATA kártya helyett, úgysem sokszor lesz ráaggatva külső HDD.

Update 2014.05.20. 18:45:
HP support sem talál rá okot, hogy az Addonics ADSA3GPX1-2E 2 eSATA II PCI-Expresscard miért nem megy a gépben. Lehet, hogy halott a slot, így küldenek egy új alaplapot.

Update 2014.05.21. 17:45:
Új alaplap megjött és beüzemelve. Helyzet változatlan :-(
Labda HP supportnál.

Update 2014.05.27. 13:30:
A HP-nál a hibajegyet lezárták azzal, hogy nincs hw hiba, a Debian és a választott kártya nem támogatott.
Íme a levél, amire gondolom már nem is reagálnak.

Tisztelt XXXX!

On Sun, 25 May 2014 at 20:48, XXXX wrote:

> Az AHS log szerint hardware hiba/probléma nem található a szerverben.
>
> MicroServer Gen8 esetében a támogatott operációs rendszerek:
>
> Windows Server 2008/2012,
> RedHat 6
> SLES 11
> VMware 5.x

Fentiek miatt regisztráltam magam a Red Hat oldalán és a hét folyamán
telepíteni fogom a Red Hat Enterprise Linux Server (v. 6 for 64-bit
x86_64) 30 napig használható változatát a tesztelésre.

> A HP által javasolt PCI Storage kártya:
>
> Smart Array P222 Controller
> HP Smart Array P222/512 FBWC 6Gb 1-port Int/1-port Ext SAS Controller
> NOTE: HP Smart Array P222/512 FBWC qualified for RAID support only for HP ProLiant
> MicroServer Gen8.
> HP PN: 631667-B21

Az Ön által megjelölt kártya számomra nem megfelelő, mivel 2db külső
eSATA porttal rendelkező kártyát szeretnék használni a MicroServerben.

Üdvözlettel:

Update 2014.05.29. 11:00:
Tegnap telefonon kértem, hogy a lezárt hibajegyet vegyék elő, mert a problémám fenn áll annak ellenére, hogy az általuk támogatott Red Hat Enterprise Linux 6.5 verzióját is kipróbáltam.

============= Innentől a post a 2. problémakört boncolta, így már tárgytalan, csak az utókor számára meghagytam =============

Preambulum:
A gépben van 2 db SSD és 2 HDD. A HDD-k a hard drive bays-ben, az egyik SSD a belső USB csatlakozón, a másik SSD az ODD helyén.
Vizuális típusoknak néhány kép.

Nem tudom, hogy befolyásolja-e dolgokat, hogy a SATA vezérlők nem AHCI, hanem Legacy módban vannak, mert csak így bootol az ODD helyére tett SSD-ről, különben csak a hard drive bays-ben lévő eszközökről hajlandó bootolni vagy USB-ről. Köszönöm HP!

A telepített rendszer:

root@silent:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.5 (wheezy)
Release:        7.5
Codename:       wheezy
root@silent:~# uname -a
Linux silent 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3+deb7u1 x86_64 GNU/Linux

Az eszközök:

/dev/sda: WDC WD30EFRX-68AX9N0
/dev/sdb: WDC WD30EFRX-68EUZN0
/dev/sdc: SamsungSSD840EVO120GB
/dev/sdd: TOSHIBA THNS128GG4BAAA-NonFDE

A partíciók:

Model: ATA WDC WD30EFRX-68A (scsi)
Disk /dev/sda: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  1026MB  1024MB               primary
 2      1026MB  2050MB  1024MB               primary
 3      2051MB  53.3GB  51.2GB               primary
 4      53.3GB  3001GB  2947GB               primary


Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  1026MB  1024MB               primary
 2      1026MB  2050MB  1024MB               primary
 3      2051MB  53.3GB  51.2GB               primary
 4      53.3GB  3001GB  2947GB               primary


Model: ATA Samsung SSD 840 (scsi)
Disk /dev/sdc: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  40.9MB  39.8MB               primary  bios_grub
 2      40.9MB  241MB   200MB   ext4         primary
 3      241MB   120GB   120GB                primary


Model: Disk Name (scsi)
Disk /dev/sdd: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  39.8MB  38.8MB               primary  bios_grub
 2      40.9MB  241MB   200MB   ext4         primary
 3      241MB   120GB   120GB                primary

Grub a /dev/sdc és /dev/sdd MBR-jébe telepítve.

A /etc/fstab:

root@silent:~# cat /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/md1 during installation
UUID=741b9fc1-d656-48f6-853a-c104b330d7fe /               ext4    noatime,discard,errors=remount-ro 0       1
# /boot was on /dev/md0 during installation
UUID=b9469bd5-c87d-4254-885c-67a4c6899eee /boot           ext4    defaults,noatime,discard,noexec,nosuid,nodev        0       2
# /home was on /dev/md5 during installation
UUID=7bdc68bc-27a0-4a4c-9fce-e65af776b2b3 /home           ext4    defaults,nosuid,nodev       0       2
# /tmp was on /dev/md2 during installation
UUID=e9fc6f70-dbf3-4be3-abb3-92756e5e6efe /tmp            ext4    defaults,noexec,nosuid,nodev        0       2
# /var was on /dev/md3 during installation
UUID=253d1175-9fb1-45d9-80be-15d299f285dc /var            ext4    defaults,nodev        0       2
# /var/mail was on /dev/md4 during installation
UUID=6348e472-47e1-460a-925b-f41ad28f24d8 /var/mail       ext4    defaults,nodev        0       2

A blkid kimenet:

/dev/sdb1: UUID="a8df0a96-cb66-018a-e34d-693d2bceb7dc" UUID_SUB="f7dd11af-8af9-2dfe-8e59-2b0a1260a1a4" LABEL="silent:2" TYPE="linux_raid_member" 
/dev/sdb2: UUID="20d1b494-87dc-df6b-a937-0de2e62dc730" UUID_SUB="4cc6cad4-d437-5ae6-eb09-de2e29449a87" LABEL="silent:3" TYPE="linux_raid_member" 
/dev/sdb3: UUID="87e48551-1d3b-740c-4609-ff00ef4ea2be" UUID_SUB="c7964aa9-4d29-5235-2284-7a9a27042c09" LABEL="silent:4" TYPE="linux_raid_member" 
/dev/sdb4: UUID="f02c2734-559e-5573-632a-c098226ceebc" UUID_SUB="56466bf0-6025-39b2-4a52-5426940a5063" LABEL="silent:5" TYPE="linux_raid_member" 
/dev/sdd2: UUID="5002f812-6dc2-fc45-8036-c0e3643d7bd0" UUID_SUB="83dbdae5-7a10-2907-285a-a3cd61d9f15d" LABEL="silent:0" TYPE="linux_raid_member" 
/dev/sdd3: UUID="cd7d9342-437c-6a74-ad73-8885a5cb3ec8" UUID_SUB="7fedbddc-f7ca-2c74-e8d9-d7118bd8deba" LABEL="silent:1" TYPE="linux_raid_member" 
/dev/sda1: UUID="a8df0a96-cb66-018a-e34d-693d2bceb7dc" UUID_SUB="23d84c5d-99c6-a0bf-8931-c60b386c2792" LABEL="silent:2" TYPE="linux_raid_member" 
/dev/sda2: UUID="20d1b494-87dc-df6b-a937-0de2e62dc730" UUID_SUB="9fbdceb6-0f7e-5429-bc0a-cfa651273389" LABEL="silent:3" TYPE="linux_raid_member" 
/dev/sda3: UUID="87e48551-1d3b-740c-4609-ff00ef4ea2be" UUID_SUB="4deaefcc-d59e-e204-9958-2ad7887779ca" LABEL="silent:4" TYPE="linux_raid_member" 
/dev/sda4: UUID="f02c2734-559e-5573-632a-c098226ceebc" UUID_SUB="15fc6654-d5c7-3dda-65e9-4b13ec71e266" LABEL="silent:5" TYPE="linux_raid_member" 
/dev/sdc2: UUID="5002f812-6dc2-fc45-8036-c0e3643d7bd0" UUID_SUB="91900955-8186-38b3-aaf3-55a278e698ee" LABEL="silent:0" TYPE="linux_raid_member" 
/dev/sdc3: UUID="cd7d9342-437c-6a74-ad73-8885a5cb3ec8" UUID_SUB="9d07c2f5-4c00-a410-3e32-d74d7092dd17" LABEL="silent:1" TYPE="linux_raid_member" 
/dev/md2: LABEL="tmp" UUID="e9fc6f70-dbf3-4be3-abb3-92756e5e6efe" TYPE="ext4" 
/dev/md3: LABEL="var" UUID="253d1175-9fb1-45d9-80be-15d299f285dc" TYPE="ext4" 
/dev/md4: LABEL="mail" UUID="6348e472-47e1-460a-925b-f41ad28f24d8" TYPE="ext4" 
/dev/md5: LABEL="home" UUID="7bdc68bc-27a0-4a4c-9fce-e65af776b2b3" TYPE="ext4" 
/dev/md0: LABEL="boot" UUID="b9469bd5-c87d-4254-885c-67a4c6899eee" TYPE="ext4" 
/dev/md1: LABEL="root" UUID="741b9fc1-d656-48f6-853a-c104b330d7fe" TYPE="ext4" 

A /proc/mdstat tartalma:

Personalities : [raid1] 
md1 : active raid1 sdd3[2] sdc3[0]
      116886400 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sdd2[2] sdc2[0]
      195392 blocks super 1.2 [2/2] [UU]
      
md5 : active raid1 sda4[0] sdb4[1]
      2878131008 blocks super 1.2 [2/2] [UU]
      
md4 : active raid1 sda3[0] sdb3[1]
      49966976 blocks super 1.2 [2/2] [UU]
      
md3 : active raid1 sda2[0] sdb2[1]
      999872 blocks super 1.2 [2/2] [UU]
      
md2 : active raid1 sda1[0] sdb1[1]
      999872 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

A /etc/mdadm/mdadm.conf tartalma:

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/2 metadata=1.2 UUID=a8df0a96:cb66018a:e34d693d:2bceb7dc name=silent:2
ARRAY /dev/md/3 metadata=1.2 UUID=20d1b494:87dcdf6b:a9370de2:e62dc730 name=silent:3
ARRAY /dev/md/4 metadata=1.2 UUID=87e48551:1d3b740c:4609ff00:ef4ea2be name=silent:4
ARRAY /dev/md/5 metadata=1.2 UUID=f02c2734:559e5573:632ac098:226ceebc name=silent:5
ARRAY /dev/md/0 metadata=1.2 UUID=5002f812:6dc2fc45:8036c0e3:643d7bd0 name=silent:0
ARRAY /dev/md/1 metadata=1.2 UUID=cd7d9342:437c6a74:ad738885:a5cb3ec8 name=silent:1

# This file was auto-generated on Sun, 11 May 2014 23:24:41 +0200
# by mkconf 3.2.5-5

Ha lefuttatom az update-initramfs parancsot, akkor a következő boot-nál az alábbi képernyő fogad.

Ezután egy debian live usb-ről bootolva chrootban az initramfs frissítést követően be tud bootolni és mindaddig jó, amíg nem generálnék új initrd.img-t.
Ha a chrootban generált initrd.img-3.2.0-4-amd64-t visszamásolom a bootba, akkor megint megjavul, nem kell chroot-tal játszanom.

A chroot-ban és a tényleges rendszerben az alábbiakat vetettem össze:

• cat /proc/mdstat
• /usr/share/mdadm/mkconf
• blkid

Egyetlen eltérés a blkid kimenetében volt,azon raid tömb elemeinek particíójának UUID_SUB elemeiben, melyek a / és a /boot alá lennének felcsatolva. Viszont szerintem ezt a rendszer nem használja, csak a UUID-okat.

blkid chroot alatt:

/dev/sdb1: UUID="a8df0a96-cb66-018a-e34d-693d2bceb7dc" UUID_SUB="f7dd11af-8af9-2dfe-8e59-2b0a1260a1a4" LABEL="silent:2" TYPE="linux_raid_member"
/dev/sdb2: UUID="20d1b494-87dc-df6b-a937-0de2e62dc730" UUID_SUB="4cc6cad4-d437-5ae6-eb09-de2e29449a87" LABEL="silent:3" TYPE="linux_raid_member"
/dev/sdb3: UUID="87e48551-1d3b-740c-4609-ff00ef4ea2be" UUID_SUB="c7964aa9-4d29-5235-2284-7a9a27042c09" LABEL="silent:4" TYPE="linux_raid_member"
/dev/sdb4: UUID="f02c2734-559e-5573-632a-c098226ceebc" UUID_SUB="56466bf0-6025-39b2-4a52-5426940a5063" LABEL="silent:5" TYPE="linux_raid_member"
/dev/sdd2: UUID="5002f812-6dc2-fc45-8036-c0e3643d7bd0" UUID_SUB="1247c4e0-95d5-3067-c50c-a5eb8db24c03" LABEL="silent:0" TYPE="linux_raid_member"
/dev/sdd3: UUID="cd7d9342-437c-6a74-ad73-8885a5cb3ec8" UUID_SUB="8155cab9-4162-8809-fb87-f969ddd878f2" LABEL="silent:1" TYPE="linux_raid_member"
/dev/sda1: UUID="a8df0a96-cb66-018a-e34d-693d2bceb7dc" UUID_SUB="23d84c5d-99c6-a0bf-8931-c60b386c2792" LABEL="silent:2" TYPE="linux_raid_member"
/dev/sda2: UUID="20d1b494-87dc-df6b-a937-0de2e62dc730" UUID_SUB="9fbdceb6-0f7e-5429-bc0a-cfa651273389" LABEL="silent:3" TYPE="linux_raid_member"
/dev/sda3: UUID="87e48551-1d3b-740c-4609-ff00ef4ea2be" UUID_SUB="4deaefcc-d59e-e204-9958-2ad7887779ca" LABEL="silent:4" TYPE="linux_raid_member"
/dev/sda4: UUID="f02c2734-559e-5573-632a-c098226ceebc" UUID_SUB="15fc6654-d5c7-3dda-65e9-4b13ec71e266" LABEL="silent:5" TYPE="linux_raid_member"
/dev/sdc2: UUID="5002f812-6dc2-fc45-8036-c0e3643d7bd0" UUID_SUB="91900955-8186-38b3-aaf3-55a278e698ee" LABEL="silent:0" TYPE="linux_raid_member"
/dev/sdc3: UUID="cd7d9342-437c-6a74-ad73-8885a5cb3ec8" UUID_SUB="9d07c2f5-4c00-a410-3e32-d74d7092dd17" LABEL="silent:1" TYPE="linux_raid_member"
/dev/loop0: TYPE="squashfs"
/dev/md2: LABEL="tmp" UUID="e9fc6f70-dbf3-4be3-abb3-92756e5e6efe" TYPE="ext4"
/dev/md3: LABEL="var" UUID="253d1175-9fb1-45d9-80be-15d299f285dc" TYPE="ext4"
/dev/md4: LABEL="mail" UUID="6348e472-47e1-460a-925b-f41ad28f24d8" TYPE="ext4"
/dev/md5: LABEL="home" UUID="7bdc68bc-27a0-4a4c-9fce-e65af776b2b3" TYPE="ext4"
/dev/md0: LABEL="boot" UUID="b9469bd5-c87d-4254-885c-67a4c6899eee" TYPE="ext4"
/dev/md1: LABEL="root" UUID="741b9fc1-d656-48f6-853a-c104b330d7fe" TYPE="ext4"
/dev/sde1: LABEL="Debian wheezy 20140209-16:42" TYPE="iso9660"

cpio-val kibontva a két initrd image-t a configokban nincs különbség, viszont a lib/modules/3.2.0-4-amd64/kernel/drivers alatt jelentős:

A chroot-ban generált és működő initrd.img-ben:

acpi
ata
md
scsi
thermal

./acpi:
fan.ko
thermal.ko

./ata:
ata_generic.ko
ata_piix.ko
libata.ko

./md:
dm-mod.ko
linear.ko
md-mod.ko
multipath.ko
raid0.ko
raid10.ko
raid1.ko
raid456.ko

./scsi:
scsi_mod.ko
sd_mod.ko

./thermal:
thermal_sys.ko

A futó rendszerben generált és nem működő initrd.img-ben:

acpi
md
scsi
thermal
usb

./acpi:
fan.ko
thermal.ko

./md:
dm-mod.ko
linear.ko
md-mod.ko
multipath.ko
raid0.ko
raid10.ko
raid1.ko
raid456.ko

./scsi:
scsi_mod.ko
sd_mod.ko

./thermal:
thermal_sys.ko

./usb:
core
host
storage
usb-common.ko

./usb/core:
usbcore.ko

./usb/host:
ehci-hcd.ko

./usb/storage:
usb-storage.ko

Gondolom ez lehet a hiba oka, ha igen, akkor miért nem kerülnek bele az ata modulok a futó rendszerben generált initrd.img-be?
Mit rontottam el és hogyan tudom kijavítani?

Sziasztok.

egy RPI-t szeretnék automatikusan, monitor és klaviatúra nélkül is elinduló, előre beállított scriptet futtató kiber-rabszolgává alakítani.

A jelenlegi akadály az, hogy elfelejtettem, hogyan kell a felesleges dolgokat eltávolítani, pláne debian alapon.

Ezeket szeretném megszüntetni:

1. login. (azt szeretném, hogy a rendszer automatikusan induljon parancssorban, rootként. Amoolyan windows3.1-gyé alakításról van szó, ha csak ezt nézem)

2. Lehetőleg ne írjon a kártyára szinte semmit, hogy ha áramkimaradás van, semmi se legyen a fájlrendszeren félbehagyottan. (No ezt végképp nem tudom hogyan tegyem, mert a rosszbian nem tudom, mikor mit ír és hova.)

Sziasztok,

adott egy gép, melyen Debian-nak kell lennie, de Wheezy már nem elég backportokkal sem, így Jessie-re frissült, gdm3 és lightdm a lehetséges display managerek, mivel alapvetően gtk környezet van.

MATE a munkakörnyezet, de leállításra csak kijelentkezést ad és sem a gdm3 sem a lightdm-ben nem jelenik meg az a lehetőség, hogy leállítsam.

Persze sok minden más már, úgy fest, systemd-journal rtkit meg ilyen csoportokat látok, ps -A is utalgat ilyesmire.

lightdm logban shutdown után látok Failed durig authentication-t

Szóval ki lát hasonló helyzetet, miket nézzek, hol adjak jogot az alapértelmezett felhasználónak a leállításra?