roboforum.ru

Palachzzz писал(а):start-stop-daemon: open pidfile /var/run/rsyslogd.pid: Input/output error (Input/output error)
failed!
start-stop-daemon: open pidfile /var/run/crond.pid: Input/output error (Input/output error)
failed![/color]
Раньше такого не было, изменилось только тип ФС (с ext3 на ext2) и флаг p в tar jcf ../lenny.tar.bz2 *

Очень похоже, что железка была выключена без shutdown, потому и ошибки на файловой системе. ext3 имеет журнал, ввиду чего после не корректного завершении работы (просто выключение питания или резет), журнал откатывается на последнее стабильное состояние и все. А вот с ext2 требуется проверка файловой системы и т.д., а для это нужно иметь fsck.ext2 и правильные инитскрипты, что бы произвести проверку и исправление.

Тут надо либо использовать ext3, либо разбивать флешку на пару разделов, в одном хранить не изменяющийся в процессе работы root dir / и монтировать его RO, а второй раздел использовать под /home, /var и в режиме RW.

День добрый, подскажите, использование SD продляет жизнь nand флэшке, кроме того места там явно побольше, а как это сказывается на скорости работы системы? Какие либо визуальные отличия наблюдаются, подтормаживает?

Попробовал поднять Debian на стандартном ядре uImage_X35, SD форматирована в два раздела, на первом разделе ядро на втором корнень.
uboot'у говорю следующее

Код: Выделить всё • Развернуть

MINI2440 # setenv bootargs console=ttySAC0,115200 mini2440=1tbc rootfstype=ext2 root=/dev/mmcblk0p2 rw rootwait=4 init=/bin/sh
MINI2440 # saveenv
Saving Environment to NAND...
Erasing Nand...
MINI2440 # setenv bootcmd mmcinit \; ext2load mmc 0:1 0x31000000 uImage_X35 \; bootm 0x31000000
MINI2440 # saveenv
Saving Environment to NAND...
Erasing Nand...
MINI2440 # boot

получаю пингвинов в панике...

Код: Выделить всё • Развернуть

mmc0: new SD card at address 1234
usb 1-1.1: New USB device found, idVendor=0ac8, idProduct=3450
usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.1: Product: Vimicro USB Camera (Altair)
usb 1-1.1: Manufacturer: Vimicro
ALSA device list:
  #0: S3C24XX_UDA134X (UDA134X)
TCP cubic registered
NET: Registered protocol family 17
mmcblk0: mmc0:1234 SA02G 1.81 GiB
 mmcblk0:
s3c2410-rtc s3c2410-rtc: setting system clock to 2155-10-31 04:26:01 UTC (1569275865)
 p1 p2
VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
Please append a correct "root=" boot option; here are the available partitions:
1f00             256 mtdblock0 (driver?)
1f01             128 mtdblock1 (driver?)
1f02            5120 mtdblock2 (driver?)
1f03          256640 mtdblock3 (driver?)
1f04          262144 mtdblock4 (driver?)
b300         1902592 mmcblk0 driver: mmcblk
  b301            9000 mmcblk0p1
  b302         1892784 mmcblk0p2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)

Я правильно понимаю, что это может быть из за того что в стандартном ядре может не быть поддержки ext2 и вылечить можно самому нормально собрав ядро, или тут какие другие грабли?

upd.
Сегодня скомпилил ядро с поддержкой ext2 все заработало. =)

Добрался и я до "собственного" линуха. Получилось не с первого раза, то состав пакетов не устраивал, то битые попадались, то места на SD не хватало. В итоге, локально накопилось порядка гигабайта DEB-ов от armel-debian-a. Живу в деревне, инет только через сотовый. Короче, перед началом экспериментов, ставьте apt-cacher. Он позволит при сборке с помощью debootstrap-а использовать ранее скаченные пакеты. В итоге, экономятся не только деньги, но и время.

cache efficiency
Cache hits Cache misses Total
Requests 445 (96.73%) 15 (3.26%) 460
Transfers 200.606 MB (91.24%) 19.251 MB (8.75%) 219.857 MB


А потом,чтобы использовать локальный кэш, достаточно поменять источник пакетов на локальный:


debootstrap --verbose --arch=armel --foreign --include=mc,ssh,vim,apt,udev,make,bluez,iw,bash,gpsd,bluetooth,wireless-tools,gnunet-tools,gnu-fdisk,util-linux,minicom stable debroot/ http://localhost:3142/debian/