Диагностика дебиана по фотографии
http://fas-tm.livejournal.com/29287.html
1) Скачал образ дебиана для raspberry pi: http://johnrhodes.co.uk/RPi/images/debian/6/debian6-19-04-2012/debian6-19-04-2012.zip
Внутри файл img - образ sd карты.
2) узнал у айседа, как узнать где живут разделы в этом образе: file debian6-19-04-2012.img
debian6-19-04-2012.img: x86 boot sector;
partition 1: ID=0xc, starthead 0, startsector 2048, 153600 sectors;
partition 2: ID=0x83, starthead 3, startsector 157696, 3256320 sectors;
partition 3: ID=0x82, starthead 3, startsector 3416064, 391168 sectors, code offset 0xb8
3) losetup -f -o 80740352 debian6-19-04-2012.img
4) mount /dev/loop0 /mnt/rpi
5) нашел файло с данными пакетов /mnt/rpi/var/lib/apt/lists/ftp.uk.debian.org_debian_dists_squeeze_main_binary-armel_Packages
В нем версия libcurl3-gnutls старая, в репе такой версии уже нет, а apt-get update почему-то не отработал (возможно, из-за дубликата main в /etc/apt/sources.list?)
Соответственно, зависимость для git-core находится старой версии, apt пытается ее качать и получает 404.
1) Скачал образ дебиана для raspberry pi: http://johnrhodes.co.uk/RPi/images/debian/6/debian6-19-04-2012/debian6-19-04-2012.zip
Внутри файл img - образ sd карты.
2) узнал у айседа, как узнать где живут разделы в этом образе: file debian6-19-04-2012.img
debian6-19-04-2012.img: x86 boot sector;
partition 1: ID=0xc, starthead 0, startsector 2048, 153600 sectors;
partition 2: ID=0x83, starthead 3, startsector 157696, 3256320 sectors;
partition 3: ID=0x82, starthead 3, startsector 3416064, 391168 sectors, code offset 0xb8
3) losetup -f -o 80740352 debian6-19-04-2012.img
4) mount /dev/loop0 /mnt/rpi
5) нашел файло с данными пакетов /mnt/rpi/var/lib/apt/lists/ftp.uk.debian.org_debian_dists_squeeze_main_binary-armel_Packages
В нем версия libcurl3-gnutls старая, в репе такой версии уже нет, а apt-get update почему-то не отработал (возможно, из-за дубликата main в /etc/apt/sources.list?)
Соответственно, зависимость для git-core находится старой версии, apt пытается ее качать и получает 404.
no subject
и не нужно всяких losetup -o
no subject
no subject
no subject
no subject
Если поддержка loop block device вкомпилена в ядро, нужно передавать через kernel command line: loop.max_part=63 loop.max_loop=8.
no subject
no subject
хотя, при правильном-стороннем ядре точно заведется.
no subject
И, это, все почему-то так и живут с parted/fdisk + losetup -o. Я имею в виду билдеры live-дисков различные.
no subject
no subject
no subject
# mount /dev/mapper/loop0p2 /mnt
Как-то так.
no subject
no subject
no subject
kpartx - для большинства случаев.
И для запущенных случаев - losetup -o (как например для угрёбищного grub2 местами, в частях grub-probe).
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
читать умею. возможно опыт не такой большой с дебианом.
no subject
no subject
создаём 1-2GB образ диска, размечаем в gparted, потом подключаем через losetup. Первое подключение - ок, разделы появились, повторные подключения - хер. До перезагрузки виртуалки не детектится. Выгрузка и загрузка назад loop тоже не помогала.
Для нужд сборочной песочницы - пришлось исключить из рассмотрения, обматерив много и злобно, т.к. на стороне заказчика сборка шла исключительно в виртуалке и времени на определение проблем ушло очень дохолеры.
no subject
no subject
Расследование привело в утилиту grub-probe, глянул как оно работает - и шумно проблевался в кустах.
Не зря мне raorn советовал выкинуть grub2 напрочь,
no subject
no subject
no subject
В виртуалке работает сборочная среда. Результат работы которой - загрузочный образ USB-флешки.
no subject
no subject
С extlinux таких проблем, разумеется, нет.