После пересборки system и world и установки kdebase-meta 4.4, загрузка системы начала стопориться на Checking root filesystem, там идет разговор про суперблоки, и предлагают использовать альтернативные суперблоки... прилагается команда
ввести пароль root и выполнить предлагаемую команду. альтернативно - загрузиться любым не древним livecd или rescue cd/usb и выполнить e2fsck на нужный раздел диска
если не помогло, значит с файловой системой большие проблемы (или вообще проблемы с диском). соответственно, нужно выяснить в чем все-таки проблема и пытаться что-то сделать. но это уже совсем другая история
ubuntu@ubuntu:~$ sudo e2fsck -b 8193 /dev/sda9
e2fsck 1.41.3 (12-Oct-2008)
e2fsck: Bad magic number in super-block while trying to open /dev/sda9
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
В Arch Linux выводы такие же.
и ещё...в генту постоянно начало сбиваться время.
Нет это не батарейка, ибо в форточках и арче все нормально с временем, в fstab менял 1 на 0, загружается... но невозможно менять дату, ибо даже не запрашивает пароль рута... я думаю это пересборка мира, системы и установка кедов виновата..
проверял я и более новой e2fsck, в арче.Т.е. я выставляю время грубо говоря на полночь, но после ребута выдет 7 часов.
Собственно вот вывод (сделан в Арче):
sudo mke2fs -n /dev/sda9
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
1220608 inodes, 4877727 blocks
243886 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
149 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000
И как я понимаю вместо 8193 я должен указать (например) 32768?
из под арча провернуть хитрости с mke2fs удалось но из под генту не получается. Возможно придется в fstab ставить вместо 1 0.
Вот что выдает генту на команду mke2fs -n /dev/sda9
$ sudo mke2fs -n /dev/sda9
mke2fs 1.41.11 (14-Mar-2010)
Could not stat /dev/sda9 --- Нет такого файла или каталога
The device apparently does not exist; did you specify it correctly?
а может быть дело в partitions table?
попробуйте CONFIG_PARTITION_ADVANCED=y
вдруг поможет?
это предположение: я никогда не пользовался extended partitions, и соответственно не включал этого параметра (logical drives? не знаю даже как они точно называются)
а может быть дело в partitions table?
попробуйте CONFIG_PARTITION_ADVANCED=y
вдруг поможет?
это предположение: я никогда не пользовался extended partitions, и соответственно не включал этого параметра (logical drives? не знаю даже как они точно называются)
Собранное новое ядро вообще не пускает грузиться ссылаясь на то что проблемы с разделом или с самим primary разделом...Видимо придётся мне переустанавливать генту.
диагностику выложите. времени же жалко: ядро и вся инсталляция это конечно связанные вещи, но не настолько, чтобы из-за того, что не грузится нужно было все заново делать
не думаю, что можно что-нить поставить так, чтобы система не могла загрузиться. если поведение такое, как было написано в первом сообщении, то сообщение выдается почти сразу по завершении загрузки ядра - стартовыми скриптами baselayout
у меня нет такого опыта, может быть кто-нить из коллег тут ставил систему не в обычный раздел?
из под арча провернуть хитрости с mke2fs удалось но из под генту не получается. Возможно придется в fstab ставить вместо 1 0.
Вот что выдает генту на команду mke2fs -n /dev/sda9
$ sudo mke2fs -n /dev/sda9
mke2fs 1.41.11 (14-Mar-2010)
Could not stat /dev/sda9 --- Нет такого файла или каталога
The device apparently does not exist; did you specify it correctly?
e2fsck: Нет такого файла или каталога while trying to open /dev/sda9
/dev/sda9 действительно нет?
Может, нам стоит посмотреть на таблицу разделов по "fdisk -l" из Дженту?
Мне кажется, это может быть какой-то непорядок в /dev/ или с udev.
это то, что попадает в syslog (/var/log/messages) и временно хранится в лог-буфере ядра, который можно получить по команде dmesg. dmеsg есть во всех *nix, то, что пишется в syslog - зависит от реализации и/или конфигурации. лог-буфер ограничен по размеру (в linux - параметр ядра), соответственно там есть только последние <размер буфера>килобайт данных
в вашем случае - после диагностики о неконсистентной фс нужно ввести рутовый пароль и сказать dmesg|less. ну и поискать искомое
я не обратил внимания на первое сообщение: наверняка же обновился udev, появились новые правила, а вы не заметили советов emerge при этих больших сборках. соответственно нужных спецфайлов в /dev не создалось. с таким вот результатом
попробуйте из другого линукса, через chroot со всеми mount'ами и bind'ами, как написано в handbook'е зайти в вашу инсталляцию и выполнить dispatch-conf, если он покажет что-нить недоделанное, все может быстро решиться