|
ru.unix.bsd- RU.UNIX.BSD ------------------------------------------------------------------ From : Valentin Nechayev 2:5020/400 14 Sep 2005 11:57:28 To : Vadim Goncharov Subject : Re: 6.0 -------------------------------------------------------------------------------- >>> Vadim Goncharov wrote: VN>> Я не во всех случаях вычислил, откуда они берутся, но факт: на ряде VN>> материнок (надеюсь, что они уже на свалке) этот метод помогал VN>> построить загружаемую установку в 99% случаев, а без него - VN>> достаточно часто не грузились. Особенно если был dedicated вариант. VN>> В качестве хохмы упомяну, что на одной из материнок загрузка прошла VN>> только когда в слайс 1 был поставлен MS-DOS. Хотя загрузочным был VN>> 2-й, с фрёй. До этого все пляски с геометрией не помогали. VG> Это случайно не отсюда растут ноги у фразы в хэндбуке "если не помогает, VG> установите на соседний раздел MS-DOS, после чего геометрия определится VG> кореткно" ? Да, отсюда. Дело в том что некоторые BIOS'ы времён 430TX, 430VX и прочих первых пней (у более поздних не замечал) для определения геометрии хотели FAT'овый раздел, и читали геометрию из его BPB. Без фатового раздела они начинали писать всякую дрянь. Добавить к этому что EDD у них был кривой или вообще вырублен - получалась лажа в кубе. VN>> корне невредно иметь занятость ниже 50%. VG> Зачем так много? Запас при таких объёмах карман не тянет;), а иногда полезно разместить рядом альтернативное дерево. Впрочем, это уже мой стиль извращений. VN>> /tmp вычищается при загрузке. Для /var/tmp согласно канонам это VN>> недопустимо (он должен чиститься только по времени). VG> И насколько часто это происходит в реальной жизни? А позволять кривым VG> прогам переполнять /var - тоже нехорошо. Впрочем, есть простой выход: VG> mkdir -p /var/tmp/tmp VG> chflags sunlnk /var/tmp/tmp VG> ln -s /var/tmp/tmp /tmp Ой, что-то заковыристо. А от переполнения /tmp сильно лучше не станет. Лучше не допускать никакого переполнения. -netch- --- ifmail v.2.15dev5.3 * Origin: Dark side of coredump (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix.bsd/2238392ff2846.html, оценка из 5, голосов 10
|