Devicemap file ошибка

Что и почему получилось — вполне понятно, ссылки выше уже давал.
Главная ошибка — необходимо было предварительно преобразовать динамический (Dynamic) диск в базовый (Basic) в терминологии Windows.

Без этого у вас получилось примерно следующее.
1) В MBR была запись о единственном первичном (primary) разделе с типом 0x42 и размером на весь диск; в последнем МБ этого раздела лежала реальная LDM-таблица разделов этого диска;

2) После

Acronis Disk Director и с помощью него отрезал 400 с лишним ГБ от дисков C и D.

возникает вопрос, действительно ли он умеет работать с LDM и что получилось при отрезании:
а) умеет, изменены (1) размеры ФС «дисков» C: и D:, (2) границы разделов внутри LDM, (3) границы внешнего контейнера в MBR;
б) не умеет, изменены размеры только внешнего контейнера.
Почему-то кажется, что у варианта (б) больше шансов :(, ведь динамический диск не может содержать дополнительных разделов внутри MBR и/или GPT… Но это мои домыслы, тут нужно исследовать вопрос по версии ADD, его документации, а при тишине в ней на эту тему — путем натурного эксперимента.

3) После создания разделов и установки Linux то, что получилось, могло выглядеть как-то так:

Было: (сверху данные MBR, снизу — LDM)
v----------------- раздел 4 тип 0x42 ---------------v
=====================================================
^-- диск C: тип 7 --^ ^---- диск D: тип 7 ----^ ^LDM^
Стало (если была поддержка):
v~~~ расш. sda1 ~~~v 
v  sda 5, 6, 7, 8  v v----- раздел 4 тип 0x42 ------v
=====================================================
                     ^-диск C:-^ ^--диск D:---^ ^LDM^
Стало (если не было поддержки):





  



                       
  





v--- расш. sda1 ---v 
v  sda 5, 6, 7, 8  v v----- раздел 4 тип 0x42 ------v
=====================================================
^-- диск C: тип 7 --^ ^---- диск D: тип 7 ----^ ^LDM^

На картинке оптимистичный вариант, когда «диск D:» не был затерт, но это не гарантировано.

Вон там: http://www.glazavezde.ru/nastroyka-programm-v-korporativnyh-setyah/tonkosti-n… пишут, что ADD 11 знает про динамические диски.

4) Если не было ценных данных, или есть их резервная копия, переразметьте и переставьте обе системы.
Если были — самое время озаботиться вопросом, 1) целы ли они и 2) куда переписать то, что еще не убито.

5) Если поддержка все же была, преобразование в Basic диск в том же ADD должно помочь, если он сможет оставить и MBR, и LDM разделы в MBR варианте.

bormant ★★★★★
()



Последнее исправление: bormant
(всего

исправлений: 3)

  • Показать ответ
  • Ссылка
Источник
  • Index
  • » Newbie Corner
  • » [SOLVED] Grub-customizer doesn’t start and can’t edit grub menu

Pages: 1

#1 2018-11-30 16:12:32

gunjah292
Member
From: Hamburg
Registered: 2011-05-05
Posts: 186

[SOLVED] Grub-customizer doesn’t start and can’t edit grub menu

It is not really a problem, but I want to get rid of it. I did some customizing of the menu with grub-customizer some time ago. I now uninstalled all of the additional kernels and want a standard grub. Unfortunately I can’t edit grub via grub customizer anymore, because it doesn’t start. I get the following error.

https://i.ibb.co/98C65M6/Auswahl-046.png

I found the DEVICEMAP_FILE but coudln’t find the MKDEVICEMAP_CMD, so I tried to update grub manually. I deleted all the unused config files from /etc/grub.d and hit grub-mkconfig, but the menu entries don’t change. It even shows menu entries from kernels and operating systems that don’t exist on the harddrive anymore.

I am really at my wit’s end here.

Mod note: Replaced oversized images — V1del

Last edited by V1del (2018-11-30 16:33:01)

KDE Plasma, ThinkPad X380 Yoga, Intel Core i7-8550U, Intel UHD Graphics 620, 512GB PCIe-NVMe SSD (OPAL 2.0), 16GB PC4-19200 (2400 MHz)

#2 2018-11-30 16:14:53

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: [SOLVED] Grub-customizer doesn’t start and can’t edit grub menu

Yeah, that’s useless without English. https://wiki.archlinux.org/index.php/Co … s_and_code

Also useless without a clarification of what you mean by «and hit grub-mkconfig». Do you mean you took a hammer to the sector of the hard drive on which the file named grub-mkconfig is stored? Do you mean you ran a command that included, but was not exclusive to, «grub-mkconfig», but which you have failed to elaborate upon? If so, did you *also* neglect to provide the output?

Last edited by eschwartz (2018-11-30 16:16:59)

Managing AUR repos The Right Way — aurpublish (now a standalone tool)

#3 2018-11-30 16:19:45

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 19,757

Re: [SOLVED] Grub-customizer doesn’t start and can’t edit grub menu

Please post only thumbnails or links to images. https://wiki.archlinux.org/index.php/Co … s_and_code

These kinds of issues usually happen if your GRUB isn’t the one being controlled by Arch, reinstall GRUB from within Arch and make sure that your paths aren’t mixed up, is /boot a separate partition? FWIW it looks like you have an EFI partition at /dev/sda2 but are trying to fumble with a (BIOS?) installed GRUB on /dev/sda5 ? Which is it that you are booting from your UEFI what’s your output for 

lsblk -f
sudo efibootmgr -v
tree /boot #Requires the tree package

Last edited by V1del (2018-11-30 16:20:50)

#4 2018-11-30 16:31:41

gunjah292
Member
From: Hamburg
Registered: 2011-05-05
Posts: 186

Re: [SOLVED] Grub-customizer doesn’t start and can’t edit grub menu

Sorry for the German picture. I now solved the issue by deleting the whole content of /etc/grub.d/ and reinstalling grub.

KDE Plasma, ThinkPad X380 Yoga, Intel Core i7-8550U, Intel UHD Graphics 620, 512GB PCIe-NVMe SSD (OPAL 2.0), 16GB PC4-19200 (2400 MHz)

Источник

Are you trying to install GRUB with grub-install /dev/sda1?

Since GRUB practically requires access to MBR and the unused space between the MBR and the first partition when installing for BIOS-style boot process, try grub-install /dev/sda. If it still displays the same error message, just write your own /boot/grub/device.map file. In your case, its contents could be just

(hd0)    /dev/sda

(Ideally, you would use an appropriate /dev/disk/by-id/... pathname in place of /dev/sda, but that’s not mandatory.)

grub-install /dev/sda1 would attempt to embed GRUB’s boot block into PBR of partition sda1 instead of the MBR. Since most filesystems won’t have a fixed space for bootloader, GRUB’s boot block would have to point at /boot/grub/i386-pc/core.img by physical disk location, which used to be a very seriously discouraged installation mode. Modern versions of GRUB might no longer support installing GRUB that way at all.

The problem is, the boot block code needs to be so small it won’t understand filesystems, so it reads the GRUB image using raw disk block numbers determined at GRUB installation time. For this to work, the GRUB core image needs to be placed somewhere where its physical location on disk is guaranteed to stay the same. From the OS viewpoint, /boot/grub/i386-pc/core.img is a regular file, so a defragmentation tool or a smart filesystem driver might occasionally move it to a different physical location on-disk: that would cause a total boot failure.

When GRUB is installed to the actual Master Boot Record of a MBR-partitioned disk, the empty space between the MBR and the beginning of the first partition (almost 1 MB) is used for the GRUB core image. Since this place is outside any partitions, no filesystem driver or defragmenting tool is going to touch it. This is enough space to embed the GRUB core image, a filesystem driver and any other GRUB modules needed to access /boot as a real filesystem. After loading these, GRUB will then be able to load additional modules (including normal.mod) and its configuration file as regular files, by pathname.

Incidentally, if you wanted to boot the i386-pc version of GRUB from a GPT-partitioned disk, you would need a «biosboot» partition that is sized 1 MB and contains no filesystem: it is used to hold the GRUB core image, as the MBR-style space before the first partition will now be occupied by GPT partition table structures instead.

The empty space between the MBR and the beginning of the first partition is a historical remnant: back when disks still used C/H/S addressing, there was a convention to place the beginning of a partition always to the first sector of a track. Since MBR was the very first block of the disk (C/H/S address 0/0/1), that meant the earliest possible start of first partition would be C/H/S 0/1/1, and the rest of track #0 (= cylinder #0, head #0) would be left unused.

Roughly in the Windows XP era, as C/H/S addressing was no longer meaningful and data alignment on RAID arrays, enterprise storage systems and SSDs was becoming an important performance issue, the start-of-first-partition convention was changed: now the recommended place to start the first partition of the disk was at exactly 1 MiB from the beginning of the disk, or at the LBA block number #2048 (assuming classic 512-byte disk blocks).

Источник

Что и почему получилось — вполне понятно, ссылки выше уже давал.
Главная ошибка — необходимо было предварительно преобразовать динамический (Dynamic) диск в базовый (Basic) в терминологии Windows.

Без этого у вас получилось примерно следующее.
1) В MBR была запись о единственном первичном (primary) разделе с типом 0x42 и размером на весь диск; в последнем МБ этого раздела лежала реальная LDM-таблица разделов этого диска;

2) После

Acronis Disk Director и с помощью него отрезал 400 с лишним ГБ от дисков C и D.

возникает вопрос, действительно ли он умеет работать с LDM и что получилось при отрезании:
а) умеет, изменены (1) размеры ФС «дисков» C: и D:, (2) границы разделов внутри LDM, (3) границы внешнего контейнера в MBR;
б) не умеет, изменены размеры только внешнего контейнера.
Почему-то кажется, что у варианта (б) больше шансов :(, ведь динамический диск не может содержать дополнительных разделов внутри MBR и/или GPT… Но это мои домыслы, тут нужно исследовать вопрос по версии ADD, его документации, а при тишине в ней на эту тему — путем натурного эксперимента.

3) После создания разделов и установки Linux то, что получилось, могло выглядеть как-то так:

Было: (сверху данные MBR, снизу — LDM)
v----------------- раздел 4 тип 0x42 ---------------v
=====================================================
^-- диск C: тип 7 --^ ^---- диск D: тип 7 ----^ ^LDM^




Стало (если была поддержка):
v~~~ расш. sda1 ~~~v 
v  sda 5, 6, 7, 8  v v----- раздел 4 тип 0x42 ------v
=====================================================
                     ^-диск C:-^ ^--диск D:---^ ^LDM^
Стало (если не было поддержки):





  



                       
  





v--- расш. sda1 ---v 
v  sda 5, 6, 7, 8  v v----- раздел 4 тип 0x42 ------v
=====================================================
^-- диск C: тип 7 --^ ^---- диск D: тип 7 ----^ ^LDM^

На картинке оптимистичный вариант, когда «диск D:» не был затерт, но это не гарантировано.

Вон там: http://www.glazavezde.ru/nastroyka-programm-v-korporativnyh-setyah/tonkosti-n… пишут, что ADD 11 знает про динамические диски.

4) Если не было ценных данных, или есть их резервная копия, переразметьте и переставьте обе системы.
Если были — самое время озаботиться вопросом, 1) целы ли они и 2) куда переписать то, что еще не убито.

5) Если поддержка все же была, преобразование в Basic диск в том же ADD должно помочь, если он сможет оставить и MBR, и LDM разделы в MBR варианте.

bormant ★★★★★

(04.01.18 20:02:16 MSK)

Последнее исправление: bormant 04.01.18 20:07:35 MSK
(всего

исправлений: 3)

  • Показать ответ
  • Ссылка

Are you trying to install GRUB with grub-install /dev/sda1?

Since GRUB practically requires access to MBR and the unused space between the MBR and the first partition when installing for BIOS-style boot process, try grub-install /dev/sda. If it still displays the same error message, just write your own /boot/grub/device.map file. In your case, its contents could be just

(hd0)    /dev/sda

(Ideally, you would use an appropriate /dev/disk/by-id/... pathname in place of /dev/sda, but that’s not mandatory.)

grub-install /dev/sda1 would attempt to embed GRUB’s boot block into PBR of partition sda1 instead of the MBR. Since most filesystems won’t have a fixed space for bootloader, GRUB’s boot block would have to point at /boot/grub/i386-pc/core.img by physical disk location, which used to be a very seriously discouraged installation mode. Modern versions of GRUB might no longer support installing GRUB that way at all.

The problem is, the boot block code needs to be so small it won’t understand filesystems, so it reads the GRUB image using raw disk block numbers determined at GRUB installation time. For this to work, the GRUB core image needs to be placed somewhere where its physical location on disk is guaranteed to stay the same. From the OS viewpoint, /boot/grub/i386-pc/core.img is a regular file, so a defragmentation tool or a smart filesystem driver might occasionally move it to a different physical location on-disk: that would cause a total boot failure.

When GRUB is installed to the actual Master Boot Record of a MBR-partitioned disk, the empty space between the MBR and the beginning of the first partition (almost 1 MB) is used for the GRUB core image. Since this place is outside any partitions, no filesystem driver or defragmenting tool is going to touch it. This is enough space to embed the GRUB core image, a filesystem driver and any other GRUB modules needed to access /boot as a real filesystem. After loading these, GRUB will then be able to load additional modules (including normal.mod) and its configuration file as regular files, by pathname.

Incidentally, if you wanted to boot the i386-pc version of GRUB from a GPT-partitioned disk, you would need a «biosboot» partition that is sized 1 MB and contains no filesystem: it is used to hold the GRUB core image, as the MBR-style space before the first partition will now be occupied by GPT partition table structures instead.

The empty space between the MBR and the beginning of the first partition is a historical remnant: back when disks still used C/H/S addressing, there was a convention to place the beginning of a partition always to the first sector of a track. Since MBR was the very first block of the disk (C/H/S address 0/0/1), that meant the earliest possible start of first partition would be C/H/S 0/1/1, and the rest of track #0 (= cylinder #0, head #0) would be left unused.

Roughly in the Windows XP era, as C/H/S addressing was no longer meaningful and data alignment on RAID arrays, enterprise storage systems and SSDs was becoming an important performance issue, the start-of-first-partition convention was changed: now the recommended place to start the first partition of the disk was at exactly 1 MiB from the beginning of the disk, or at the LBA block number #2048 (assuming classic 512-byte disk blocks).

Стоят Windows и несколько Ubuntu-подобных ОС.
Слетел GRUB.
Откуда SFS взялась???Где ext2?

root@kali:~# sudo fdisk -l

Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xa244bd53

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1              63      2047      1985 992,5K 42 SFS
/dev/sda2  *         2048    718847    716800   350M 42 SFS
/dev/sda3          718848 213012479 212293632 101,2G 42 SFS
/dev/sda4       213012480 976771119 763758640 364,2G 42 SFS

Partition 2 does not start on physical sector boundary.

Disk /dev/sdb: 3,6 GiB, 3880452096 bytes, 7579008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3077d69f

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1  *    16128 7579007 7562880  3,6G  7 HPFS/NTFS/exFAT
/dev/sdb4       68576 1534943 1466368  716M  0 Empty

Disk /dev/sdc: 14,7 GiB, 15798894592 bytes, 30857216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3b0217b6

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdc1        2048 30855167 30853120 14,7G  c W95 FAT32 (LBA)

root@kali:~#

root@kali:~# grub-mkconfig -o /boot/grub/menu.cfg
Generating grub configuration file …
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Найден образ linux: /boot/vmlinuz-4.0.0-kali1-amd64
Найден образ initrd: /boot/initrd.img-4.0.0-kali1-amd64
  No volume groups found
grub-probe: ошибка: не удалось найти привод GRUB для /dev/sda15. Проверьте device.map.
grub-probe: ошибка: не удалось найти привод GRUB для /dev/sda5. Проверьте device.map.
grub-probe: ошибка: не удалось найти привод GRUB для /dev/sdb4. Проверьте device.map.
Найден Ubuntu 15.04 (15.04) на /dev/sda1
Найден Ubuntu 15.04 (15.04) на /dev/sda11
Найден Windows 7 (loader) на /dev/sda2
Найден Ubuntu 15.04 (15.04) на /dev/sda7
завершено

Сегодня я решил подцепить свой старый диск, чтобы на него отдельно попробовать поставить Arch.

Загрузчик я оставляю Убунтовский, GRUB2.

Подключил диск, установил вроде бы Arch, зашел в Ubuntu, делаю

update-grub

и вижу

grub-probe: error: Cannot find a GRUB drive for /dev/sdb1.  Check your device.map.

и еще несколько похожих ошибок, отличающихся только цифрами.

Гугл подсказал, что, после добавления нового диска, надо обновить файл /boot/grub/device.map. Делается это так:

sudo grub-mkdevicemap --no-floppy

или без --no-floppy если вы используете дисковод.

Источник

Сегодня я решил подцепить свой старый диск, чтобы на него отдельно попробовать поставить Arch.

Загрузчик я оставляю Убунтовский, GRUB2.

Подключил диск, установил вроде бы Arch, зашел в Ubuntu, делаю

update-grub

и вижу

grub-probe: error: Cannot find a GRUB drive for /dev/sdb1.  Check your device.map.

и еще несколько похожих ошибок, отличающихся только цифрами.

Гугл подсказал, что, после добавления нового диска, надо обновить файл /boot/grub/device.map. Делается это так:

sudo grub-mkdevicemap --no-floppy

или без --no-floppy если вы используете дисковод.

Источник

Понравилась статья? Поделить с друзьями:

Интересное по теме:

  • Df002 ошибка рено клио
  • Devicemanagement enterprise diagnostics provider ошибка 454
  • Df002 ошибка рено дастер
  • Device setup manager ошибка 152
  • Df002 ошибка ларгус

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии