Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Franco Martelli]

Hi Marc,

On 20/05/24 at 14:35, Marc SCHAEFER wrote:

3. grub BOOT FAILS IF ANY LV HAS dm-integrity, EVEN IF NOT LINKED TO /

if I reboot now, grub2 complains about rimage issues, clear the screen
and then I am at the grub2 prompt.

Booting is only possible with Debian rescue, disabling the dm-integrity
on the above volume and rebooting. Note that you still can see the
rimage/rmeta sub LVs (lvs -a), they are not deleted! (but no
dm-integrity is activated).

4. update-grub GIVES WARNINGS

Now, if I try to start update-grub while booted AND having enabled
dm-integrity on the vg1/docker volume, I get:

# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-21-amd64
Found initrd image: /boot/initrd.img-6.1.0-21-amd64
error: unknown node 'docker_rimage_0'.
[ ... many ... ]
/usr/sbin/grub-probe: error: disk
`lvmid/xLE0OV-wQy7-88H9-yKCz-4DUQ-Toce-h9rQvk/FzCf1C-95eB-7B0f-DSrF-t1pg-66qp-hmP3nZ'
  not found.
error: unknown node 'docker_rimage_0'.
[ ... many ... ]

[ this repeats a few times ]


Sorry for the late in the answer, but I've just noticed that the Linux 
kernel of Debian Bookworm ISO image (debian-12.0.0-amd64-DVD-1.iso) 
comes *without* "dm-integrity.ko" module, making therefore not possible 
to support volumes formatted with "--raidintegrity y" neither those 
formatted with "integritysetup" command (I think that it's a bug and it 
should be reported).


When you booted in rescue mode which ISO image have you used?

Thank for your patience, kind regards.
--
Franco Martelli

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Marc SCHAEFER]

Hello,

On Wed, May 22, 2024 at 05:03:34PM -0400, Stefan Monnier wrote:
> Hmm... I've been using a "plain old partition" for /boot (with
> everything else in LVM) for "ever", originally because the boot loader
> was not able to read LVM, and later out of habit.  I was thinking of
> finally moving /boot into an LV to make things simpler, but I see that
> it'd still be playing with fire

grub supports, for a long time:

   - / on LVM, with /boot within that filesystem
   - /boot on LVM, separately

(it also worked with LILO, because LILO would record the exact address
 where the kernel & initrd was, regardless of abstractions layers :->)

Recently, I have been playing with RAID-on-LVM (I was mostly using LVM
on md before, which worked with grub), and it works too.

Where grub fails, is if you have /boot on the same LVM volume group
where any of the LVs "before him in order" have:

   - dm-integrity
   - specific metadata

So yes, any advanced setup might break grub, and so the easiest is to
have /boot on its separate partition again for the time being.

Which makes two partitions of you also have an UEFI.

>  (AFAICT booting off of LVM was still not
> supported by U-Boot either last time I checked).  

No idea about that one, sorry.

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Stefan Monnier]

> I found this [1], quoting: "I'd also like to share an issue I've
> discovered: if /boot's partition is a LV, then there must not be a
> raidintegrity LV anywhere before that LV inside the same VG. Otherwise,
> update-grub will show an error (disk `lvmid/.../...' not found) and GRUB
> cannot boot. So it's best if you put /boot into its own VG. (PS: Errors
> like unknown node '..._rimage_0 can be ignored.)"

Hmm... I've been using a "plain old partition" for /boot (with
everything else in LVM) for "ever", originally because the boot loader
was not able to read LVM, and later out of habit.  I was thinking of
finally moving /boot into an LV to make things simpler, but I see that
it'd still be playing with fire (AFAICT booting off of LVM was still not
supported by U-Boot either last time I checked).  


Stefan

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Marc SCHAEFER]

Hello,

On Wed, May 22, 2024 at 10:13:06AM +, Andy Smith wrote:
> metadata tags to some PVs prevented grub from assembling them,

grub is indeed very fragile if you use dm-integrity anywhere on any of
your LVs on the same VG where /boot is (or at least if in the list
of LVs, the dm-integrity protected ones come first).

I guess it's a general problem how grub2 parses LVM, yes,
as soon as their are special things going on, it somehow breaks.

However, if you don't have /boot on LVM, hand-fixing grub2 can be
trivial, e.g. here on another system with /boot/efi on 1st disk's first
partition and /boot on 2nd disk's first partition.

   linux (hd1,1)vmlinuz-5.10.0-29-amd64 root=/dev/mapper/vg1-root ro quiet
   initrd (hd1,1)initrd.img-5.10.0-29-amd64
   boot

(you even have completions in grub's interactive boot system)

and it boots.  Next step: I am going to make me a USB boot key for that
system, in case (first using a simple mount of two partitions of the
USB key on /boot, respectively /boot/efi (vfat), then update-grub,
or if it breaks, completely by hand like above -- I have been using
syslinux for the last 20 years or so for that purpose, but it gets
apparently too complicated with Secure Boot and stuff).

PS: I have from now on decided I will always use a /boot no longer
on LVM but on a separate partition, like the /boot/efi, it
seems, indeed, much less fragile.  Aka, back to what I
was doing a few years ago before my confidence in grub2
got apparently too high :)

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Andy Smith]

Hello,

On Wed, May 22, 2024 at 08:57:38AM +0200, Marc SCHAEFER wrote:
> I will try this work-around and report back here.  As I said, I can
> live with /boot on RAID without dm-integrity, as long as the rest can be
> dm-integrity+raid protected.

I'm interested in how you get on.

I don't (yet) use dm-integrity, but I have seen extreme fragility in
grub with regard to LVM. For example, a colleague of mine recently
lost 5 hours of their life (and their SLA budget) when simply adding
metadata tags to some PVs prevented grub from assembling them,
resulting in a hard to debug failed boot at next boot.

Anything that involves grub having to interact with LVM just seems
really fragile.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Marc SCHAEFER]

Hello,

On Wed, May 22, 2024 at 08:57:38AM +0200, Marc SCHAEFER wrote:
> I will try this work-around and report back here.  As I said, I can
> live with /boot on RAID without dm-integrity, as long as the rest can be
> dm-integrity+raid protected.

So, enable dm-integrity on all LVs, including /, /var/lib/lxc, /scratch
and swap, now boots without any issue with grub2 as long as /boot is NOT
on the same VG where the dm-integrity over LVM RAID is enabled.

This is OK for me, I don't need /boot on dm-integrity.

update-grub gives out warning for every of the rimage subvolumes, but
can still then reboot.

I would guess the bug is thus in grub2, not yet supporting boot on a
/boot not necessarily dm-integrityfied itself, but on a VG where any
of the LV is.

Are readers seconding conclusion?  If yes, I could report a bug on grub2.

Have a nice day.

Details:
root@ds-03:~# lvs -a
  LV   VG  Attr   LSize   Pool Origin   
Data%  Meta%  Move Log Cpy%Sync Convert
  docker   vg1 rwi-aor--- 500.00g   
   100.00  
  [docker_rimage_0]vg1 gwi-aor--- 500.00g  [docker_rimage_0_iorig]  
   100.00  
  [docker_rimage_0_imeta]  vg1 ewi-ao  <4.07g   
   
  [docker_rimage_0_iorig]  vg1 -wi-ao 500.00g   
   
  [docker_rimage_1]vg1 gwi-aor--- 500.00g  [docker_rimage_1_iorig]  
   100.00  
  [docker_rimage_1_imeta]  vg1 ewi-ao  <4.07g   
   
  [docker_rimage_1_iorig]  vg1 -wi-ao 500.00g   
   
  [docker_rmeta_0] vg1 ewi-aor---   4.00m   
   
  [docker_rmeta_1] vg1 ewi-aor---   4.00m   
   
  root vg1 rwi-aor---  10.00g   
   100.00  
  [root_rimage_0]  vg1 gwi-aor---  10.00g  [root_rimage_0_iorig]
   100.00  
  [root_rimage_0_imeta]vg1 ewi-ao 148.00m   
   
  [root_rimage_0_iorig]vg1 -wi-ao  10.00g   
   
  [root_rimage_1]  vg1 gwi-aor---  10.00g  [root_rimage_1_iorig]
   100.00  
  [root_rimage_1_imeta]vg1 ewi-ao 148.00m   
   
  [root_rimage_1_iorig]vg1 -wi-ao  10.00g   
   
  [root_rmeta_0]   vg1 ewi-aor---   4.00m   
   
  [root_rmeta_1]   vg1 ewi-aor---   4.00m   
   
  scratch  vg1 rwi-aor---  10.00g   
   100.00  
  [scratch_rimage_0]   vg1 gwi-aor---  10.00g  [scratch_rimage_0_iorig] 
   100.00  
  [scratch_rimage_0_imeta] vg1 ewi-ao 148.00m   
   
  [scratch_rimage_0_iorig] vg1 -wi-ao  10.00g   
   
  [scratch_rimage_1]   vg1 gwi-aor---  10.00g  [scratch_rimage_1_iorig] 
   100.00  
  [scratch_rimage_1_imeta] vg1 ewi-ao 148.00m   
   
  [scratch_rimage_1_iorig] vg1 -wi-ao  10.00g   
   
  [scratch_rmeta_0]vg1 ewi-aor---   4.00m   
   
  [scratch_rmeta_1]vg1 ewi-aor---   4.00m   
   
  swap vg1 rwi-aor---   8.00g   
   100.00  
  [swap_rimage_0]  vg1 gwi-aor---   8.00g  [swap_rimage_0_iorig]
   100.00  
  [swap_rimage_0_imeta]vg1 ewi-ao 132.00m   
   
  [swap_rimage_0_iorig]vg1 -wi-ao   8.00g   
   
  [swap_rimage_1]  vg1 gwi-aor---   8.00g  [swap_rimage_1_iorig]
   100.00  
  [swap_rimage_1_imeta]vg1 ewi

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Marc SCHAEFER]

Additional info:

On Wed, May 22, 2024 at 08:49:56AM +0200, Marc SCHAEFER wrote:
> Having /boot on a LVM non enabled dm-integrity logical volume does not
> work either, as soon as there is ANY LVM dm-integrity enabled logical
> volume anywhere (even not linked to booting), grub2 complains (at boot
> time or at update-grub) about the rimage LV.

I found this [1], quoting: "I'd also like to share an issue I've
discovered: if /boot's partition is a LV, then there must not be a
raidintegrity LV anywhere before that LV inside the same VG. Otherwise,
update-grub will show an error (disk `lvmid/.../...' not found) and GRUB
cannot boot. So it's best if you put /boot into its own VG. (PS: Errors
like unknown node '..._rimage_0 can be ignored.)"

So, the work-around seems to be to simple have /boot not on a LVM VG where
any LV has dm-integrity enabled.

I will try this work-around and report back here.  As I said, I can
live with /boot on RAID without dm-integrity, as long as the rest can be
dm-integrity+raid protected.

[1] 
https://unix.stackexchange.com/questions/717763/lvm2-integrity-feature-breaks-lv-activation

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Marc SCHAEFER]

Hello,

On Tue, May 21, 2024 at 08:41:58PM +0200, Franco Martelli wrote:
> I can only recommend you to read carefully the Wiki:
> https://raid.wiki.kernel.org/index.php/Dm-integrity

I did, and it looks it does not seem to document anything pertaining
to my issue:

1) I don't use integritysetup (from LUKS), but LVM RAID PVs -- I don't use
   LUKS encryption anyway on that system

2) the issue is not the kernel not supporting it, because when the
   system is up, it works (I have done tests to destroy part of the
   underlying devices, they get detected and fixed correctly)

3) the issue is not with the initrd -- I added the dm-integrity module
   and rebuilt the initrd (and actually the bug happens before grub2 loads
   the kernel & init) -- or at least "not yet"!  maybe this will fail
   later :)

4) actually the issue is just grub2, be it when the system is up
   (it complains about the special subvolumes) or at boot time

Having /boot on a LVM non enabled dm-integrity logical volume does not
work either, as soon as there is ANY LVM dm-integrity enabled logical
volume anywhere (even not linked to booting), grub2 complains (at boot
time or at update-grub) about the rimage LV.

Re: Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Franco Martelli]

On 20/05/24 at 14:35, Marc SCHAEFER wrote:

Any idea what could be the problem?  Any way to just make grub2 ignore
the rimage (sub)volumes at setup and boot time?  (I could live with / aka
vg1/root not using dm-integrity, as long as the data/docker/etc volumes
are integrity-protected) ?  Or how to make grub 100% compatible with a
vg1/root using dm-integrity (that would be obviously the final goal!)

Thank you for any pointers!


I can only recommend you to read carefully the Wiki:

https://raid.wiki.kernel.org/index.php/Dm-integrity

HTH

kind regards
--
Franco Martelli

Debian bookwork / grub2 / LVM / RAID / dm-integrity fails to boot

[Marc SCHAEFER]

Hello,

1. INITIAL SITUATION: WORKS (no dm-integrity at all)

I have a Debian bookwork uptodate system that boots correctly with
kernel 6.1.0-21-amd64.

It is setup like this:

   - /dev/nvme1n1p1 is /boot/efi

   - /dev/nvme0n1p2 and /dev/nvme1n1p2 are the two LVM physical volumes

   - a volume group, vg1 is built with those PVs

vg1 has a few LVs that have been created in RAID1 LVM mode:

lvdisplay | egrep 'Path|Mirrored'

  LV Path/dev/vg1/root   <-- this is /
  Mirrored volumes   2
  LV Path/dev/vg1/swap
  Mirrored volumes   2
  LV Path/dev/vg1/scratch
  Mirrored volumes   2
  LV Path/dev/vg1/docker
  Mirrored volumes   2

As said, this boots without any issue.

2. ADDING dm-integrity WHILE BOOTED: works!

Now, while booted, I can add dm-integrity to one of the volumes,
let's say /dev/vg1/docker (this LV has absolutely no link with the
boot process, except obviously it is listed in /etc/fstab -- it also
fails the same way if even the swap is dm-integrit enabled, or
/):

   lvconvert  --raidintegrity y --raidintegritymode bitmap vg1/docker

and wait a bit til the integrity is setup with lvs -a (100%)

Obviously, this creates and uses a few rimage/rmeta sub LVs.

Then I did this (after having boot issues):

  echo dm_integrity >> /etc/initramfs-tools/modules
  update-initramfs -u

This did not change the below issue:

3. grub BOOT FAILS IF ANY LV HAS dm-integrity, EVEN IF NOT LINKED TO /

if I reboot now, grub2 complains about rimage issues, clear the screen
and then I am at the grub2 prompt.

Booting is only possible with Debian rescue, disabling the dm-integrity
on the above volume and rebooting. Note that you still can see the
rimage/rmeta sub LVs (lvs -a), they are not deleted! (but no
dm-integrity is activated).

4. update-grub GIVES WARNINGS

Now, if I try to start update-grub while booted AND having enabled
dm-integrity on the vg1/docker volume, I get:

# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-21-amd64
Found initrd image: /boot/initrd.img-6.1.0-21-amd64
error: unknown node 'docker_rimage_0'.
[ ... many ... ]
/usr/sbin/grub-probe: error: disk 
`lvmid/xLE0OV-wQy7-88H9-yKCz-4DUQ-Toce-h9rQvk/FzCf1C-95eB-7B0f-DSrF-t1pg-66qp-hmP3nZ'
 not found.
error: unknown node 'docker_rimage_0'.
[ ... many ... ]

[ this repeats a few times ]

Found linux image: /boot/vmlinuz-6.1.0-10-amd64
Found initrd image: /boot/initrd.img-6.1.0-10-amd64
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will not be executed to detect other bootable partitions.
[ there are none ]
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

Any idea what could be the problem?  Any way to just make grub2 ignore
the rimage (sub)volumes at setup and boot time?  (I could live with / aka
vg1/root not using dm-integrity, as long as the data/docker/etc volumes
are integrity-protected) ?  Or how to make grub 100% compatible with a
vg1/root using dm-integrity (that would be obviously the final goal!)

Thank you for any pointers!

Re: Uninstall grub2 on Sparc T2000

[Dan Ritter]

pvilt...@free.fr wrote: 
> Hello, 
> 
> I burned [ 
> https://cdimage.debian.org/cdimage/ports/current/debian-11.0.0-sparc64-NETINST-1.iso
>  | debian-11.0.0-sparc64-NETINST-1.iso ] on CdRom for a Sun T2000 (Sun4v) 
> Used Putty on windows 10 with SerManagement 
> 
> Boot OK 
> Startup OK 
> Partition not OK(?) : Warnings : Detects 256000 blocks on 65676 blocks ??? 

That's the problem. This should be a SAS disk; how is it
addressed? /dev/sda?

> But Install the Grub boot Loader 
> Unable to install GRUB in /dev/md126p1 
> Executing 'grub-install /dev/md126p1' failed 

Derives from the previous problem.

-dsr-

Uninstall grub2 on Sparc T2000

[pviltard]

Hello, 

I burned [ 
https://cdimage.debian.org/cdimage/ports/current/debian-11.0.0-sparc64-NETINST-1.iso
 | debian-11.0.0-sparc64-NETINST-1.iso ] on CdRom for a Sun T2000 (Sun4v) 
Used Putty on windows 10 with SerManagement 

Boot OK 
Startup OK 
Partition not OK(?) : Warnings : Detects 256000 blocks on 65676 blocks ??? 
Network OK 
Download Packages OK 
Upgrade with Site mirror Germany OK 
But Install the Grub boot Loader 
Unable to install GRUB in /dev/md126p1 
Executing 'grub-install /dev/md126p1' failed 
This is a fatal error. 

Used one disk 73Gb SunFRU : 540-6601-01 Fujitsu Limited 
No Raid. 

Thanks for your Help. 
Pascal 

Tipo de fuente de GRUB2 (era: Tildes y eñes en consola de X.)

[Camaleón]

El 2022-04-12 a las 09:41 -0500, Aristobulo Pinzon escribió:

> Algo fuera de lugar. :-)
> 
> En el /boot/grub/grub.cfg hay una linea que dice
> font="/usr/share/grub/unicode.pf2" y supongo que es las fuentes que se usan
> en el menú de inicio del sistema y que solo duran un poco.
> 
> Pregunta: ¿ Habrá alguna manera de seguirlas utilizando como como fuentes
> para las tty?

Si existe una aplicación para generar tipos de letra pf2 (grub2-mkfont) 
debe haber otra para hacer lo contrario, es decir, para convertir tipos 
de letra con formato pf2 a ttf u otf, etc...

De todas formas, si tiene sinterés en tipos de letra para usar en 
terminales y consolas, yo miraría las del paquete «fonts-terminus-otb», 
quizá te sirvan.

En cualquier caso, me parece que el origen del tipo de letra que usa 
GRUB2 es éste:

https://unifoundry.com/unifont/index.html

Saludos,

-- 
Camaleón 

Re: grub2 uefi et raid

[Kohler Gerard]

Le 20/10/2021 à 06:43, Jean-Michel OLTRA a écrit :

 Bonjour,


Le mardi 19 octobre 2021, Kohler Gerard a écrit...



Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
sur quel disque et quelle partition il est installé.

comment faire pour avoir ces réponses ?

Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).


habituellement pour installer une nouvelle version je clone ma partition
système et je fais un upgrade. comment faire pour réinstaller Grub et sur
quelle partition/DD ?

Avec grub-install, je pense.


je vous remercie avec retard !,

après sauvegarde j'ai du tout réinstallé, avec un grub tout neuf.

le problème de base venais du fait que je clonais mes partitions avec 
gparted, et celui-ci marque les partitions clonées avec le même UUID que 
la partition d'origine, d’où un petit mélange.


Gérard

Re : Re: grub2 uefi et raid

[k6dedijon]

Bonjour,
La réponse de Wallace est bonne.
Mais elle nécessite un disque par distro.

Tu peux essayer de mettre une image de fond différente par distribution, mettre 
un écran de connexion différent (ssdm).
Tu peux aussi paramétrer Grub pour qu'il indique sur quelle partition est le 
système sur lequel tu vas démarrer.
Cela se traduira par une ligne de menu :
Debian X (on dev/sdYY)
X= numéro de version de Debiaan
YY= lettre du lecteur et le numéro de partition
Par exemple :
Debian 10 (on dev/sdc3)

Bon courage
Cassis



- Mail d'origine -
De: Wallace 
À: debian-user-french@lists.debian.org
Envoyé: Wed, 20 Oct 2021 12:38:55 +0200 (CEST)
Objet: Re: grub2 uefi et raid

Tu t'es aventuré dans une installation compliquée.

Pour ma part j'ai arrêté de faire du multiboot géré par un OS ça finit 
toujours mal lors d'une réinstallation d'un OS.

Sur mon ordi fixe qui a plusieurs OS, lorsque je fais une installation 
je débranche tous les disques non concernés, puis quand j'ai tout 
rebranché, je fais F8 pour choisir le disque sur lequel je veux booter 
si j'en veux un différent du par défaut.

Bon courage

Le 20/10/2021 à 06:43, Jean-Michel OLTRA a écrit :
>  Bonjour,
>
>
> Le mardi 19 octobre 2021, Kohler Gerard a écrit...
>
>
>> Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
>> sur quel disque et quelle partition il est installé.
>>
>> comment faire pour avoir ces réponses ?
> Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).
>
>> habituellement pour installer une nouvelle version je clone ma partition
>> système et je fais un upgrade. comment faire pour réinstaller Grub et sur
>> quelle partition/DD ?
> Avec grub-install, je pense.
>

Re: grub2 uefi et raid

[Wallace]

Tu t'es aventuré dans une installation compliquée.

Pour ma part j'ai arrêté de faire du multiboot géré par un OS ça finit 
toujours mal lors d'une réinstallation d'un OS.


Sur mon ordi fixe qui a plusieurs OS, lorsque je fais une installation 
je débranche tous les disques non concernés, puis quand j'ai tout 
rebranché, je fais F8 pour choisir le disque sur lequel je veux booter 
si j'en veux un différent du par défaut.


Bon courage

Le 20/10/2021 à 06:43, Jean-Michel OLTRA a écrit :

 Bonjour,


Le mardi 19 octobre 2021, Kohler Gerard a écrit...



Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
sur quel disque et quelle partition il est installé.

comment faire pour avoir ces réponses ?

Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).


habituellement pour installer une nouvelle version je clone ma partition
système et je fais un upgrade. comment faire pour réinstaller Grub et sur
quelle partition/DD ?

Avec grub-install, je pense.

Re: grub2 uefi et raid

[Jean-Michel OLTRA]

Bonjour,


Le mardi 19 octobre 2021, Kohler Gerard a écrit...


> Le problème : je ne me rappelle plus quel est le Debian qui gère le Grub, ni
> sur quel disque et quelle partition il est installé.
> 
> comment faire pour avoir ces réponses ?

Avec `fdisk -l` ou au menu de grub lors du boot (commande `find` de grub).

> habituellement pour installer une nouvelle version je clone ma partition
> système et je fais un upgrade. comment faire pour réinstaller Grub et sur
> quelle partition/DD ?

Avec grub-install, je pense.

-- 
jm

grub2 uefi et raid

[Kohler Gerard]

bonjour,

voulant installer la version testing je me heurte à un problème bête :

Ma machine est dotée d'UEFI.

j'ai 3 DD dont les deux premiers sont montés en RAID1 (/dev/sda et 
/dev/sdb) et ils contiennent mes données, le troisième (/dev/sdc) est 
mon disque système.


sur mon disque système j'ai plusieurs partitions avec des versions de 
Debian différentes .


Au démarrage Grub me permet de choisir entre les différents systèmes 
Debian (j'ai 5 Debian différents, des versions historiques ...).


Le problème : je ne me rappelle plus quel est le Debian qui gère le 
Grub, ni sur quel disque et quelle partition il est installé.


comment faire pour avoir ces réponses ?

autre question :

habituellement pour installer une nouvelle version je clone ma partition 
système et je fais un upgrade. comment faire pour réinstaller Grub et 
sur quelle partition/DD ?


merci de votre aide

Gérard

Re: apt tells me that grub-efi, grub2-common are no longer needed

[David Wright]

On Thu 24 Jun 2021 at 17:06:50 (+0200), Markus wrote:
> I wanted to reinstall grub-efi-amd64 and got this:
> 
> markus@bmtMB1:/var/log/apt$ sudo apt install grub-efi-amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  grub-efi-amd64 : Depends: grub-common (= 2.02+dfsg1-20+deb10u3)
>   Depends: grub2-common (= 2.02+dfsg1-20+deb10u3)
>   Depends: grub-efi-amd64-bin (= 2.02+dfsg1-20+deb10u3)
> E: Unable to correct problems, you have held broken packages.
> markus@bmtMB1:/var/log/apt$
> 
> 
> So...something is wrong here. Puhh...how to fix that?

Aftr reading the bug report (seems to be about macbooks, dual disks,
misconfigured grubs, etc), and https://wiki.debian.org/AptConfiguration
which gives an idea of pinning, you might consider just:

  $ sudo apt install grub-efi-amd64=2.02+dfsg1-20+deb10u4

I think you only have the one package pinned, so its dependencies
should just get dragged in as normal.

(Where there are several interrelated packages that are problematical,
people sometimes forget that installing them all in the same command
line can succeed, while installing one by one fails.)

Safety first: always have an alternative method of booting available
(usually a USB stick).

Cheers,
David.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[The Wanderer]

On 2021-07-08 at 04:21, Markus wrote:

> Am 07.07.21 um 12:27 schrieb Markus:

>> markus@bmtMB1:/etc/apt/preferences.d$ ls
>> apt-listbugs
>> markus@bmtMB1:/etc/apt/preferences.d$ cat apt-listbugs
>>
>> Explanation: Pinned by apt-listbugs at 2021-03-06 12:05:35 +0100
>> Explanation:   #984520: 'error: symbol "grub_register_command_lockdown"
>> not found' and then lightdm fails to start
>> Package: grub-efi-amd64
>> Pin: version 2.02+dfsg1-20+deb10u3
>> Pin-Priority: 3
>>
>> Explanation: Pinned by apt-listbugs at 2021-06-20 11:19:38 +0200
>> Explanation:   #990082: High chance of boot problems with buster's
>> version of arm64 shim
>> Package: shim-signed
>> Pin: version 1.33+15+1533136590.3beb971-7
>> Pin-Priority: 3
>> markus@bmtMB1:/etc/apt/preferences.d$
>>
>>
>> So it seems that apt-listbugs has done the pinning. Right?
> 
> Hi guys, it is nice that from all of this a little discussion took of.
> But what can I actually do to fix my problem here? Any suggestions?

As Anssi said, that would depend what you define the problem to be.

The *symptom* is what you describe in the Subject line, and have
discussed previously.

The *cause* is the fact that someone (or some automatic mechanism, and I
don't know of any such that might exist) has seen these bug reports, and
has decided to create pins to prevent the reported-as-buggy versions
from being upgraded to.

What to do about the latter would boil down to a question of what to
decide about those bug reports. For that, you need to examine and
analyze them directly, and come to your own decisions.

You might also want to try to figure out how those pins came to be
created. If you created them (or told apt-listbugs to do so), then
presumably seeing them will have jogged your memory about why you
decided to create them, and you'll be able to make decisions about the
listed bugs based on that memory; if something else created them, then
you'll want to identify what that something else was.


The general process for dealing with pins like these, once created and
observed to be getting in the way, is:

Look at the bug reports listed in the pin(s) for the package(s) you care
about.

Decide whether or not that bug might apply to your system, and whether
or not that bug is something you expect to care about, and whether or
not you're willing to risk the consequences of having the bug on your
system if you're wrong.

Based on that decision, either A: remove the pin and install the updated
package version anyway (i.e., accept the risk), or B: keep waiting, for
the bug to be fixed and the fixed package version to be made available
in a repository you're tracking.


When I decide to do A, I simply edit
/etc/apt/preferences.d/apt-listbugs, and delete (or comment out) the
section matching that pin. There may or may not be a better way of doing
it; if there is, I can't personally advise you on it.

If you decide to do B, but want to avoid the "no longer needed" reports
from apt, then you have the option to C: pick one or more of the
packages named as being "no longer needed", and mark that package as
being manually installed ('apt-mark manual packagename' should do it).
That should paper over the symptom, while still leaving the underlying
cause in place. Personally, I don't usually do this, because I prefer to
keep the set of marked-manual packages to a reasonable minimum - but
that's a case-by-case decision, which depends largely on the
sensibilities of the individual sysadmin.


As you may be able to tell from the small discussion which has ensued
from this, the bug for shim-signed is probably not relevant to you
(unless the system you've pinned it on is arm64), so it should probably
be safe to override that one; then again, that one's also fixed (albeit
not necessarily in a version yet available in a repo you're tracking),
so it might be worth waiting.

As you may also be able to tell from that same discussion, the bug for
grub-efi-amd64 is still open. Examining the bug report for that bug
shows that it seems likely to turn out to be a problem with the specific
firmware used on the specific motherboard of the specific person
reporting the problem, and not a problem with the named package itself;
unless you expect to have a similar firmware with similar problems, this
may not be relevant to you. Then again, that bug report *is* still open,
so you might want to wait until either it gets closed or at least it
gets downgraded to a lower, non-release-critical severity (which would
indicate that it's not considered likely to be a problem for enough
users to warrant delaying the upcoming Debian release).

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Anssi Saari]

Markus  writes:

> Hi guys, it is nice that from all of this a little discussion took of.
> But what can I actually do to fix my problem here? Any suggestions?

What was the problem again? Just the suggestion to run apt autoremove
which probably isn't a good idea now?

Easiest is probably waiting until the bugs get fixed and fixes
distributed, the pinning should disappear and no more suggestions from
apt.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

Am 07.07.21 um 12:27 schrieb Markus:

Am 07.07.21 um 09:24 schrieb Andrei POPESCU:

On Mi, 07 iul 21, 08:21:17, Markus wrote:

Am 24.06.21 um 18:51 schrieb Greg Wooledge:

On Thu, Jun 24, 2021 at 06:43:15PM +0200, Markus wrote:

grub-efi-amd64:
    Installed: (none)
    Candidate: 2.02+dfsg1-20+deb10u3
    Version table:
   2.02+dfsg1-20+deb10u4 500
  500 http://ftp.de.debian.org/debian buster/main amd64
Packages
  500 http://security.debian.org buster/updates/main amd64
Packages
   2.02+dfsg1-20+deb10u3 3
  100 /var/lib/dpkg/status


Everything else looks good, except for this "3" section.  You've
got
a pin somewhere, for an older version of grub-efi-amd64, and it's
throwing everything out of whack.


Could you please help me fixing this? What are the next steps to go? How
can I unpin this or find out why it was pinned?


Please show the output of `apt policy` (without any package) as well as
the contents of /etc/apt/preferences and any file under
/etc/apt/preferences.d/

Kind regards,
Andrei



apt policy:

Package files:
  100 /var/lib/dpkg/status
  release a=now
  100 http://ftp.de.debian.org/debian buster-backports/non-free i386
Packages
  release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=non-free,b=i386
  origin ftp.de.debian.org
  100 http://ftp.de.debian.org/debian buster-backports/non-free amd64
Packages
  release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=non-free,b=amd64
  origin ftp.de.debian.org
  100 http://ftp.de.debian.org/debian buster-backports/contrib i386
Packages
  release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=contrib,b=i386
  origin ftp.de.debian.org
  100 http://ftp.de.debian.org/debian buster-backports/contrib amd64
Packages
  release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=contrib,b=amd64
  origin ftp.de.debian.org
  100 http://ftp.de.debian.org/debian buster-backports/main i386 Packages
  release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=main,b=i386
  origin ftp.de.debian.org
  100 http://ftp.de.debian.org/debian buster-backports/main amd64 Packages
  release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=main,b=amd64
  origin ftp.de.debian.org
  500 http://ftp.de.debian.org/debian buster-updates/main i386 Packages
  release
o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=i386
  origin ftp.de.debian.org
  500 http://ftp.de.debian.org/debian buster-updates/main amd64 Packages
  release
o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=amd64
  origin ftp.de.debian.org
  500 http://security.debian.org buster/updates/non-free i386 Packages
  release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=non-free,b=i386
  origin security.debian.org
  500 http://security.debian.org buster/updates/non-free amd64 Packages
  release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=non-free,b=amd64
  origin security.debian.org
  500 http://security.debian.org buster/updates/main i386 Packages
  release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=i386
  origin security.debian.org
  500 http://security.debian.org buster/updates/main amd64 Packages
  release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=amd64
  origin security.debian.org
  500 http://ftp.de.debian.org/debian buster/non-free i386 Packages
  release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=i386
  origin ftp.de.debian.org
  500 http://ftp.de.debian.org/debian buster/non-free amd64 Packages
  release
v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=amd64
  origin ftp.de.debian.org
  500 http://ftp.de.debian.org/debian buster/contrib i386 Packages
  release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=i386
  origin ftp.de.debian.org
  500 http://ftp.de.debian.org/debian buster/contrib amd64 Packages
  release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=amd64
  origin ftp.de.debian.org
  500 http://ftp.de.debian.org/debian buster/main i386 Packages
  release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=main,b=i386
  origin ftp.de.debian.org
  500 http://ftp.de.debian.org/debian buster/main amd64 Packages
  release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=main,b=amd64
  origin ftp.de.debian.org
Pinned packages:
  grub-efi-amd64 -> 2.02+dfsg1-20+deb10u3 with priority 3




markus@bmtMB1:/etc/apt$ cat preferences
cat: preferences: No such file or directory



markus@bmtMB1:/etc/apt/preferences.d$ ls
apt-listbugs
markus@bmtMB1:/etc/apt/preferences.d$ cat apt-listbugs

Explanation: Pinned by apt-listbugs at 2021-03-06 12:05:35 +0100
Explanation:   #984520: 'error: symbol "grub_register_command_lockdown"
not found' and then 

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Anssi Saari]

The Wanderer  writes:

> #990082 is for shim-signed, and it does seem to be closed now, but if
> I'm reading the discussion correctly that's not the package we're
> concerned with.

True, especially as #990082 is specific to ARM.

> $984520 is for grub-efi-amd64, which I think is the package we're
> concerned with, and as far as I can tell it's still open.

I missed this. The report seems a little dubious though.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[The Wanderer]

On 2021-07-07 at 08:19, Anssi Saari wrote:

> Markus  writes:
> 
>> So it seems that apt-listbugs has done the pinning. Right?
> 
> Right and while I've never used apt-listbugs, it should've asked you
>  what to do when you updated your system? Since the issue concerns 
> ARM based systems only, binning was not the correct choice.
> 
> As the bug is fixed now

Is it?

I saw two bugs listed under the 3 apt-listbugs pins: #984520 and
#990082.

#990082 is for shim-signed, and it does seem to be closed now, but if
I'm reading the discussion correctly that's not the package we're
concerned with.

$984520 is for grub-efi-amd64, which I think is the package we're
concerned with, and as far as I can tell it's still open.

> it seems to me apt-listbugs should clean this up by itself, it's
> supposed to run periodically. I guess you could run it manually too.

If I'm not mistaken, the cleanup will only happen when the appropriate
package version is available in the repositories configured as visible
in /etc/apt/sources.list*.

As far as I can see at a quick glance, the package versions with the fix
are not in testing; they're only in unstable and in buster-security. If
Markus is not tracking either of those repos, then the fixed version
won't show as available yet, so the pin won't be automatically removed.


(I learned something today; I thought the check for removing the pin was
done at apt-listbugs invocation time, not on a daily cron job. In
hindsight it makes sense, since apt-listbugs can be invoked manually and
the invoking user probably wouldn't have write access to modify
/etc/apt/preferences/ contents, but I wasn't expecting it.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Anssi Saari]

Markus  writes:

> So it seems that apt-listbugs has done the pinning. Right?

Right and while I've never used apt-listbugs, it should've asked you
what to do when you updated your system? Since the issue concerns ARM
based systems only, binning was not the correct choice.

As the bug is fixed now it seems to me apt-listbugs should clean this up
by itself, it's supposed to run periodically. I guess you could run it
manually too.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Greg Wooledge]

On Wed, Jul 07, 2021 at 08:21:17AM +0200, Markus wrote:
> Am 24.06.21 um 18:51 schrieb Greg Wooledge:
> > On Thu, Jun 24, 2021 at 06:43:15PM +0200, Markus wrote:
> > > grub-efi-amd64:
> > >Installed: (none)
> > >Candidate: 2.02+dfsg1-20+deb10u3
> > >Version table:
> > >   2.02+dfsg1-20+deb10u4 500
> > >  500 http://ftp.de.debian.org/debian buster/main amd64 Packages
> > >  500 http://security.debian.org buster/updates/main amd64 Packages
> > >   2.02+dfsg1-20+deb10u3 3
> > >  100 /var/lib/dpkg/status
> > 
> > Everything else looks good, except for this "3" section.  You've got
> > a pin somewhere, for an older version of grub-efi-amd64, and it's
> > throwing everything out of whack.
> > 
> Could you please help me fixing this? What are the next steps to go? How
> can I unpin this or find out why it was pinned?

I would have started with "grep -r 3 /etc/apt" but it seems you
found another path to the answer.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

Am 07.07.21 um 09:24 schrieb Andrei POPESCU:

On Mi, 07 iul 21, 08:21:17, Markus wrote:

Am 24.06.21 um 18:51 schrieb Greg Wooledge:

On Thu, Jun 24, 2021 at 06:43:15PM +0200, Markus wrote:

grub-efi-amd64:
Installed: (none)
Candidate: 2.02+dfsg1-20+deb10u3
Version table:
   2.02+dfsg1-20+deb10u4 500
  500 http://ftp.de.debian.org/debian buster/main amd64 Packages
  500 http://security.debian.org buster/updates/main amd64 Packages
   2.02+dfsg1-20+deb10u3 3
  100 /var/lib/dpkg/status


Everything else looks good, except for this "3" section.  You've got
a pin somewhere, for an older version of grub-efi-amd64, and it's
throwing everything out of whack.


Could you please help me fixing this? What are the next steps to go? How
can I unpin this or find out why it was pinned?


Please show the output of `apt policy` (without any package) as well as
the contents of /etc/apt/preferences and any file under
/etc/apt/preferences.d/

Kind regards,
Andrei



apt policy:

Package files:
 100 /var/lib/dpkg/status
 release a=now
 100 http://ftp.de.debian.org/debian buster-backports/non-free i386
Packages
 release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=non-free,b=i386
 origin ftp.de.debian.org
 100 http://ftp.de.debian.org/debian buster-backports/non-free amd64
Packages
 release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=non-free,b=amd64
 origin ftp.de.debian.org
 100 http://ftp.de.debian.org/debian buster-backports/contrib i386 Packages
 release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=contrib,b=i386
 origin ftp.de.debian.org
 100 http://ftp.de.debian.org/debian buster-backports/contrib amd64
Packages
 release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=contrib,b=amd64
 origin ftp.de.debian.org
 100 http://ftp.de.debian.org/debian buster-backports/main i386 Packages
 release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=main,b=i386
 origin ftp.de.debian.org
 100 http://ftp.de.debian.org/debian buster-backports/main amd64 Packages
 release o=Debian
Backports,a=buster-backports,n=buster-backports,l=Debian
Backports,c=main,b=amd64
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian buster-updates/main i386 Packages
 release
o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=i386
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian buster-updates/main amd64 Packages
 release
o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=amd64
 origin ftp.de.debian.org
 500 http://security.debian.org buster/updates/non-free i386 Packages
 release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=non-free,b=i386
 origin security.debian.org
 500 http://security.debian.org buster/updates/non-free amd64 Packages
 release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=non-free,b=amd64
 origin security.debian.org
 500 http://security.debian.org buster/updates/main i386 Packages
 release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=i386
 origin security.debian.org
 500 http://security.debian.org buster/updates/main amd64 Packages
 release
v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=amd64
 origin security.debian.org
 500 http://ftp.de.debian.org/debian buster/non-free i386 Packages
 release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=i386
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian buster/non-free amd64 Packages
 release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=amd64
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian buster/contrib i386 Packages
 release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=i386
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian buster/contrib amd64 Packages
 release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=amd64
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian buster/main i386 Packages
 release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=main,b=i386
 origin ftp.de.debian.org
 500 http://ftp.de.debian.org/debian buster/main amd64 Packages
 release v=10.10,o=Debian,a=stable,n=buster,l=Debian,c=main,b=amd64
 origin ftp.de.debian.org
Pinned packages:
 grub-efi-amd64 -> 2.02+dfsg1-20+deb10u3 with priority 3




markus@bmtMB1:/etc/apt$ cat preferences
cat: preferences: No such file or directory



markus@bmtMB1:/etc/apt/preferences.d$ ls
apt-listbugs
markus@bmtMB1:/etc/apt/preferences.d$ cat apt-listbugs

Explanation: Pinned by apt-listbugs at 2021-03-06 12:05:35 +0100
Explanation:   #984520: 'error: symbol "grub_register_command_lockdown"
not found' and then lightdm fails to start
Package: grub-efi-amd64
Pin: version 2.02+dfsg1-20+deb10u3
Pin-Priority: 

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Andrei POPESCU]

On Mi, 07 iul 21, 08:21:17, Markus wrote:
> Am 24.06.21 um 18:51 schrieb Greg Wooledge:
> > On Thu, Jun 24, 2021 at 06:43:15PM +0200, Markus wrote:
> > > grub-efi-amd64:
> > >Installed: (none)
> > >Candidate: 2.02+dfsg1-20+deb10u3
> > >Version table:
> > >   2.02+dfsg1-20+deb10u4 500
> > >  500 http://ftp.de.debian.org/debian buster/main amd64 Packages
> > >  500 http://security.debian.org buster/updates/main amd64 Packages
> > >   2.02+dfsg1-20+deb10u3 3
> > >  100 /var/lib/dpkg/status
> > 
> > Everything else looks good, except for this "3" section.  You've got
> > a pin somewhere, for an older version of grub-efi-amd64, and it's
> > throwing everything out of whack.
> > 
> Could you please help me fixing this? What are the next steps to go? How
> can I unpin this or find out why it was pinned?

Please show the output of `apt policy` (without any package) as well as 
the contents of /etc/apt/preferences and any file under 
/etc/apt/preferences.d/

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

Am 24.06.21 um 18:51 schrieb Greg Wooledge:

On Thu, Jun 24, 2021 at 06:43:15PM +0200, Markus wrote:

grub-efi-amd64:
   Installed: (none)
   Candidate: 2.02+dfsg1-20+deb10u3
   Version table:
  2.02+dfsg1-20+deb10u4 500
 500 http://ftp.de.debian.org/debian buster/main amd64 Packages
 500 http://security.debian.org buster/updates/main amd64 Packages
  2.02+dfsg1-20+deb10u3 3
 100 /var/lib/dpkg/status


Everything else looks good, except for this "3" section.  You've got
a pin somewhere, for an older version of grub-efi-amd64, and it's
throwing everything out of whack.


Could you please help me fixing this? What are the next steps to go? How
can I unpin this or find out why it was pinned?

Thanks in advance

Re: grub2 boot menu

[didier gaumet]

Le vendredi 25 juin 2021 à 11:40 -0400, Cindy Sue Causey a écrit :
> On 6/24/21, didier gaumet  wrote:
> 
[...]
> > 'GRUB_OS_PROBER_SKIP_LIST'
> >     List of space-separated FS UUIDs of filesystems to be ignored
> > from
> >  os-prober output.  For efi chainloaders it's @"
[...]
> it would surely help if someone could point GRUB
> Users to what that "" is referencing.
[...]

My laptop (with an EFI firmware) has a dual boot with Debian Bullseye
and Windows 10. In this Windows 10 case, it is an EFI chainloading
(that would not be the case (chainloading) with another OS without its
self bootloader installed and properly configured)

My /boot/grub.grub.cfg contains:
"[...]
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/nvme0n1p3)' --class windows --
class os $menuentry_id_option 'osprober-efi-FAF2-88F6' {
insmod part_gpt
insmod fat
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  FAF2-88F6
else
  search --no-floppy --fs-uuid --set=root FAF2-88F6
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###
[...]"

I edit /etc/default/grub to add this line:
GRUB_OS_PROBER_SKIP_LIST='FAF2-88F6@/EFI/Microsoft/Boot/bootmgfw.efi'

then I update the config:
didier@hp-notebook14:~$ sudo update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-7-amd64
Found initrd image: /boot/initrd.img-5.10.0-7-amd64
Skipped Windows Boot Manager on
/dev/nvme0n1p3@/EFI/Microsoft/Boot/bootmgfw.efi by user request.
Adding boot menu entry for EFI firmware configuration
done

So the Windows 10 entry has been skipped

It is confirmed by inspecting /boot/grub/grub.cfg:
"[...]
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
[...]"

Cheers :-)

Re: grub2 boot menu

[Cindy Sue Causey]

On 6/24/21, didier gaumet  wrote:
>
> Hello,
>
> Grub can ignore all or only certain OSes that os-prober detects by
> setting up the desired behaviour in /etc/default/grub
>
> from the grub info page:
> [...]"
> 'GRUB_DISABLE_OS_PROBER'
>  Normally, 'grub-mkconfig' will try to use the external 'os-prober'
>  program, if installed, to discover other operating systems
>  installed on the same system and generate appropriate menu entries
>  for them.  Set this option to 'true' to disable this.
>
> 'GRUB_OS_PROBER_SKIP_LIST'
>  List of space-separated FS UUIDs of filesystems to be ignored from
>  os-prober output.  For efi chainloaders it's @
> "[...]


This is basically just noise, but, ooohhh, that sounds NICE and
HANDY. I'm wondering how many other tricks like that exist that never
see the light of day. In a perfect World, maybe someone with deep
knowledge of those features could approach Debian-Publicity about
submitting e.g. "Hey, Did You Know You Can" tips that are included
in their newsletters and updates?

Speaking as someone with cognitive issues such that I operate as a
perennial newbie, it would surely help if someone could point GRUB
Users to what that "" is referencing.

For now, it just sounds like part of the fancier loading needs that
are occasionally discussed here on Debian-User. My thought process is
that maybe hearing it further described will trigger a fellow lurker's
interest in learning more about how their Debian works right from the
boot beginning.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: grub2 boot menu

[elvis]

On 24/6/21 11:51 pm, mick crane wrote:

hello,
I was dual booting but got another PC so I can have windows and debain 
at the same time. Just for tidiness of booting I'd have liked to 
comment out the submenu entry in /boot/grub/grub.cfg for windows just 
in case I wanted to put it back but not allowed.
Physically removing the windows disk and "grub-mkconfig" and/or 
"update-grub" sorts itself out but is there any way to do this 
manually as used to be the case ?

mick


you can still edit /boot/grub/grub.cfg

It's a bit more complex than the old grub but it's pretty obvious which bit it 
which when you look at it.

Any changes will be overwritten by grub-mkconfig but I assume that is what you 
want.



--
Sir John Hoskyns, an adviser to Margaret Thatcher, observed that governments 
are formed from ?a talent pool that could not sustain a single multinational 
company.?

Re: grub2 boot menu

[didier gaumet]

Hello, 

Grub can ignore all or only certain OSes that os-prober detects by
setting up the desired behaviour in /etc/default/grub

from the grub info page:
[...]"
'GRUB_DISABLE_OS_PROBER'
 Normally, 'grub-mkconfig' will try to use the external 'os-prober'
 program, if installed, to discover other operating systems
 installed on the same system and generate appropriate menu entries
 for them.  Set this option to 'true' to disable this.

'GRUB_OS_PROBER_SKIP_LIST'
 List of space-separated FS UUIDs of filesystems to be ignored from
 os-prober output.  For efi chainloaders it's @
"[...]

 :-)

Re: grub2 boot menu

[David Wright]

On Thu 24 Jun 2021 at 14:51:06 (+0100), mick crane wrote:
> I was dual booting but got another PC so I can have windows and debain
> at the same time. Just for tidiness of booting I'd have liked to
> comment out the submenu entry in /boot/grub/grub.cfg for windows just
> in case I wanted to put it back but not allowed.
> Physically removing the windows disk and "grub-mkconfig" and/or
> "update-grub" sorts itself out but is there any way to do this
> manually as used to be the case ?

Some BIOSes will allow you to turn off a disk interface.
But I can't see the point, myself. I've only done this
when I had an interface that would stall booting (and
updating Grub) for 10 minutes while it repeatedly timed
out many many times. (IOW it was broken.)

The Windows entry would disappear when grub.cfg is rebuilt
(unless you edit it yourself). Of course, when you wanted
Windows back, you'd need to rebuild grub.cfg again before
you could boot it (unless you learn a few raw Grub commands).

Can you not just ignore the entry. It's usually right at the
bottom of the list. In fact, do you really *read* the grub
menu when you boot?

Cheers,
David.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Greg Wooledge]

On Thu, Jun 24, 2021 at 06:43:15PM +0200, Markus wrote:
> grub-efi-amd64:
>   Installed: (none)
>   Candidate: 2.02+dfsg1-20+deb10u3
>   Version table:
>  2.02+dfsg1-20+deb10u4 500
> 500 http://ftp.de.debian.org/debian buster/main amd64 Packages
> 500 http://security.debian.org buster/updates/main amd64 Packages
>  2.02+dfsg1-20+deb10u3 3
> 100 /var/lib/dpkg/status

Everything else looks good, except for this "3" section.  You've got
a pin somewhere, for an older version of grub-efi-amd64, and it's
throwing everything out of whack.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

More information:

markus@bmtMB1:/var/log/apt$ sudo apt policy grub-efi-amd64 grub-common
grub2-common grub-efi-amd64-bin
grub-efi-amd64:
  Installed: (none)
  Candidate: 2.02+dfsg1-20+deb10u3
  Version table:
 2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
 2.02+dfsg1-20+deb10u3 3
100 /var/lib/dpkg/status
grub-common:
  Installed: 2.02+dfsg1-20+deb10u4
  Candidate: 2.02+dfsg1-20+deb10u4
  Version table:
 *** 2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
grub2-common:
  Installed: 2.02+dfsg1-20+deb10u4
  Candidate: 2.02+dfsg1-20+deb10u4
  Version table:
 *** 2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
grub-efi-amd64-bin:
  Installed: 2.02+dfsg1-20+deb10u4
  Candidate: 2.02+dfsg1-20+deb10u4
  Version table:
 *** 2.02+dfsg1-20+deb10u4 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
500 http://security.debian.org buster/updates/main amd64 Packages
100 /var/lib/dpkg/status
markus@bmtMB1:/var/log/apt$


Sources list:

markus@bmtMB1:/etc/apt$ cat sources.list
deb http://ftp.de.debian.org/debian/ buster main contrib non-free
deb-src http://ftp.de.debian.org/debian/ buster main contrib non-free

deb http://security.debian.org/ buster/updates main contrib non-free
deb-src http://security.debian.org/ buster/updates main contrib non-free

# buster-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ buster-updates main contrib non-free
deb-src http://ftp.de.debian.org/debian/ buster-updates main contrib
non-free

# buster-backports
deb http://ftp.de.debian.org/debian/ buster-backports main contrib non-free

# unofficial vbox
deb http://download.virtualbox.org/virtualbox/debian buster contrib
markus@bmtMB1:/etc/apt$


Am 24.06.21 um 17:14 schrieb Greg Wooledge:

On Thu, Jun 24, 2021 at 05:06:50PM +0200, Markus wrote:

I wanted to reinstall grub-efi-amd64 and got this:

markus@bmtMB1:/var/log/apt$ sudo apt install grub-efi-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
  grub-efi-amd64 : Depends: grub-common (= 2.02+dfsg1-20+deb10u3)
   Depends: grub2-common (= 2.02+dfsg1-20+deb10u3)
   Depends: grub-efi-amd64-bin (= 2.02+dfsg1-20+deb10u3)
E: Unable to correct problems, you have held broken packages.
markus@bmtMB1:/var/log/apt$


Start by getting more information:

apt policy grub-efi-amd64 grub-common grub2-common grub-efi-amd64-bin

It wouldn't hurt to double-check your sources.list as well.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Greg Wooledge]

On Thu, Jun 24, 2021 at 05:06:50PM +0200, Markus wrote:
> I wanted to reinstall grub-efi-amd64 and got this:
> 
> markus@bmtMB1:/var/log/apt$ sudo apt install grub-efi-amd64
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  grub-efi-amd64 : Depends: grub-common (= 2.02+dfsg1-20+deb10u3)
>   Depends: grub2-common (= 2.02+dfsg1-20+deb10u3)
>   Depends: grub-efi-amd64-bin (= 2.02+dfsg1-20+deb10u3)
> E: Unable to correct problems, you have held broken packages.
> markus@bmtMB1:/var/log/apt$

Start by getting more information:

apt policy grub-efi-amd64 grub-common grub2-common grub-efi-amd64-bin

It wouldn't hurt to double-check your sources.list as well.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

I wanted to reinstall grub-efi-amd64 and got this:

markus@bmtMB1:/var/log/apt$ sudo apt install grub-efi-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 grub-efi-amd64 : Depends: grub-common (= 2.02+dfsg1-20+deb10u3)
  Depends: grub2-common (= 2.02+dfsg1-20+deb10u3)
  Depends: grub-efi-amd64-bin (= 2.02+dfsg1-20+deb10u3)
E: Unable to correct problems, you have held broken packages.
markus@bmtMB1:/var/log/apt$


So...something is wrong here. Puhh...how to fix that?


Thanks and Cheers
Markus


Am 24.06.21 um 13:10 schrieb Greg Wooledge:

On Thu, Jun 24, 2021 at 08:49:40AM +0200, Markus wrote:

Ok so...hmmm...I did not remove it myself. I mean why would I want to do
that?!?! Nevertheless this is an issue now.
Interestingly when booting my computer this morning grub was there and
booted into Buster. Shouldn't it be gone if it got removed (even though
it not got purged)? Hmmm...!?!?


Removing the grub packages doesn't remove GRUB from your hard drive(s).
Thankfully.


How to fix that? Is there actually something wrong (this morning grub
was there!!!) that needs to be fixed?
Is it save to just reinstall grub-efi-amd64?


It should be, as far as I know.  I'm not sure whether this will prompt
you for where to install GRUB, or whether it will retain knowledge of
this from the config files which you say haven't been purged yet.

It'll probably regenerate the grub.cfg menu, though.  If you haven't done
anything too silly, that shouldn't be an issue.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

Thank you, David, for the very useful hint.

I found this in apt history:

Start-Date: 2021-03-06  21:08:42
Commandline: apt full-upgrade
Requested-By: markus (1000)
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u3,
2.02+dfsg1-20+deb10u4), grub2-common:amd64 (2.02+dfsg1-20+deb10u3,
2.02+dfsg1-20+deb10u4), grub-efi-amd64-bin:amd64 (2.02+dfsg1-20+deb10u3,
2.02+dfsg1-20+deb10u4), grub-efi-amd64-signed:amd64
(1+2.02+dfsg1+20+deb10u3, 1+2.02+dfsg1+20+deb10u4)
Remove: grub-efi-amd64:amd64 (2.02+dfsg1-20+deb10u3)
End-Date: 2021-03-06  21:08:45


Do you guys maybe find similar entries in apt history?

So why did apt remove it while upgrading other grub corresponding
packages? And then afterwards apt is complaining and wants to remove
grub, efibootmgr and other stuff.

The following packages were automatically installed and are no longer
required:
efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
shim-signed-common
shim-unsigned

Is it somehow linked to that shim-* packages that got also updated.
Wasn't there a bug report recently about this package when updating to
Buster 10.10?

Maybe it was like this:
1. On 2021-03-06 grub-efi-amd64 got removed because the other updated
grub packages somehow took over its tasks

2. shim got updated just recently and took over the tasks of
efibootmgr
grub-efi-amd64-bin
grub-efi-amd64-signed
grub2-common

3. only grub-common gets not removed because it is still required and in
conjunction with shim it is enough and all fine.

Because if you subtract the "no longer required" grub packages from

markus@bmtMB1:/var/log/apt$ sudo dpkg -l | grep grub
ii  grub-common 2.02+dfsg1-20+deb10u4
rc  grub-efi-amd64  2.02+dfsg1-20+deb10u3
ii  grub-efi-amd64-bin  2.02+dfsg1-20+deb10u4
ii  grub-efi-amd64-signed   1+2.02+dfsg1+20+deb10u4
ii  grub-firmware-qemu  2.02+dfsg1-20+deb10u4
ii  grub2-common2.02+dfsg1-20+deb10u4

you end up with grub-common and grub-firmware-qemu.

From here you can read that shim is also some kind of bootloader:
https://packages.debian.org/en/buster/shim-signed

But obviously shim depends on grub2-common and grub-efi-amd64-bin.
Hmmm...this makes no sense...

Cheers



Am 24.06.21 um 16:00 schrieb David Wright:

On Thu 24 Jun 2021 at 08:49:40 (+0200), Markus wrote:

Am 23.06.21 um 18:08 schrieb David Wright:

On Wed 23 Jun 2021 at 17:01:07 (+0200), Markus wrote:



rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3

↑↑ There's your problem. It's been removed (but not purged).



Ok so...hmmm...I did not remove it myself. I mean why would I want to do
that?!?! Nevertheless this is an issue now.


Take a look at /var/log/apt/history.log* to see the reason
and/or the occasion (but not necessarily the intent).¹

As an example of how things can happen unintentionally, this
post from Tuesday illustrates where a broken package's bug
report seems to have led to a different package being removed:
https://lists.debian.org/debian-user/2021/06/msg00581.html


Interestingly when booting my computer this morning grub was there and
booted into Buster. Shouldn't it be gone if it got removed (even though
it not got purged)? Hmmm...!?!?


Only if you'd gone ahead and removed all those other packages.
There's actually nothing substantial inside grub-efi-amd64:

$ dpkg -L grub-efi-amd64
/.
/usr
/usr/share
/usr/share/bug
/usr/share/bug/grub-efi-amd64
/usr/share/bug/grub-efi-amd64/presubj
/usr/share/bug/grub-efi-amd64/script
/usr/share/doc
/usr/share/doc/grub-efi-amd64
$


How to fix that? Is there actually something wrong (this morning grub
was there!!!) that needs to be fixed?
Is it sa[f]e to just reinstall grub-efi-amd64?


Yes. The package exists for its dependencies. Just reinstall it.
You can then try autoremove again, and its list should now only
include the (presumably third) versions of the kernel packages
that you wanted to remove as a matter of routine, like mine in ¹.

¹ entries in /var/log/apt/history.log look like:

Start-Date: 2021-06-19  17:45:10
Commandline: apt-get --purge autoremove
Purge: linux-headers-4.19.0-14-amd64:amd64 (4.19.171-2), 
linux-headers-4.19.0-14-common:amd64 (4.19.171-2), 
linux-image-4.19.0-14-amd64:amd64 (4.19.171-2)
End-Date: 2021-06-19  17:45:33

Cheers,
David.

Re: grub2 boot menu

[The Wanderer]

On 2021-06-24 at 10:32, Felix Miata wrote:

> mick crane composed on 2021-06-24 14:51 (UTC+0100):
> 
>> I was dual booting but got another PC so I can have windows and debain 
>> at the same time. Just for tidiness of booting I'd have liked to comment 
>> out the submenu entry in /boot/grub/grub.cfg for windows just in case I 
>> wanted to put it back but not allowed.
>> Physically removing the windows disk and "grub-mkconfig" and/or 
>> "update-grub" sorts itself out but is there any way to do this manually 
>> as used to be the case ?
>   
> 
> You can use any of:
> /etc/grub.d/40_custom 
> /etc/grub.d/41_custom
> /boot/grub/custom.cfg
> or 40_custom and/or 41_custom copied e.g. to
> /etc/grub.d/06_custom or /etc/grub.d/07_custom.

From looking at those files, it seems as if they can be used to *add*
entries manually, and your example matches up with doing that - but can
they be used to modify (or remove) entries which would otherwise appear,
as seems to be the desire in this instance? I'm not seeing an obvious
way how, if so.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: grub2 boot menu

[Felix Miata]

mick crane composed on 2021-06-24 14:51 (UTC+0100):

> I was dual booting but got another PC so I can have windows and debain 
> at the same time. Just for tidiness of booting I'd have liked to comment 
> out the submenu entry in /boot/grub/grub.cfg for windows just in case I 
> wanted to put it back but not allowed.
> Physically removing the windows disk and "grub-mkconfig" and/or 
> "update-grub" sorts itself out but is there any way to do this manually 
> as used to be the case ?


You can use any of:
/etc/grub.d/40_custom 
/etc/grub.d/41_custom
/boot/grub/custom.cfg
or 40_custom and/or 41_custom copied e.g. to
/etc/grub.d/06_custom or /etc/grub.d/07_custom.
The actual names in /etc/grub.d/ do not seem to be carved in stone, but
/boot/grub/custom.cfg does seem to be. Within the /etc/grub.d/ hierarchy,
the names affect where the custom entries appear in the boot menu. Before
10 entries are first listed, the 4x entries are shown after the auto-generated
entries. I use custom.cfg, which I populate with the kernel & initrd symlinks
so that need to maintain custom.cfg is minimal.

The custom.cfg entries can be seriously simplified compared to the 
auto-generated
ones. e.g.:

menuentry "Debian 11 Bullseye defkernel" {
search --no-floppy --set=root --hint-baremetal=ahci0,gpt9 --label 
tg1p09deb11
linuxefi/vmlinuz root=LABEL=tg1p09deb11 noresume ipv6.disable=1 
net.ifnames=0 mitigations=auto consoleblank=0 
initrdefi   /initrd.img
}

Note omission of UUIDs and inclusion of volume labels in their place.
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Nicolas George]

David Wright (12021-06-24):
> Only if you'd gone ahead and removed all those other packages.

Not even then. The GRUB packages are useful for installing the GRUB
bootloader. Once it's installed, the computer will boot, and the package
are not necessary, although they might be useful to automatically update
the configuration after upgrades.

Regards,

-- 
  Nicolas George

Re: grub2 boot menu

[Greg Wooledge]

On Thu, Jun 24, 2021 at 02:51:06PM +0100, mick crane wrote:
> I was dual booting but got another PC so I can have windows and debain at
> the same time. Just for tidiness of booting I'd have liked to comment out
> the submenu entry in /boot/grub/grub.cfg for windows just in case I wanted
> to put it back but not allowed.
> Physically removing the windows disk and "grub-mkconfig" and/or
> "update-grub" sorts itself out but is there any way to do this manually as
> used to be the case ?

You want the GRUB menu to skip over Windows?  The easiest way would
probably be to remove the os-prober package, so update-grub never sees
Windows and never includes it in the generated menu.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[David Wright]

On Thu 24 Jun 2021 at 08:49:40 (+0200), Markus wrote:
> Am 23.06.21 um 18:08 schrieb David Wright:
> > On Wed 23 Jun 2021 at 17:01:07 (+0200), Markus wrote:

> > > rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3
> >↑↑ There's your problem. It's been removed (but not purged).

> Ok so...hmmm...I did not remove it myself. I mean why would I want to do
> that?!?! Nevertheless this is an issue now.

Take a look at /var/log/apt/history.log* to see the reason
and/or the occasion (but not necessarily the intent).¹

As an example of how things can happen unintentionally, this
post from Tuesday illustrates where a broken package's bug
report seems to have led to a different package being removed:
https://lists.debian.org/debian-user/2021/06/msg00581.html

> Interestingly when booting my computer this morning grub was there and
> booted into Buster. Shouldn't it be gone if it got removed (even though
> it not got purged)? Hmmm...!?!?

Only if you'd gone ahead and removed all those other packages.
There's actually nothing substantial inside grub-efi-amd64:

$ dpkg -L grub-efi-amd64
/.
/usr
/usr/share
/usr/share/bug
/usr/share/bug/grub-efi-amd64
/usr/share/bug/grub-efi-amd64/presubj
/usr/share/bug/grub-efi-amd64/script
/usr/share/doc
/usr/share/doc/grub-efi-amd64
$ 

> How to fix that? Is there actually something wrong (this morning grub
> was there!!!) that needs to be fixed?
> Is it sa[f]e to just reinstall grub-efi-amd64?

Yes. The package exists for its dependencies. Just reinstall it.
You can then try autoremove again, and its list should now only
include the (presumably third) versions of the kernel packages
that you wanted to remove as a matter of routine, like mine in ¹.

¹ entries in /var/log/apt/history.log look like:

Start-Date: 2021-06-19  17:45:10
Commandline: apt-get --purge autoremove
Purge: linux-headers-4.19.0-14-amd64:amd64 (4.19.171-2), 
linux-headers-4.19.0-14-common:amd64 (4.19.171-2), 
linux-image-4.19.0-14-amd64:amd64 (4.19.171-2)
End-Date: 2021-06-19  17:45:33

Cheers,
David.

grub2 boot menu

[mick crane]

hello,
I was dual booting but got another PC so I can have windows and debain 
at the same time. Just for tidiness of booting I'd have liked to comment 
out the submenu entry in /boot/grub/grub.cfg for windows just in case I 
wanted to put it back but not allowed.
Physically removing the windows disk and "grub-mkconfig" and/or 
"update-grub" sorts itself out but is there any way to do this manually 
as used to be the case ?

mick
--
Key ID4BFEBB31

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Greg Wooledge]

On Thu, Jun 24, 2021 at 08:49:40AM +0200, Markus wrote:
> Ok so...hmmm...I did not remove it myself. I mean why would I want to do
> that?!?! Nevertheless this is an issue now.
> Interestingly when booting my computer this morning grub was there and
> booted into Buster. Shouldn't it be gone if it got removed (even though
> it not got purged)? Hmmm...!?!?

Removing the grub packages doesn't remove GRUB from your hard drive(s).
Thankfully.

> How to fix that? Is there actually something wrong (this morning grub
> was there!!!) that needs to be fixed?
> Is it save to just reinstall grub-efi-amd64?

It should be, as far as I know.  I'm not sure whether this will prompt
you for where to install GRUB, or whether it will retain knowledge of
this from the config files which you say haven't been purged yet.

It'll probably regenerate the grub.cfg menu, though.  If you haven't done
anything too silly, that shouldn't be an issue.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

Ok so...hmmm...I did not remove it myself. I mean why would I want to do
that?!?! Nevertheless this is an issue now.
Interestingly when booting my computer this morning grub was there and
booted into Buster. Shouldn't it be gone if it got removed (even though
it not got purged)? Hmmm...!?!?

How to fix that? Is there actually something wrong (this morning grub
was there!!!) that needs to be fixed?
Is it save to just reinstall grub-efi-amd64?

Cheers
Markus


Am 23.06.21 um 18:08 schrieb David Wright:

On Wed 23 Jun 2021 at 17:01:07 (+0200), Markus wrote:

Am 23.06.21 um 16:43 schrieb David Wright:

Has grub-efi-amd64 been accidentally removed? AIUI that's the package
which depends on having the packages to boot your machine.

No, not that I am aware of. But here is the ouput of

markus@bmtMB1:~$ sudo dpkg -l | grep grub
ii  grub-common 2.02+dfsg1-20+deb10u4
amd64    GRand Unified Bootloader (common files)
rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3

   ↑↑ There's your problem. It's been removed (but not purged).


amd64    GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin 2.02+dfsg1-20+deb10u4
amd64    GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed 1+2.02+dfsg1+20+deb10u4
amd64    GRand Unified Bootloader, version 2 (amd64 UEFI signed by
Debian)
ii  grub-firmware-qemu 2.02+dfsg1-20+deb10u4
amd64    GRUB firmware image for QEMU
ii  grub2-common 2.02+dfsg1-20+deb10u4
amd64    GRand Unified Bootloader (common files for version 2)
markus@bmtMB1:~$

Thanks for posting text.

Cheers,
David.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[David Wright]

On Wed 23 Jun 2021 at 17:01:07 (+0200), Markus wrote:
> Am 23.06.21 um 16:43 schrieb David Wright:
> > Has grub-efi-amd64 been accidentally removed? AIUI that's the package
> > which depends on having the packages to boot your machine.

> No, not that I am aware of. But here is the ouput of
> 
> markus@bmtMB1:~$ sudo dpkg -l | grep grub
> ii  grub-common 2.02+dfsg1-20+deb10u4   
> amd64    GRand Unified Bootloader (common files)
> rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3   

  ↑↑ There's your problem. It's been removed (but not purged).

> amd64    GRand Unified Bootloader, version 2 (EFI-AMD64 version)
> ii  grub-efi-amd64-bin 2.02+dfsg1-20+deb10u4   
> amd64    GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
> ii  grub-efi-amd64-signed 1+2.02+dfsg1+20+deb10u4 
> amd64    GRand Unified Bootloader, version 2 (amd64 UEFI signed by
> Debian)
> ii  grub-firmware-qemu 2.02+dfsg1-20+deb10u4   
> amd64    GRUB firmware image for QEMU
> ii  grub2-common 2.02+dfsg1-20+deb10u4   
> amd64    GRand Unified Bootloader (common files for version 2)
> markus@bmtMB1:~$

Thanks for posting text.

Cheers,
David.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

No, not that I am aware of. But here is the ouput of

markus@bmtMB1:~$ sudo dpkg -l | grep grub
ii  grub-common 2.02+dfsg1-20+deb10u4   
amd64    GRand Unified Bootloader (common files)
rc  grub-efi-amd64 2.02+dfsg1-20+deb10u3   
amd64    GRand Unified Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin 2.02+dfsg1-20+deb10u4   
amd64    GRand Unified Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed 1+2.02+dfsg1+20+deb10u4 
amd64    GRand Unified Bootloader, version 2 (amd64 UEFI signed by
Debian)
ii  grub-firmware-qemu 2.02+dfsg1-20+deb10u4   
amd64    GRUB firmware image for QEMU
ii  grub2-common 2.02+dfsg1-20+deb10u4   
amd64    GRand Unified Bootloader (common files for version 2)
markus@bmtMB1:~$

Cheers
Markus


Am 23.06.21 um 16:43 schrieb David Wright:

Please post as text, not *just* html.

On Wed 23 Jun 2021 at 15:55:04 (+0200), Markus wrote:


   

 
   
   
 Hi, just before and also after today's "apt full-upgrade" apt tells
 me that:
 
 The following packages were automatically installed and are no longer 
required:
efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
shim-signed-common
shim-unsigned


 I don't have a good feeling when I see that it allows me to remove 
 "efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common"
 
 
 
 What is wrong here? I am on Buster and used kernel
 5.10.0-0.bpo.5-amd64. With today's
 
 full-upgrade 5.10.0-0.bpo.7-amd64 came in.

Has grub-efi-amd64 been accidentally removed? AIUI that's the package
which depends on having the packages to boot your machine.

Cheers,
David.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[David Wright]

Please post as text, not *just* html.

On Wed 23 Jun 2021 at 15:55:04 (+0200), Markus wrote:
> 
>   
> 
> 
>   
>   
> Hi, just before and also after today's "apt full-upgrade" apt tells
> me that:
> 
> The following packages were automatically installed and are no 
> longer required:
> efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
> libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
> libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
> libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
> linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
> linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
> shim-signed-common
> shim-unsigned
> 
> 
> I don't have a good feeling when I see that it allows me to remove 
> "efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common"
> 
> 
> 
> What is wrong here? I am on Buster and used kernel
> 5.10.0-0.bpo.5-amd64. With today's
> 
> full-upgrade 5.10.0-0.bpo.7-amd64 came in.

Has grub-efi-amd64 been accidentally removed? AIUI that's the package
which depends on having the packages to boot your machine.

Cheers,
David.

Re: apt tells me that grub-efi, grub2-common are no longer needed

[Greg Wooledge]

On Wed, Jun 23, 2021 at 03:55:04PM +0200, Markus wrote:
>Hi, just before and also after today's "apt full-upgrade" apt tells me
>that:
> The following packages were automatically installed and are no longer 
> required:
> efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
> libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
> libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
> libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
> linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
> linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
> shim-signed-common
> shim-unsigned

This may not be helpful for you, but this is *exactly* the kind of thing
that led me to turning off apt's autoremove feature.  In my experience, it
does more harm than good.

I did it by marking every package as "never-autoremove", by creating the
following one-line text file:

unicorn:~$ cat /etc/apt/apt.conf.d/99local 
APT::NeverAutoRemove ".";

There may be other ways to do it.

If you don't like that solution, which I'll admit is not for everyone,
my best advice would be to pick whichever package(s) in the above output
you care about, and mark them as manually installed, using apt-mark(8).

apt tells me that grub-efi, grub2-common are no longer needed

[Markus]

  
  
Hi, just before and also after today's "apt full-upgrade" apt tells
me that:

The following packages were automatically installed and are no longer required:
efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common
libappindicator3-1 libcanberra-gtk3-0 libcanberra-gtk3-module
libclutter-gtk-1.0-0 libdbusmenu-glib4 libdbusmenu-gtk3-4 libindicator3-7
libupsclient4 linux-headers-5.10.0-0.bpo.4-amd64
linux-headers-5.10.0-0.bpo.4-common linux-image-5.10.0-0.bpo.4-amd64
linux-kbuild-4.19 linux-kbuild-5.9 mokutil shim-helpers-amd64-signed
shim-signed-common
shim-unsigned


I don't have a good feeling when I see that it allows me to remove 
"efibootmgr grub-efi-amd64-bin grub-efi-amd64-signed grub2-common"



What is wrong here? I am on Buster and used kernel
5.10.0-0.bpo.5-amd64. With today's

full-upgrade 5.10.0-0.bpo.7-amd64 came in.


Cheers
  

Re: Re : Installer windows 8.1 à partir de son image iso sur une clé usb avec grub2 ?

[toto]

Merci pour les réponses.

Je vais regarder tout cela ce soir.



--
Sent from: http://debian.2.n7.nabble.com/debian-user-french-f1152225.html

Re : Installer windows 8.1 à partir de son image iso sur une clé usb avec grub2 ?

[k6dedijon]

Bonjour,
Tu peux aller voir :
https://doc.ubuntu-fr.org/tutoriel/grub2_lancer_des_images_iso
Il y a pas mal d'informations.
Cassis



- Mail d'origine -
De: toto 
À: debian-user-french@lists.debian.org
Envoyé: Sun, 07 Jul 2019 07:46:07 +0200 (CEST)
Objet: Installer windows 8.1 à partir de son image iso sur une clé usb avec 
grub2 ?

Bonjour à tous !

Je souhaite aujourd'hui installer windows 8.1 puis debian stretch 9.9.0 sur
un disque dur (table de partition GPT et bios UEFI) en amorçant mon pc
portable avec une clé multiboot sur laquelle il y grub2 et les images iso de
ces 2 os.

Que dois je mettre dans mon fichier grub.cfg ?

Voilà un début :

===debut grub.cfg===

menuentry 'windows 8.1 64 bits' {
iso=/boot/win8_1.iso
loopback loop $iso
ntldr (loop)/bootmgr
boot
}
menuentry 'hdMedia' {
linux /boot/hdMedia/vmlinuz
initrd /boot/hdMedia/initrd.gz
}

fin grub.cfg===

Les images iso se trouvent dans le répertoire /boot de la clé usb :

/boot/win8_1.iso
/boot/firmware-9.9.0-amd64-DVD-1.iso

Si quelqu'un a une expérience pratique de la chose qu'elle n'hésite pas à
corriger mon fichier grub.cfg sinon si elle a des adresses internet parlant
très bien du sujet j'irai voir cela aujjourd'hui pour réaliser ma clé
multiboot.

Merci d'avance pour les réponses. 



--
Sent from: http://debian.2.n7.nabble.com/debian-user-french-f1152225.html

Re: Installer windows 8.1 à partir de son image iso sur une clé usb avec grub2 ?

[Pascal Hambourg]

Le 07/07/2019 à 13:54, didier gaumet a écrit :

Le 07/07/2019 à 07:46, toto a écrit :


Je souhaite aujourd'hui installer windows 8.1 puis debian stretch 9.9.0 sur
un disque dur (table de partition GPT et bios UEFI) en amorçant mon pc
portable avec une clé multiboot sur laquelle il y grub2 et les images iso de
ces 2 os.

Que dois je mettre dans mon fichier grub.cfg ?

Voilà un début :

===debut grub.cfg===

menuentry 'windows 8.1 64 bits' {
 iso=/boot/win8_1.iso
 loopback loop $iso
 ntldr (loop)/bootmgr


Marchera pas. La commande ntldr n'est disponible qu'en mode BIOS.


 boot
}


Inutile, c'est implicite dans les entrées de menu.


menuentry 'hdMedia' {
 linux /boot/hdMedia/vmlinuz
 initrd /boot/hdMedia/initrd.gz
}

fin grub.cfg===

Les images iso se trouvent dans le répertoire /boot de la clé usb :

/boot/win8_1.iso
/boot/firmware-9.9.0-amd64-DVD-1.iso

(...)

- pour lancer l'installateur Debian, tu peux à mon sens détruire ton
entrée Grub "hdmedia" et la remplacer par une entrée du style de
SystemrescueCD en chainload ISO dans ce tutoriel du wiki Gentoo:


Ta suggestion a un léger problème : l'initrd.gz pour "cdrom" inclus dans 
les images ISO hybrides d'installation officielles n'est pas capable de 
monter une image disque, et je suppose qu'il en est de même avec les 
images non officielles incluant les firmwares non libres. Certes 
l'installateur se lancera mais il échouera à l'étape "détecter et monter 
un CD-ROM". C'est pourquoi toto a utilisé à juste titre l'initrd.gz pour 
"hd-media" qui peut monter une image disque. En revanche l'image du 
noyau vmlinuz est identique.

Re: Installer windows 8.1 à partir de son image iso sur une clé usb avec grub2 ?

[didier gaumet]

Le 07/07/2019 à 07:46, toto a écrit :
> Bonjour à tous !
> 
> Je souhaite aujourd'hui installer windows 8.1 puis debian stretch 9.9.0 sur
> un disque dur (table de partition GPT et bios UEFI) en amorçant mon pc
> portable avec une clé multiboot sur laquelle il y grub2 et les images iso de
> ces 2 os.
> 
> Que dois je mettre dans mon fichier grub.cfg ?
> 
> Voilà un début :
> 
> ===debut grub.cfg===
> 
> menuentry 'windows 8.1 64 bits' {
> iso=/boot/win8_1.iso
> loopback loop $iso
> ntldr (loop)/bootmgr
> boot
> }
> menuentry 'hdMedia' {
> linux /boot/hdMedia/vmlinuz
> initrd /boot/hdMedia/initrd.gz
> }
> 
> fin grub.cfg===
> 
> Les images iso se trouvent dans le répertoire /boot de la clé usb :
> 
> /boot/win8_1.iso
> /boot/firmware-9.9.0-amd64-DVD-1.iso
> 
> Si quelqu'un a une expérience pratique de la chose qu'elle n'hésite pas à
> corriger mon fichier grub.cfg sinon si elle a des adresses internet parlant
> très bien du sujet j'irai voir cela aujjourd'hui pour réaliser ma clé
> multiboot.

Alors je ne pense pas être très instruit sur le sujet mais à mon avis
pour installer en dual-boot Windows 8.1 et Debian, le plus simple et
efficace -de loin- serait de créer deux supports d'installation séparés
Windows et Debian:

- l'image iso Windows 8.1 n'est pas hybride à ma connaissance. Donc soit
on télécharge l'iso pour la graver sur un DVD, soit on utilise l'outil
Windows dédié pour. Le téléchargement officiel et plus d'infos sur la
manip pour créer une clé USB ici:
  https://www.microsoft.com/fr-fr/software-download/windows8ISO

- inversement les images Debian sont hybrides donc tu peux les graver
sur CD.DVD ou directement créer une clé USB.

- pour fixer la valeur d'une variable dans grub.cfg il faut semble-t-il
utiliser set.

- pour lancer l'installateur Debian, tu peux à mon sens détruire ton
entrée Grub "hdmedia" et la remplacer par une entrée du style de
SystemrescueCD en chainload ISO dans ce tutoriel du wiki Gentoo:
 https://wiki.gentoo.org/wiki/GRUB2/Chainloading
mais en inspectant préalablement le contenu de ton image ISO Debian pour
modifier le lignes linux et initrd

Installer windows 8.1 à partir de son image iso sur une clé usb avec grub2 ?

[toto]

Bonjour à tous !

Je souhaite aujourd'hui installer windows 8.1 puis debian stretch 9.9.0 sur
un disque dur (table de partition GPT et bios UEFI) en amorçant mon pc
portable avec une clé multiboot sur laquelle il y grub2 et les images iso de
ces 2 os.

Que dois je mettre dans mon fichier grub.cfg ?

Voilà un début :

===debut grub.cfg===

menuentry 'windows 8.1 64 bits' {
iso=/boot/win8_1.iso
loopback loop $iso
ntldr (loop)/bootmgr
boot
}
menuentry 'hdMedia' {
linux /boot/hdMedia/vmlinuz
initrd /boot/hdMedia/initrd.gz
}

fin grub.cfg===

Les images iso se trouvent dans le répertoire /boot de la clé usb :

/boot/win8_1.iso
/boot/firmware-9.9.0-amd64-DVD-1.iso

Si quelqu'un a une expérience pratique de la chose qu'elle n'hésite pas à
corriger mon fichier grub.cfg sinon si elle a des adresses internet parlant
très bien du sujet j'irai voir cela aujjourd'hui pour réaliser ma clé
multiboot.

Merci d'avance pour les réponses. 



--
Sent from: http://debian.2.n7.nabble.com/debian-user-french-f1152225.html

Re: update-grub2 et /dev/sda : résolus

[Stephane Ascoet]

Le 20/01/2018 à 18:54, andre_deb...@numericable.fr a écrit :


As tu vraiment lu mon mail avant ta réponse ?
Il n'y a vraiment rien eu "d'insupportable" de ma part,


Bonjour, chacun son niveau de tolerance. Tu ne vois pas le probleme dans 
le fait de nous traiter comme des agents de support tout le temps 
disponible pour lire entre les lignes de ce que tu daignes devoiler et 
pour t'aider alors que tu ne reponds qu'a les questions que tu 
souhaites, mets plus de volonte a faire tes bidouilles car comprendre et 
appliquer ce qu'on t'explique et n'indiques pas exactement toutes les 
manipulations que tu fais en parallele. Moi si, ce n'est pas la 
conception que j'ai de cette liste d'entraide.




/dev/sda était bien remis avant de lancer update-grub2, ça ne vient pas de là.


Je ne dis pas le contraire.




L'essentiel est que l'action réussisse :

Tu compares des choses que ne le sont pas vraiment :

Quelle est cette facheuse erreur de comparaison ?


Ben te sortir d'une tempete sans respecter les regles theoriques n'aura 
d'impact que sur toi et sur le moment. Si tu casses ton spi, tu devras 
te debrouiller pour le remplacer... Mettre des rustines sur un systeme 
informatique va peut-etre te sembler resoudre le probleme en apparence, 
mais va peut-etre creer un mic-mac en dessous qui lancera une bombe a 
retardement.


/dev/sda est brusquement devenu /dev/sdc : c'est anormal.


Si c'est normal car ce disque a toujours ete "/dev/sdc", un co-listier 
avait retrouve un message de l'ete dernier dans lequel tu disais deja 
que ca t'embetait et que tu avais trouve une rustine pour le faire 
devenir "/dev/sda". Et oh surprise, un trimestre plus tard, la 
rustine(dont tu ne te souviens plus en quoi elle consistais) n'agit plus...




J'aurais préféré réussir par la méthode de la conformité,
mais elle n'a jamais voulu fonctionner.

J'ai deja assez exprime mon desaccord la-dessus, mais on ne changera pas 
ta facon de fonctionner et de communiquer. Tant mieux si tu trouves 
encore de bonnes ames pour t'aider, c'est juste que je n'en ferai pas 
partie.


--
Cordialement, Stephane Ascoet

Re: update-grub2 et /dev/sda : résolus

[andre_debian]

On Wednesday 17 January 2018 09:53:33 S. Ascoet wrote:
> Bonjour, non, je n'ai rien contre toi. C'est juste que tu ne respectes 
> pas les bonnes regles pour poser des questions ce qui cree de la 
> confusion et fait perdre bien du temps a tourner en rond pour qu'au 
> final tu n'en fasses qu'a ta tete et surtout en ne l'assumant pas, c'est 
> ca le plus insupportable :

As tu vraiment lu mon mail avant ta réponse ?
Il n'y a vraiment rien eu "d'insupportable" de ma part,
surtout si tu daignes maintenant lire mon mail ci-dessous :

> Bien sur, Grub intervient alors que /dev n'existe meme pas encore :

/dev/sda était bien remis avant de lancer update-grub2, ça ne vient pas de là.

> > Les membres de l'association retrouvent un serveur bien fonctionnel :
> Qui ne serait peut-etre jamais tombe en panne si tu n'avais pas 
> l'habitude de toucher a des trucs qui ne doivent pas l'etre, mais comme 
> tu ne nous donnes jamais aucune information sur le pourquoi de ces 
> manipulations... :

Je n'ai rien touché avant la panne, elle s'est manifestée après un reboot.

> > L'essentiel est que l'action réussisse :
> Tu compares des choses que ne le sont pas vraiment :
Quelle est cette facheuse erreur de comparaison ?

Plus sérieux,
DEVICE DU DISQUE DUR :
/dev/sda est brusquement devenu /dev/sdc : c'est anormal.
Ma méthode était peut-être pas trop orthodoxe :
# mv /dev/sdc /dev/sda
après reboot, a remis toutes les 8 partitions du disque dur sur leur 
device /dev/sda1 à /dev/sda8.

GRUB :
#update-grub2
ne me créait pas un fichier "grub.cfg" bootable, car UUID pas respectés.
Je l'ai modifié à la main, en remettant le bon UUID pour chaque partition.
C'est vrai, la méthode est non conforme, puisque au début du fichier grub.cfg,
il est indiqué qu'il ne faut pas le modifier à la mano.

Au reboot, tout refonctionne, grub boote sur sur toutes les partitions Linux,
et #df -h indique bien /dev/sda1.

J'aurais préféré réussir par la méthode de la conformité,
mais elle n'a jamais voulu fonctionner.

André

Re: update-grub2 : résolu mais...

[Pierre L.]

(...)
Ok

Le 19/01/2018 à 22:21, Pascal Hambourg a écrit :
> Dans mon idée, la configuration du GRUB principal indépendant serait
> gérée manuellement et n'aurait besoin d'être modifiée que lorsqu'on
> ajoute ou supprime une distribution. Les noyaux des distributions
> seraient gérés par leurs GRUB respectifs.
>
> Menu de GRUB0 :
> "Linux1" -> GRUB1
> "Linux2" -> GRUB2
> etc. 

Bon, il faudrait que je vois ca de mes yeux vus.
Donc le GRUB0 n'aurait que des liens vers les autres Grub... ok, je
comprend mieux. Je croyais que les lignes de commandes de boot étaient
en lui, tu comprends donc maintenant ma logique qui me disait que ce
n'était pas ultra simple de mettre à jour à chaque fois ce GRUB0 (à la
manière de notre bon vieux Grub en solo habituel).



signature.asc
Description: OpenPGP digital signature

Re: update-grub2 : résolu mais...

[Pascal Hambourg]

Le 19/01/2018 à 09:51, Pierre L. a écrit :


Le 18/01/2018 à 23:43, Pascal Hambourg a écrit :

Le 18/01/2018 à 23:14, Pierre L. a écrit :



Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB
par exemple, et n'utiliser que cette clé comme périph' de boot ?

(...)

Mais pourquoi sur une clé USB plutôt que sur un disque interne ?

Pourquoi pas ? ;)


Eh, c'est toi qui a demandé si ça ne valait pas le coup. Tu
sous-entends donc que ça aurait un intérêt. Je n'ai pas dit que ça
avait un inconvénient. Je dis juste que je ne vois pas l'intérêt.


On donne l'ordre aux distribs d'installer Grub dans /dev/sda qui est mon
seul HDD. Donc systématiquement ces distribs écraseront Grub présent au
boot de /dev/sda, non ?
Sinon oui, l'intérêt d'avoir une clé, serait d'éviter les conflits de
Grub (généré par les distribs) sur ce même disque dur, et ainsi
extérioriser Grub dans un /dev/sdb


Il suffit de leur donner l'ordre d'installer GRUB ailleurs pour éviter 
les conflits, et pas besoin de clé USB.



Pour ma part, je serais plutôt partisan d'un GRUB principal
indépendant qui chaînerait les GRUB des différentes distributions.

(...)

Dans mon exemple, appelons Grub0 celui
qui est principal, le fameux indépendant.
Mes distribs seront Linux1, Linux2, etc. qui auront chacune leur Grub1,
Grub2, etc.

Linux1 obtient un nouveau kernel via ses mises à jour, donc son Grub1
"personnel" sera mis à jour comme d'hab.


Jusqu'ici, ça va.


De plus, Linux1 mettra à jour
AUSSI le principal Grub0 dans la foulée (c'est une supposition, jamais
testé),


Et comment diable ferait-il cela ?


car si Grub0 n'est plus à jour, sa référence vers Linux1 sera erronée.


Le chaînage éviterait de devoir modifier le GRUB principal.


Idem avec un Linux2 qui obtiendrait un nouveau kernel une semaine plus
tard... qui mettrait à jour son Grub2 + Grub0
Etc. Linux3 -> Grub3 + Grub0

Bref, tout le monde pourrait effectivement générer ce Grub0 principal.
(principe erroné ?)


Dans le principe, pourquoi pas. Mais concrètement, comment fais-tu ça ?


J'ai souvenir d'avoir utilisé des outils comme SuperGrub il y a un
certain temps, tu penserais alors à ce genre de truc ? (qui si je me
souviens bien, permettait de booter les distribs présentes sur les
disques d'une machine, dans laquelle le programme de boot avait été
corrompu ou effacé, une roue de secours pour booter tes systèmes Linux
et autres windows...)


Je n'ai jamais utilisé ce genre d'outil que je ne connais que de nom.

Dans mon idée, la configuration du GRUB principal indépendant serait 
gérée manuellement et n'aurait besoin d'être modifiée que lorsqu'on 
ajoute ou supprime une distribution. Les noyaux des distributions 
seraient gérés par leurs GRUB respectifs.


Menu de GRUB0 :
"Linux1" -> GRUB1
"Linux2" -> GRUB2
etc.

Re: update-grub2 : résolu mais...

[Pierre L.]

Le 18/01/2018 à 23:43, Pascal Hambourg a écrit :
> Le 18/01/2018 à 23:14, Pierre L. a écrit :
>>
>> Le 18/01/2018 à 22:19, Pascal Hambourg a écrit :
>>> Le 18/01/2018 à 20:36, Pierre L. a écrit :
>>>>
>>>> Le 18/01/2018 à 20:09, Pascal Hambourg a écrit :
>>>>> Le 18/01/2018 à 14:04, Pierre L. a écrit :
>>>>>> Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB
>>>>>> par
>>>>>> exemple, et n'utiliser que cette clé comme périph' de boot ?
>>>>>
>>>>> Dans quel intérêt ? Je n'en vois aucun.
>>>>
>>>> 1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air
>>>> d'être le cas... On centralise...
>>>
>>> Mais pourquoi sur une clé USB plutôt que sur un disque interne ?
>> Pourquoi pas ? ;)
>
> Eh, c'est toi qui a demandé si ça ne valait pas le coup. Tu
> sous-entends donc que ça aurait un intérêt. Je n'ai pas dit que ça
> avait un inconvénient. Je dis juste que je ne vois pas l'intérêt.
On donne l'ordre aux distribs d'installer Grub dans /dev/sda qui est mon
seul HDD. Donc systématiquement ces distribs écraseront Grub présent au
boot de /dev/sda, non ?
Sinon oui, l'intérêt d'avoir une clé, serait d'éviter les conflits de
Grub (généré par les distribs) sur ce même disque dur, et ainsi
extérioriser Grub dans un /dev/sdb


>
>>> Pour ma part, je serais plutôt partisan d'un GRUB principal
>>> indépendant qui chaînerait les GRUB des différentes distributions.
>>>
>> Ce fameux "GRUB principal indépendant" pourrait alors être généré par
>> chacune des distribs,
>
> Ben non, sinon il ne serait pas indépendant.
Il le pourrait (être indépendant et généré par tous), car généré à
chaque fois que c'est nécessaire. Dans mon exemple, appelons Grub0 celui
qui est principal, le fameux indépendant.
Mes distribs seront Linux1, Linux2, etc. qui auront chacune leur Grub1,
Grub2, etc.

Linux1 obtient un nouveau kernel via ses mises à jour, donc son Grub1
"personnel" sera mis à jour comme d'hab. De plus, Linux1 mettra à jour
AUSSI le principal Grub0 dans la foulée (c'est une supposition, jamais
testé), car si Grub0 n'est plus à jour, sa référence vers Linux1 sera
erronée.
Idem avec un Linux2 qui obtiendrait un nouveau kernel une semaine plus
tard... qui mettrait à jour son Grub2 + Grub0
Etc. Linux3 -> Grub3 + Grub0

Bref, tout le monde pourrait effectivement générer ce Grub0 principal.
(principe erroné ?)
(j'espère avoir été précis dans l'exposition de mes pensées ! )

>
>> dès lors que la distrib irait lire chaque grub.cfg
>> dans la machine, mais alors en reprenant la précédente citation, il
>> faudrait alors qu'une seule distrib gère ce GRUB principal ?
>
> C'est une autre possibilité, qui correspond à ce que j'ai répondu à
> André. Mais ce n'est pas un GRUB indépendant, c'est le GRUB d'une
> distribution qui récupère et inclut les paramètres des autres dans sa
> config.
>
Mais alors, si c'est un Grub d'une distrib et qu'il n'est plus
indépendant, c'est le serpent qui se mord la queue :)
J'ai souvenir d'avoir utilisé des outils comme SuperGrub il y a un
certain temps, tu penserais alors à ce genre de truc ? (qui si je me
souviens bien, permettait de booter les distribs présentes sur les
disques d'une machine, dans laquelle le programme de boot avait été
corrompu ou effacé, une roue de secours pour booter tes systèmes Linux
et autres windows...)



signature.asc
Description: OpenPGP digital signature

Re: update-grub2 : résolu mais...

[Pascal Hambourg]

Le 18/01/2018 à 23:14, Pierre L. a écrit :


Le 18/01/2018 à 22:19, Pascal Hambourg a écrit :

Le 18/01/2018 à 20:36, Pierre L. a écrit :


Le 18/01/2018 à 20:09, Pascal Hambourg a écrit :

Le 18/01/2018 à 14:04, Pierre L. a écrit :

Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par
exemple, et n'utiliser que cette clé comme périph' de boot ?


Dans quel intérêt ? Je n'en vois aucun.


1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air
d'être le cas... On centralise...


Mais pourquoi sur une clé USB plutôt que sur un disque interne ?

Pourquoi pas ? ;)


Eh, c'est toi qui a demandé si ça ne valait pas le coup. Tu sous-entends 
donc que ça aurait un intérêt. Je n'ai pas dit que ça avait un 
inconvénient. Je dis juste que je ne vois pas l'intérêt.



Pour ma part, je serais plutôt partisan d'un GRUB principal
indépendant qui chaînerait les GRUB des différentes distributions.


Ce fameux "GRUB principal indépendant" pourrait alors être généré par
chacune des distribs,


Ben non, sinon il ne serait pas indépendant.


dès lors que la distrib irait lire chaque grub.cfg
dans la machine, mais alors en reprenant la précédente citation, il
faudrait alors qu'une seule distrib gère ce GRUB principal ?


C'est une autre possibilité, qui correspond à ce que j'ai répondu à 
André. Mais ce n'est pas un GRUB indépendant, c'est le GRUB d'une 
distribution qui récupère et inclut les paramètres des autres dans sa 
config.

Re: update-grub2 : résolu mais...

[Pierre L.]

Le 18/01/2018 à 22:19, Pascal Hambourg a écrit :
> Le 18/01/2018 à 20:36, Pierre L. a écrit :
>>
>> Le 18/01/2018 à 20:09, Pascal Hambourg a écrit :
>>> Le 18/01/2018 à 14:04, Pierre L. a écrit :
>>>> Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par
>>>> exemple, et n'utiliser que cette clé comme périph' de boot ?
>>>
>>> Dans quel intérêt ? Je n'en vois aucun.
>>
>> 1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air
>> d'être le cas... On centralise...
>
> Mais pourquoi sur une clé USB plutôt que sur un disque interne ?
Pourquoi pas ? ;)

>
>>>> Les différentes distrib iront regarder sur tout le système là où il
>>>> y a
>>>> moyen de booter non ?
>>>
>>> Peux-tu préciser ? Je ne vois pas de quoi tu parles.
>
> Pas de réponse ?
C'était une question...
Désolé de ne pouvoir trouver meilleurs termes plus explicites, techniques...

>
>>>> Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ?
>>>
>>> Sûrement pas. Une distribution ne met à jour que son propre GRUB.
>>
>> On rejoint ma précédente pensée, chaque distribution pourrait actualiser
>> le seul Grub de la machine présent sur la clé USB, car j'imagine que
>> Grub2 est normalisé ?
>
> Pas tant que ça. Il y a de légères différences entre différentes
> versions de GRUB Et c'est AMA une mauvaise idée car chaque
> distribution ne ferait pas que réactualiser le fichier de
> configuration mais le réécrirait complètement, en se mettant en
> première position bien évidemment. D'autre part il vaut mieux que
> chaque distribution garde son propre GRUB avec son propre fichier
> grub.cfg avec ses paramètres de démarrage spécifiques car update-grub
> se sert du fichier grub.cfg des autres distributions détectées par
> os-prober pour récupérer et intégrer lesdits paramètres de démarrage
> dans le fichier grub.cfg qu'il construit.
>
Ok c'est donc de cette manière que Grub fonctionne, interesting.
A partir de ces infos, je comprends mieux la suite.

> Pour ma part, je serais plutôt partisan d'un GRUB principal
> indépendant qui chaînerait les GRUB des différentes distributions.
>
Ce fameux "GRUB principal indépendant" pourrait alors être généré par
chacune des distribs, dès lors que la distrib irait lire chaque grub.cfg
dans la machine, mais alors en reprenant la précédente citation, il
faudrait alors qu'une seule distrib gère ce GRUB principal ? (evitant :
"chaque distribution ne ferait pas que réactualiser le fichier de
configuration mais le réécrirait complètement, en se mettant en première
position bien évidemment")



signature.asc
Description: OpenPGP digital signature

Re: update-grub2 : résolu mais...

[Pascal Hambourg]

Le 18/01/2018 à 20:36, Pierre L. a écrit :


Le 18/01/2018 à 20:09, Pascal Hambourg a écrit :

Le 18/01/2018 à 14:04, Pierre L. a écrit :

Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par
exemple, et n'utiliser que cette clé comme périph' de boot ?


Dans quel intérêt ? Je n'en vois aucun.


1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air
d'être le cas... On centralise...


Mais pourquoi sur une clé USB plutôt que sur un disque interne ?


Les différentes distrib iront regarder sur tout le système là où il y a
moyen de booter non ?


Peux-tu préciser ? Je ne vois pas de quoi tu parles.


Pas de réponse ?


Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ?


Sûrement pas. Une distribution ne met à jour que son propre GRUB.


On rejoint ma précédente pensée, chaque distribution pourrait actualiser
le seul Grub de la machine présent sur la clé USB, car j'imagine que
Grub2 est normalisé ?


Pas tant que ça. Il y a de légères différences entre différentes 
versions de GRUB Et c'est AMA une mauvaise idée car chaque distribution 
ne ferait pas que réactualiser le fichier de configuration mais le 
réécrirait complètement, en se mettant en première position bien 
évidemment. D'autre part il vaut mieux que chaque distribution garde son 
propre GRUB avec son propre fichier grub.cfg avec ses paramètres de 
démarrage spécifiques car update-grub se sert du fichier grub.cfg des 
autres distributions détectées par os-prober pour récupérer et intégrer 
lesdits paramètres de démarrage dans le fichier grub.cfg qu'il construit.


Pour ma part, je serais plutôt partisan d'un GRUB principal indépendant 
qui chaînerait les GRUB des différentes distributions.

Re: update-grub2 : résolu mais...

[Pierre L.]

Le 18/01/2018 à 20:09, Pascal Hambourg a écrit :
> Le 18/01/2018 à 14:04, Pierre L. a écrit :
>> Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par
>> exemple, et n'utiliser que cette clé comme périph' de boot ?
>
> Dans quel intérêt ? Je n'en vois aucun.
1 seul Grub plutôt que d'avoir 50 fichiers à gérer comme ca a l'air
d'être le cas... On centralise...
Pour mémo, plus haut dans le fil :

"J'ai recopié le répertoire /boot/grub sur toutes les partitions Linux."


>
>> Les différentes distrib iront regarder sur tout le système là où il y a
>> moyen de booter non ?
>
> Peux-tu préciser ? Je ne vois pas de quoi tu parles.
>
>> Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ?
>
> Sûrement pas. Une distribution ne met à jour que son propre GRUB.
On rejoint ma précédente pensée, chaque distribution pourrait actualiser
le seul Grub de la machine présent sur la clé USB, car j'imagine que
Grub2 est normalisé ?



signature.asc
Description: OpenPGP digital signature

Re: update-grub2 : résolu mais...

[Pascal Hambourg]

Le 18/01/2018 à 14:04, Pierre L. a écrit :

Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par
exemple, et n'utiliser que cette clé comme périph' de boot ?


Dans quel intérêt ? Je n'en vois aucun.


Les différentes distrib iront regarder sur tout le système là où il y a
moyen de booter non ?


Peux-tu préciser ? Je ne vois pas de quoi tu parles.


Et donc mettre à jour ce Grub à chaque fois que ce sera nécessaire ?


Sûrement pas. Une distribution ne met à jour que son propre GRUB.

Re: update-grub2 : résolu mais...

[Pierre L.]

Ca ne vaudrait pas le coup d'avoir qu'1 seul Grub sur une clé USB par
exemple, et n'utiliser que cette clé comme périph' de boot ?

Les différentes distrib iront regarder sur tout le système là où il y a
moyen de booter non ? Et donc mettre à jour ce Grub à chaque fois que ce
sera nécessaire ?



signature.asc
Description: OpenPGP digital signature

Re: update-grub2 : résolu

[Haricophile]

Le Wed, 17 Jan 2018 20:52:20 +0100,
Pascal Hambourg  a écrit :

> Le 17/01/2018 à 09:53, Stephane Ascoet a écrit :
> [au sujet de l'utilité d'un swap]
> > Le 16/01/2018 à 20:25, Pascal Hambourg a écrit :  
> >  > Ou simplement utiliser l'hibernation (suspend to disk).  
> > 
> > Je fuis ce truc qui est juste bon a foutre en l'air le mecanisme 
> > d'amorcage en cas de loupe  
> 
> Source ou exemple ?

pratique personnelle, je ne lui donne pas tort. Je veux dire par la que
la "fiabilité" aléatoire de cet engin peut causer des petites
tracasseries équivalent à un arrêt brutal ce qui n'est pas très cool
quand on compte sur lui pour sauver le travail en cours, ou au moins
se planter pour la restauration de l'état de la machine.
 
> > pour un apport fonctionnel fort faible voire nefaste.  
> 
> Ce n'est pas l'avis de tout le monde. Chacun ses besoins.

Je suis d'accord aussi, chacun ses besoin, ceci étant il y a quand
même des machine plus ou moins fiable sur ce sujet, je suppose en
fonction de , pardon, de l'ACPI qui est un peu usine a gaz pas
très normalisée dans son genre selon les fabricants. C'est pas comme si
le hardware était libre...

Re: update-grub2 : résolu mais...

[Pascal Hambourg]

Le 15/01/2018 à 23:52, andre_deb...@numericable.fr a écrit :


Par contre, je trouve le fichier "/boot/grub/grub.cfg" très volumineux (142Ko
et 2.771 lignes), et les partitions de /dev/sda2 à sda7 n'ont pas toujours
leur bon UUID.
Exemple :
$menuentry_id_option 
'osprober-gnulinux-/boot/vmlinuz-4.4.0-109-generic-root=UUID=3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8
ro single-6af32adf-87c5-4c3f-b390-9727185169ef' ...

Dans un même menuentry /dev/sda5, deux UUID différents :
3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8 = /dev/sda1
6af32adf-87c5-4c3f-b390-9727185169ef = /dev/sda5


Ce genre de chose peut arriver quand il y plusieurs systèmes installés 
avec chacun leur GRUB qui détecte tous les autres. Lors de la génération 
de grub.cfg les fichiers grub.cfg des autres systèmes détectés sont lus 
pour les intégrer. Une solution consiste à désactiver l'utilisation 
d'os-prober par GRUB dans les systèmes qui n'ont pas le GRUB actif et 
exécuter update-grub sur tous les systèmes en finissant par celui qui a 
le GRUB actif.

Re: update-grub2 : résolu

[Pascal Hambourg]

Le 17/01/2018 à 09:53, Stephane Ascoet a écrit :
[au sujet de l'utilité d'un swap]

Le 16/01/2018 à 20:25, Pascal Hambourg a écrit :
 > Ou simplement utiliser l'hibernation (suspend to disk).

Je fuis ce truc qui est juste bon a foutre en l'air le mecanisme 
d'amorcage en cas de loupe


Source ou exemple ?


pour un apport fonctionnel fort faible voire nefaste.


Ce n'est pas l'avis de tout le monde. Chacun ses besoins.

Re: update-grub2 : résolu

[Stephane Ascoet]

Le 16/01/2018 à 13:32, andre_deb...@numericable.fr a écrit :


Humm, ici le "cordialement" est de trop.

> Je ne t'ai rien demandé personnellement,
> je n'ai vraiment pas besoin de tes réflexions,

Bonjour, non, je n'ai rien contre toi. C'est juste que tu ne respectes 
pas les bonnes regles pour poser des questions ce qui cree de la 
confusion et fait perdre bien du temps a tourner en rond pour qu'au 
final tu n'en fasses qu'a ta tete et surtout en ne l'assumant pas, c'est 
ca le plus insupportable.



Oui, c'est bien mon serveur, le problème ne vient pas du tout
de "/dev/sdc ou /dev/sda", avant de poster j'ai évidemment testé,
avec les 2 devices en sda et sdc, même réponse de Grub.


Bien sur, Grub intervient alors que /dev n'existe meme pas encore.



Les membres de l'association retrouvent un serveur bien fonctionnel.


Qui ne serait peut-etre jamais tombe en panne si tu n'avais pas 
l'habitude de toucher a des trucs qui ne doivent pas l'etre, mais comme 
tu ne nous donnes jamais aucune information sur le pourquoi de ces 
manipulations...



L'essentiel est que l'action réussisse.


Tu compares des choses que ne le sont pas vraiment.

Le 16/01/2018 à 20:25, Pascal Hambourg a écrit :
> Ou simplement utiliser l'hibernation (suspend to disk).

Je fuis ce truc qui est juste bon a foutre en l'air le mecanisme 
d'amorcage en cas de loupe pour un apport fonctionnel fort faible voire 
nefaste.


--
Cordialement, Stephane Ascoet

Re: update-grub2

[Pascal Hambourg]

Le 16/01/2018 à 10:22, Stephane Ascoet a écrit :


Mais franchement vu les quantites de RAM des ordinateurs 
actuels, il faut vraiment avoir un usage de folie pour avoir besoin de 
fichier d'echange!!! Ou alors etre un vieux chieur comme moi qui utilise 
des ordinausores


Ou simplement utiliser l'hibernation (suspend to disk).

Re: update-grub2 : résolu

[Daniel Caillibaud]

Le 16/01/18 à 13:32, andre_deb...@numericable.fr a écrit :
AF> "Pire" encore, dans la "non-conformité", j'ai même re-rédigé
AF> le fichier "/boot/grub/grub.cfg" à la mano.

C'est effectivement déconseillé car c'est un fichier généré
automatiquement, ce sont les sources de cette génération qu'il vaut mieux
modifier (dans /etc/grub.d ou /etc/default/grub).

Mais si tu tiens à ta façon de faire, gardes-en une copie car il sera
écrasé à la prochaine màj de grub ou du noyau, ou à la prochaine commande
grub.

-- 
Daniel

Le carré est un triangle qui a réussi, ou une circonférence qui a mal
tourné… 
Pierre Dac

Re: update-grub2 : résolu

[andre_debian]

On Tuesday 16 January 2018 10:22:45 Stephane Ascoet wrote:
> Quant aux problemes d'Andre je n'ai meme pas envie 
> d'y reflechir pour au moins ces raisons:
> -il n'a pas pris la peine de nous faciliter la tache dans sa question 
> sur le renommage de sda en sdb;
> -Il nous repose une question du meme style qui est peut-etre sur la meme 
> machine, sur laquelle il a fait des choses non conformes a un usage 
> normal en depit de nos conseils et revient la tout innocent comme si de 
> rien n'etait et comme si on ne le connaissait pas;
> -Si c'est une autre machine, tiens comme c'est bizarre, le meme genres 
> de problemes... qui viennent peut-etre plutot de ce qui se trouve entre 
> la chaise et le clavier...
> Cordialement, Stephane Ascoet

Humm, ici le "cordialement" est de trop.

Peu importe que ce soit sur un ordinateur perso 
ou un serveur à device (/dev/disque dur) renommé.

Oui, c'est bien mon serveur, le problème ne vient pas du tout
de "/dev/sdc ou /dev/sda", avant de poster j'ai évidemment testé,
avec les 2 devices en sda et sdc, même réponse de Grub.

> Quant aux problemes d'André je n'ai meme pas envie 
> d'y reflechir pour au moins ces raisons...

Je ne t'ai rien demandé personnellement,
je n'ai vraiment pas besoin de tes réflexions,
surtout pour ce type de réponse.
Le problème est résolu à 100%,
Grub refonctionne avec mon disque en /dev/sda.

"Pire" encore, dans la "non-conformité", j'ai même re-rédigé
le fichier "/boot/grub/grub.cfg" à la mano.

Les membres de l'association retrouvent un serveur bien fonctionnel.

Si dans ma vie, j'avais toujours adopté la pensée unique de 
la conformité, je serais resté un chômeur invétéré au RSA.

Dans le domaine de la voile, la conformité dit qu'en cas de tempête,
il faut baisser le foc et jouer avec la grand voile.
J'ai fait exactement le contraire un jour de grand vent,
levé le foc, baissé la grand voile, et j'ai sauvé ma vie.

L'essentiel est que l'action réussisse.

André

Re: update-grub2

[steve]

Le 16-01-2018, à 10:22:45 +0100, Stephane Ascoet a écrit :

[snip]

-il n'a pas pris la peine de nous faciliter la tache dans sa question 
sur le renommage de sda en sdb;
-Il nous repose une question du meme style qui est peut-etre sur la 
meme machine, sur laquelle il a fait des choses non conformes a un 
usage normal en depit de nos conseils et revient la tout innocent 
comme si de rien n'etait et comme si on ne le connaissait pas;


Mais si on le connaît notre André :)

-Si c'est une autre machine, tiens comme c'est bizarre, le meme genres 
de problemes... qui viennent peut-etre plutot de ce qui se trouve 
entre la chaise et le clavier...


Alors même machine ou autre machine ?

Qui ouvre les paris ?


En passant une newz qui lui fera plaisir:

http://www.lemagit.fr/actualites/450433173/Barcelone-veut-son-poste-de-travail-Open-Source

Re: update-grub2

[Stephane Ascoet]

Le 15/01/2018 à 20:25, steve a écrit :


Sous-entendu que la tête passe plus de temps au centre que vers
l'extérieur. Mais est-ce bien le cas ? On pourrait se dire que ce serait


Bonjour, je le fait aussi mais plutot en raison de l'argument comme quoi 
le debit est plus important a l'exterieur qu'a l'interieur(et oui: un 
disque dur commence par l'exterieur, comme un disque microsillon et non 
comme un CD). Mais franchement vu les quantites de RAM des ordinateurs 
actuels, il faut vraiment avoir un usage de folie pour avoir besoin de 
fichier d'echange!!! Ou alors etre un vieux chieur comme moi qui utilise 
des ordinausores :-D Quant aux problemes d'Andre je n'ai meme pas envie 
d'y reflechir pour au moins ces raisons:
-il n'a pas pris la peine de nous faciliter la tache dans sa question 
sur le renommage de sda en sdb;
-Il nous repose une question du meme style qui est peut-etre sur la meme 
machine, sur laquelle il a fait des choses non conformes a un usage 
normal en depit de nos conseils et revient la tout innocent comme si de 
rien n'etait et comme si on ne le connaissait pas;
-Si c'est une autre machine, tiens comme c'est bizarre, le meme genres 
de problemes... qui viennent peut-etre plutot de ce qui se trouve entre 
la chaise et le clavier...

--
Cordialement, Stephane Ascoet

Re: update-grub2 : résolu mais...

[andre_debian]

On Sunday 14 January 2018 19:37:35 Haricophile wrote:
> Le Sun, 14 Jan 2018 19:00:16 +0100, andre_deb...@numericable.fr a écrit :
> > Grub semble trouver la partition n° 1 (racine)
> > mais pas /dev/sda2... et les autres.
> > Comment créer le menu Grub avec toutes les partitions citées ?
> > (création de grub.cfg)

Grub semble réparé.
J'ai recopié le répertoire /boot/grub sur toutes les partitions Linux.
il détecte maintenant toutes les partitions rapidement de sda1 à sda7.

Par contre, je trouve le fichier "/boot/grub/grub.cfg" très volumineux (142Ko 
et 2.771 lignes), et les partitions de /dev/sda2 à sda7 n'ont pas toujours 
leur bon UUID.
Exemple :
$menuentry_id_option 
'osprober-gnulinux-/boot/vmlinuz-4.4.0-109-generic-root=UUID=3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8
 
ro single-6af32adf-87c5-4c3f-b390-9727185169ef' ...

Dans un même menuentry /dev/sda5, deux UUID différents :
3ba3cb5b-5a71-4d13-90d2-dcdfbea7b3b8 = /dev/sda1
6af32adf-87c5-4c3f-b390-9727185169ef = /dev/sda5

Bonne soirée,

André

Re: update-grub2

[Eric Degenetais]

Le 15 janv. 2018 20:25, "steve"  a écrit :

Le 15-01-2018, à 16:52:44 +0100, hamster a écrit :

Le 14/01/2018 à 19:00, andre_deb...@numericable.fr a écrit :
>
>> avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue)
>> et trois partitions logiques sda5 à sda7.
>>
>
> C'est hors sujet par rapport a grub, mais je met la partition swap en
> premier pour que la tete de lecture du disque ait moins de chemin a
> parcourir quand l'ordi swappe.
>

Sous-entendu que la tête passe plus de temps au centre que vers
l'extérieur. Mais est-ce bien le cas ? On pourrait se dire que ce serait
plus optimisé de le mettre au centre (moins de chemin à parcourir en
moyenne). J'en sais à vrai dire rien, mais j'imagine que ça dépend
fortement du partitionnement lui-même et du type d'utilisation de la
machine.

Intuitivement, je dirais que la tête doit être un peu n'importe où au gré
des accès.
Après, si on est certain de la partition la plus lue, ça doit pouvoir
accélérer les choses de mettre le swap à proximité. Mais ça fait
l'hypothèse que c'est plus avantageux de faire osciller une tête entre deux
positions proches. Est-ce que tous les disques ont des têtes synchrones, où
est-ce que les têtes peuvent être décalées entre elles ?
À mon avis il vaut mieux en rester à : "swapper c'est lent, évitons au
maximum de le faire" et laisser tomber le reste.
Un truc qui est paraît-il vraiment efficace si on souhaite swapper plus
vite, et qui ne repose pas sur des hypothèses au sujet du fonctionnement
des disques, c'est de faire plusieurs swaps sur des disques différents, et
laisser le noyau paralleliser les accès au swap.

Cordialement

Re: update-grub2

[steve]

Le 15-01-2018, à 16:52:44 +0100, hamster a écrit :


Le 14/01/2018 à 19:00, andre_deb...@numericable.fr a écrit :

avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue)
et trois partitions logiques sda5 à sda7.


C'est hors sujet par rapport a grub, mais je met la partition swap en
premier pour que la tete de lecture du disque ait moins de chemin a
parcourir quand l'ordi swappe.


Sous-entendu que la tête passe plus de temps au centre que vers
l'extérieur. Mais est-ce bien le cas ? On pourrait se dire que ce serait
plus optimisé de le mettre au centre (moins de chemin à parcourir en
moyenne). J'en sais à vrai dire rien, mais j'imagine que ça dépend
fortement du partitionnement lui-même et du type d'utilisation de la
machine.

Re: update-grub2

[hamster]

Le 14/01/2018 à 19:00, andre_deb...@numericable.fr a écrit :
> avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue)
> et trois partitions logiques sda5 à sda7.

C'est hors sujet par rapport a grub, mais je met la partition swap en
premier pour que la tete de lecture du disque ait moins de chemin a
parcourir quand l'ordi swappe.

Re: update-grub2

[andre_debian]

On Sunday 14 January 2018 19:37:35 Haricophile wrote:
> Le Sun, 14 Jan 2018 19:00:16 +0100,
> andre_deb...@numericable.fr a écrit :
> > Grub semble trouver la partition n° 1 (racine)
> > mais pas /dev/sda2... et les autres.
> > Comment créer le menu Grub avec toutes les partitions citées ?
> > (création de grub.cfg)

> Ton disque ne serait pas en gpt/efi ? En ce cas utiliser grub-efi
> serait fortement conseillé. 

Non et il fonctionnait avec update-grub2

Re: update-grub2

[andre_debian]

On Sunday 14 January 2018 19:12:53 Michel wrote:
> Le 14/01/2018 à 19:10, andre_deb...@numericable.fr a écrit :
> > Mon ordinateur possède un seul disque dur /dev/sda,
> > avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue)
> > et trois partitions logiques sda5 à sda7.
> > sda1, sda2, sda5, sda6 et sda7 = GNU/Linux en ext4, installé.
> > # update-grub2
> > Création du fichier de configuration GRUB...
> > Image Linux trouvée : /boot/vmlinuz-4.4.0-109-generic
> > Image mémoire initiale trouvée : /boot/initrd.img-4.4.0-109-generic
> > Failed to probe /dev/sda2 for filesystem type
> > Failed to probe /dev/sda5 for filesystem type
> > Failed to probe /dev/sda6 for filesystem type
> > Failed to probe /dev/sda7 for filesystem type
> > Grub semble trouver la partition n° 1 (racine)
> > mais pas /dev/sda2... et les autres.
> > Comment créer le menu Grub avec toutes les partitions citées ?
> > (création de grub.cfg)

> Mais tu as un système installé sur chaque partition? :

Oui, comme je l'ai indiqué ci-dessus.

Re: update-grub2

[Haricophile]

Le Sun, 14 Jan 2018 19:00:16 +0100,
andre_deb...@numericable.fr a écrit :

> Grub semble trouver la partition n° 1 (racine)
> mais pas /dev/sda2... et les autres.
> 
> Comment créer le menu Grub avec toutes les partitions citées ?
> (création de grub.cfg)
> 
> Merci, André


Ton disque ne serait pas en gpt/efi ? En ce cas utiliser grub-efi
serait fortement conseillé. 

Re: update-grub2

[Michel]

Le 14/01/2018 à 19:10, andre_deb...@numericable.fr a écrit :
> Bonsoir,
> 
> Mon ordinateur possède un seul disque dur /dev/sda,
> avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue)
> et trois partitions logiques sda5 à sda7.
> 
> sda1, sda2, sda5, sda6 et sda7 = GNU/Linux en ext4, installé.
> 
> # update-grub2
> Création du fichier de configuration GRUB...
> Image Linux trouvée : /boot/vmlinuz-4.4.0-109-generic
> Image mémoire initiale trouvée : /boot/initrd.img-4.4.0-109-generic
> Failed to probe /dev/sda2 for filesystem type
> Failed to probe /dev/sda5 for filesystem type
> Failed to probe /dev/sda6 for filesystem type
> Failed to probe /dev/sda7 for filesystem type
> 
> Grub semble trouver la partition n° 1 (racine)
> mais pas /dev/sda2... et les autres.
> 
> Comment créer le menu Grub avec toutes les partitions citées ?
> (création de grub.cfg)
> 
> Merci, André
> 

Mais tu as un système installé sur chaque partition?

update-grub2

[andre_debian]

Bonsoir,

Mon ordinateur possède un seul disque dur /dev/sda,
avec 4 partitions principales (/dev/sda1, sda2, swap et sda4 étendue)
et trois partitions logiques sda5 à sda7.

sda1, sda2, sda5, sda6 et sda7 = GNU/Linux en ext4, installé.

# update-grub2
Création du fichier de configuration GRUB...
Image Linux trouvée : /boot/vmlinuz-4.4.0-109-generic
Image mémoire initiale trouvée : /boot/initrd.img-4.4.0-109-generic
Failed to probe /dev/sda2 for filesystem type
Failed to probe /dev/sda5 for filesystem type
Failed to probe /dev/sda6 for filesystem type
Failed to probe /dev/sda7 for filesystem type

Grub semble trouver la partition n° 1 (racine)
mais pas /dev/sda2... et les autres.

Comment créer le menu Grub avec toutes les partitions citées ?
(création de grub.cfg)

Merci, André

kernel param vga=* and grub2

[john doe]

Hi list,

I'm booting and installing debian 9 using a serial console.

After entering the boot command:

"install console=ttyS0,115200n8"

the following appeared:

"Undefined video mode number: 314
Press  to see video modes available,  to continue, or wait 
30 sec"


This can be suppressed by  adding 'vga=off'.
However, vga=* is deprecated in grub2 and will make your newly 
installation unbootable.

I would prefer not to have to manually correct this issue.
Does anyone has any idea on how to avoied that prompt while keeping 
grub2 happy?


--
John Doe

Re: (deb-cat) GRUB2, BIOS, LBA, mdadm

[Jordi Miguel]

Amb la informació que disposem no se m'acut cap idea per ajudar-te a
fer que el GRUB vegi el volum RAID, així que em sembla q et queden
dues opcions:

1. Esperar que algu d'aquesta llista tingui una bona idea per
solucionar-ho i/o anar a demanar suport als desenvolupadors de GRUB
per tal de trobar la causa del teu problema.
2. Canviar d'estratègia i aconseguir el teu volum amb els 3 discs
utilitzant LVM enlloc de RAID. Potser d'aquesta manera esquives els
problemes/anomalies.


Salutacions,
Jordi

--
Para ser realmente grande, hay que estar con la gente, no por encima de ella.

2017-11-23 17:30 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>
> $ insmod mdraid1x
> $ ls
> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1) (fd0)
>
>
>
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 23/11/17 a les 16:19, Jordi Miguel ha escrit:
> > Sembla ser que el GRUB no està veient els dispositius RAID. Podries
> > executar a la shell de GRUB el següent i enviar-nos la sortida??
> >
> > grub> insmod mdraid # (podria ser que es digues "raid" a seques, no
> > estic segur del nom ara)
> > grub> ls
> >
> >
> > Salutacions,
> > Jordi
> > --
> > Para ser realmente grande, hay que estar con la gente, no por encima de 
> > ella.
> >
> >
> > 2017-11-23 15:38 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
> >> Deshabilitant la disquetera de 1.44K, la única diferència és que
> >> desapareix el missatge sobre «fd0». Tinc entès que seria possible
> >> configurar el mapa d'unitats de GRUB per tal que ometi unitats com fd0.
> >>
> >> grub rescue> ls
> >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1)
> >>
> >> grub rescue> ls (hd0,msdos1)/
> >> error: unknown filesystem.
> >>
> >>
> >> __
> >> I'm using this express-made address because personal addresses aren't
> >> masked enough at this mail public archive. Public archive administrator
> >> should fix this against automated addresses collectors.
> >>
> >> El 23/11/17 a les 15:25, Jordi Miguel ha escrit:
> >>> Donades les linies d'error que ens has posat sembla que la unitat de
> >>> disquet (fd0) de l'ordinador esta en conflicte amb el GRUB, ja sigui
> >>> per un bug o un altre motiu que desconec. Podries provar a desactivar
> >>> de la BIOS la unitat de disquet (i ja posats desendollar-la del
> >>> ordinador per estar segurs) i provar-ho de nou?
> >>> Si a la consola del Grub executes un "ls", quines particions veu? Ens
> >>> pots enviar l'output?
> >>>
> >>> A veure si hi ha sort.
> >>>
> >>>
> >>> Salutacions,
> >>> Jordi
> >>>
> >>> --
> >>> Para ser realmente grande, hay que estar con la gente, no por encima de 
> >>> ella.
> >>>
> >>>
> >>> 2017-11-23 14:02 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
> >>>> No sabia que GRUB2 ja s'espabilava directament amb RAID. Ho fa GRUB1 ?
> >>>>
> >>>> He tingut oportunitat de provar amb un disc dur de 20GB (dins els límits
> >>>> de la BIOS):
> >>>> /dev/sda1 Ext4 1GB per /boot
> >>>> /dev/sda2 Ext4 10GB per l'arrel
> >>>> Resultat: Després d'instal·lar bé, no arrenca amb el mateix missatge.
> >>>> Aleshores, de qualsevol manera GRUB2 en un i586 autèntic no reconeix els
> >>>> sistemes de fitxers quan hi ha 2 particions al mateix disc.
> >>>>
> >>>> Vist això, avui també he provat la suggerència de Jordi Miguel:
> >>>> /dev/sda1 (els 32GiB) volum per a RAID
> >>>> /dev/sdb1 (els 32GiB) volum per a RAID
> >>>> /dev/sdc1 (els 32GiB) volum per a RAID
> >>>> -> /dev/md0 (els 100GB) Ext4 per l'arrel.
> >>>> Resultat: Després d'instal·lar bé, no arrenca. Els missatges:
> >>>>
> >>>> error: failure reading sector 0xb30 from `fd0´.
> >>>> error: disk `mduuid/a867853f5e9773488fa4911285e2db93´ not found.
> >>>> Entering rescue mode...
> >>>> grub rescue> _
> >>>>
> >>>> Hauria de sacrificar tot el primer disc només per /boot fora del RAID?
> >>>>
> >>>>
> >>>> __
>

Re: (deb-cat) GRUB2, BIOS, LBA, mdadm

[Narcis Garcia]

$ insmod mdraid1x
$ ls
(hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1) (fd0)



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 23/11/17 a les 16:19, Jordi Miguel ha escrit:
> Sembla ser que el GRUB no està veient els dispositius RAID. Podries
> executar a la shell de GRUB el següent i enviar-nos la sortida??
> 
> grub> insmod mdraid # (podria ser que es digues "raid" a seques, no
> estic segur del nom ara)
> grub> ls
> 
> 
> Salutacions,
> Jordi
> --
> Para ser realmente grande, hay que estar con la gente, no por encima de ella.
> 
> 
> 2017-11-23 15:38 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>> Deshabilitant la disquetera de 1.44K, la única diferència és que
>> desapareix el missatge sobre «fd0». Tinc entès que seria possible
>> configurar el mapa d'unitats de GRUB per tal que ometi unitats com fd0.
>>
>> grub rescue> ls
>> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1)
>>
>> grub rescue> ls (hd0,msdos1)/
>> error: unknown filesystem.
>>
>>
>> __
>> I'm using this express-made address because personal addresses aren't
>> masked enough at this mail public archive. Public archive administrator
>> should fix this against automated addresses collectors.
>>
>> El 23/11/17 a les 15:25, Jordi Miguel ha escrit:
>>> Donades les linies d'error que ens has posat sembla que la unitat de
>>> disquet (fd0) de l'ordinador esta en conflicte amb el GRUB, ja sigui
>>> per un bug o un altre motiu que desconec. Podries provar a desactivar
>>> de la BIOS la unitat de disquet (i ja posats desendollar-la del
>>> ordinador per estar segurs) i provar-ho de nou?
>>> Si a la consola del Grub executes un "ls", quines particions veu? Ens
>>> pots enviar l'output?
>>>
>>> A veure si hi ha sort.
>>>
>>>
>>> Salutacions,
>>> Jordi
>>>
>>> --
>>> Para ser realmente grande, hay que estar con la gente, no por encima de 
>>> ella.
>>>
>>>
>>> 2017-11-23 14:02 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>>>> No sabia que GRUB2 ja s'espabilava directament amb RAID. Ho fa GRUB1 ?
>>>>
>>>> He tingut oportunitat de provar amb un disc dur de 20GB (dins els límits
>>>> de la BIOS):
>>>> /dev/sda1 Ext4 1GB per /boot
>>>> /dev/sda2 Ext4 10GB per l'arrel
>>>> Resultat: Després d'instal·lar bé, no arrenca amb el mateix missatge.
>>>> Aleshores, de qualsevol manera GRUB2 en un i586 autèntic no reconeix els
>>>> sistemes de fitxers quan hi ha 2 particions al mateix disc.
>>>>
>>>> Vist això, avui també he provat la suggerència de Jordi Miguel:
>>>> /dev/sda1 (els 32GiB) volum per a RAID
>>>> /dev/sdb1 (els 32GiB) volum per a RAID
>>>> /dev/sdc1 (els 32GiB) volum per a RAID
>>>> -> /dev/md0 (els 100GB) Ext4 per l'arrel.
>>>> Resultat: Després d'instal·lar bé, no arrenca. Els missatges:
>>>>
>>>> error: failure reading sector 0xb30 from `fd0´.
>>>> error: disk `mduuid/a867853f5e9773488fa4911285e2db93´ not found.
>>>> Entering rescue mode...
>>>> grub rescue> _
>>>>
>>>> Hauria de sacrificar tot el primer disc només per /boot fora del RAID?
>>>>
>>>>
>>>> __
>>>> I'm using this express-made address because personal addresses aren't
>>>> masked enough at this mail public archive. Public archive administrator
>>>> should fix this against automated addresses collectors.
>>>>
>>>> El 22/11/17 a les 19:57, Jordi Miguel ha escrit:
>>>>> Hola,
>>>>>
>>>>> Pq mantens la partició boot fora del RAID?? Et proposo q provis la
>>>>> següent config:
>>>>>
>>>>> - /dev/sda1: Partició primària de la resta, volum per a RAID
>>>>> - /dev/sda2: Partició primària de 1GB, volum per a RAID
>>>>> - /dev/sdb1: Partició primària de la resta, volum per a RAID
>>>>> - /dev/sdb2: Partició primària de 1GB, volum per a RAID
>>>>> - /dev/sdc1: Partició primària de la resta, volum per a RAID
>>>>> - /dev/sdc2: Partició primària de 1GB, volum per a RAID
>>>>>
>>>>> /dev/md0: RAID0 amb les 3 particions gran

Re: (deb-cat) GRUB2, BIOS, LBA, mdadm

[Jordi Miguel]

Sembla ser que el GRUB no està veient els dispositius RAID. Podries
executar a la shell de GRUB el següent i enviar-nos la sortida??

grub> insmod mdraid # (podria ser que es digues "raid" a seques, no
estic segur del nom ara)
grub> ls


Salutacions,
Jordi
--
Para ser realmente grande, hay que estar con la gente, no por encima de ella.


2017-11-23 15:38 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
> Deshabilitant la disquetera de 1.44K, la única diferència és que
> desapareix el missatge sobre «fd0». Tinc entès que seria possible
> configurar el mapa d'unitats de GRUB per tal que ometi unitats com fd0.
>
> grub rescue> ls
> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1)
>
> grub rescue> ls (hd0,msdos1)/
> error: unknown filesystem.
>
>
> __
> I'm using this express-made address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
>
> El 23/11/17 a les 15:25, Jordi Miguel ha escrit:
>> Donades les linies d'error que ens has posat sembla que la unitat de
>> disquet (fd0) de l'ordinador esta en conflicte amb el GRUB, ja sigui
>> per un bug o un altre motiu que desconec. Podries provar a desactivar
>> de la BIOS la unitat de disquet (i ja posats desendollar-la del
>> ordinador per estar segurs) i provar-ho de nou?
>> Si a la consola del Grub executes un "ls", quines particions veu? Ens
>> pots enviar l'output?
>>
>> A veure si hi ha sort.
>>
>>
>> Salutacions,
>> Jordi
>>
>> --
>> Para ser realmente grande, hay que estar con la gente, no por encima de ella.
>>
>>
>> 2017-11-23 14:02 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>>> No sabia que GRUB2 ja s'espabilava directament amb RAID. Ho fa GRUB1 ?
>>>
>>> He tingut oportunitat de provar amb un disc dur de 20GB (dins els límits
>>> de la BIOS):
>>> /dev/sda1 Ext4 1GB per /boot
>>> /dev/sda2 Ext4 10GB per l'arrel
>>> Resultat: Després d'instal·lar bé, no arrenca amb el mateix missatge.
>>> Aleshores, de qualsevol manera GRUB2 en un i586 autèntic no reconeix els
>>> sistemes de fitxers quan hi ha 2 particions al mateix disc.
>>>
>>> Vist això, avui també he provat la suggerència de Jordi Miguel:
>>> /dev/sda1 (els 32GiB) volum per a RAID
>>> /dev/sdb1 (els 32GiB) volum per a RAID
>>> /dev/sdc1 (els 32GiB) volum per a RAID
>>> -> /dev/md0 (els 100GB) Ext4 per l'arrel.
>>> Resultat: Després d'instal·lar bé, no arrenca. Els missatges:
>>>
>>> error: failure reading sector 0xb30 from `fd0´.
>>> error: disk `mduuid/a867853f5e9773488fa4911285e2db93´ not found.
>>> Entering rescue mode...
>>> grub rescue> _
>>>
>>> Hauria de sacrificar tot el primer disc només per /boot fora del RAID?
>>>
>>>
>>> __
>>> I'm using this express-made address because personal addresses aren't
>>> masked enough at this mail public archive. Public archive administrator
>>> should fix this against automated addresses collectors.
>>>
>>> El 22/11/17 a les 19:57, Jordi Miguel ha escrit:
>>>> Hola,
>>>>
>>>> Pq mantens la partició boot fora del RAID?? Et proposo q provis la
>>>> següent config:
>>>>
>>>> - /dev/sda1: Partició primària de la resta, volum per a RAID
>>>> - /dev/sda2: Partició primària de 1GB, volum per a RAID
>>>> - /dev/sdb1: Partició primària de la resta, volum per a RAID
>>>> - /dev/sdb2: Partició primària de 1GB, volum per a RAID
>>>> - /dev/sdc1: Partició primària de la resta, volum per a RAID
>>>> - /dev/sdc2: Partició primària de 1GB, volum per a RAID
>>>>
>>>> /dev/md0: RAID0 amb les 3 particions grans, formatat a ext4, per a l'arrel.
>>>> /dev/md1: RAID0 amb les 3 particions petites, per a swap.
>>>>
>>>> Despres quan et pregunti on vols instal·lar el grub li especifiques
>>>> que el vols a /dev/sda.
>>>>
>>>>
>>>> Salutacions,
>>>> Jordi
>>>> --
>>>> Para ser realmente grande, hay que estar con la gente, no por encima de 
>>>> ella.
>>>>
>>>>
>>>> 2017-11-22 19:49 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>>>>> Després de fer diversitat de proves amb els discs com a 32GiB de mida:
>>>>>
>>>>> - La mateixa distribució amb el sistema de fitxers Ext3 falla igual.
&

Re: (deb-cat) GRUB2, BIOS, LBA, mdadm

[Narcis Garcia]

Deshabilitant la disquetera de 1.44K, la única diferència és que
desapareix el missatge sobre «fd0». Tinc entès que seria possible
configurar el mapa d'unitats de GRUB per tal que ometi unitats com fd0.

grub rescue> ls
(hd0) (hd0,msdos1) (hd1) (hd1,msdos1) (hd2) (hd2,msdos1)

grub rescue> ls (hd0,msdos1)/
error: unknown filesystem.


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

El 23/11/17 a les 15:25, Jordi Miguel ha escrit:
> Donades les linies d'error que ens has posat sembla que la unitat de
> disquet (fd0) de l'ordinador esta en conflicte amb el GRUB, ja sigui
> per un bug o un altre motiu que desconec. Podries provar a desactivar
> de la BIOS la unitat de disquet (i ja posats desendollar-la del
> ordinador per estar segurs) i provar-ho de nou?
> Si a la consola del Grub executes un "ls", quines particions veu? Ens
> pots enviar l'output?
> 
> A veure si hi ha sort.
> 
> 
> Salutacions,
> Jordi
> 
> --
> Para ser realmente grande, hay que estar con la gente, no por encima de ella.
> 
> 
> 2017-11-23 14:02 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>> No sabia que GRUB2 ja s'espabilava directament amb RAID. Ho fa GRUB1 ?
>>
>> He tingut oportunitat de provar amb un disc dur de 20GB (dins els límits
>> de la BIOS):
>> /dev/sda1 Ext4 1GB per /boot
>> /dev/sda2 Ext4 10GB per l'arrel
>> Resultat: Després d'instal·lar bé, no arrenca amb el mateix missatge.
>> Aleshores, de qualsevol manera GRUB2 en un i586 autèntic no reconeix els
>> sistemes de fitxers quan hi ha 2 particions al mateix disc.
>>
>> Vist això, avui també he provat la suggerència de Jordi Miguel:
>> /dev/sda1 (els 32GiB) volum per a RAID
>> /dev/sdb1 (els 32GiB) volum per a RAID
>> /dev/sdc1 (els 32GiB) volum per a RAID
>> -> /dev/md0 (els 100GB) Ext4 per l'arrel.
>> Resultat: Després d'instal·lar bé, no arrenca. Els missatges:
>>
>> error: failure reading sector 0xb30 from `fd0´.
>> error: disk `mduuid/a867853f5e9773488fa4911285e2db93´ not found.
>> Entering rescue mode...
>> grub rescue> _
>>
>> Hauria de sacrificar tot el primer disc només per /boot fora del RAID?
>>
>>
>> __
>> I'm using this express-made address because personal addresses aren't
>> masked enough at this mail public archive. Public archive administrator
>> should fix this against automated addresses collectors.
>>
>> El 22/11/17 a les 19:57, Jordi Miguel ha escrit:
>>> Hola,
>>>
>>> Pq mantens la partició boot fora del RAID?? Et proposo q provis la
>>> següent config:
>>>
>>> - /dev/sda1: Partició primària de la resta, volum per a RAID
>>> - /dev/sda2: Partició primària de 1GB, volum per a RAID
>>> - /dev/sdb1: Partició primària de la resta, volum per a RAID
>>> - /dev/sdb2: Partició primària de 1GB, volum per a RAID
>>> - /dev/sdc1: Partició primària de la resta, volum per a RAID
>>> - /dev/sdc2: Partició primària de 1GB, volum per a RAID
>>>
>>> /dev/md0: RAID0 amb les 3 particions grans, formatat a ext4, per a l'arrel.
>>> /dev/md1: RAID0 amb les 3 particions petites, per a swap.
>>>
>>> Despres quan et pregunti on vols instal·lar el grub li especifiques
>>> que el vols a /dev/sda.
>>>
>>>
>>> Salutacions,
>>> Jordi
>>> --
>>> Para ser realmente grande, hay que estar con la gente, no por encima de 
>>> ella.
>>>
>>>
>>> 2017-11-22 19:49 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>>>> Després de fer diversitat de proves amb els discs com a 32GiB de mida:
>>>>
>>>> - La mateixa distribució amb el sistema de fitxers Ext3 falla igual.
>>>> - Amb una sola partició primària Ext4 de 10GB al primer disc dur, FUNCIONA.
>>>> - Amb dues particions primàries Ext4 al primer disc dur:
>>>>   (/boot de 1GB, arrel de 10GB) Falla amb el mateix missatge.
>>>>
>>>> És a dir, que el problema no sembla tenir a veure amb la mida de les
>>>> particions, ni amb el RAID.
>>>>
>>>>
>>>>
>>>> __
>>>> I'm using this express-made address because personal addresses aren't
>>>> masked enough at this mail public archive. Public archive administrator
>>>> should fix this against automated addresses collectors.
>>>> El 21/11/17 a les 20:48, Narcis Garcia ha escrit:
>>>>> Estic posant

Re: (deb-cat) GRUB2, BIOS, LBA, mdadm

[Narcis Garcia]

No sabia que GRUB2 ja s'espabilava directament amb RAID. Ho fa GRUB1 ?

He tingut oportunitat de provar amb un disc dur de 20GB (dins els límits
de la BIOS):
/dev/sda1 Ext4 1GB per /boot
/dev/sda2 Ext4 10GB per l'arrel
Resultat: Després d'instal·lar bé, no arrenca amb el mateix missatge.
Aleshores, de qualsevol manera GRUB2 en un i586 autèntic no reconeix els
sistemes de fitxers quan hi ha 2 particions al mateix disc.

Vist això, avui també he provat la suggerència de Jordi Miguel:
/dev/sda1 (els 32GiB) volum per a RAID
/dev/sdb1 (els 32GiB) volum per a RAID
/dev/sdc1 (els 32GiB) volum per a RAID
-> /dev/md0 (els 100GB) Ext4 per l'arrel.
Resultat: Després d'instal·lar bé, no arrenca. Els missatges:

error: failure reading sector 0xb30 from `fd0´.
error: disk `mduuid/a867853f5e9773488fa4911285e2db93´ not found.
Entering rescue mode...
grub rescue> _

Hauria de sacrificar tot el primer disc només per /boot fora del RAID?


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

El 22/11/17 a les 19:57, Jordi Miguel ha escrit:
> Hola,
> 
> Pq mantens la partició boot fora del RAID?? Et proposo q provis la
> següent config:
> 
> - /dev/sda1: Partició primària de la resta, volum per a RAID
> - /dev/sda2: Partició primària de 1GB, volum per a RAID
> - /dev/sdb1: Partició primària de la resta, volum per a RAID
> - /dev/sdb2: Partició primària de 1GB, volum per a RAID
> - /dev/sdc1: Partició primària de la resta, volum per a RAID
> - /dev/sdc2: Partició primària de 1GB, volum per a RAID
> 
> /dev/md0: RAID0 amb les 3 particions grans, formatat a ext4, per a l'arrel.
> /dev/md1: RAID0 amb les 3 particions petites, per a swap.
> 
> Despres quan et pregunti on vols instal·lar el grub li especifiques
> que el vols a /dev/sda.
> 
> 
> Salutacions,
> Jordi
> --
> Para ser realmente grande, hay que estar con la gente, no por encima de ella.
> 
> 
> 2017-11-22 19:49 GMT+01:00 Narcis Garcia <debianli...@actiu.net>:
>> Després de fer diversitat de proves amb els discs com a 32GiB de mida:
>>
>> - La mateixa distribució amb el sistema de fitxers Ext3 falla igual.
>> - Amb una sola partició primària Ext4 de 10GB al primer disc dur, FUNCIONA.
>> - Amb dues particions primàries Ext4 al primer disc dur:
>>   (/boot de 1GB, arrel de 10GB) Falla amb el mateix missatge.
>>
>> És a dir, que el problema no sembla tenir a veure amb la mida de les
>> particions, ni amb el RAID.
>>
>>
>>
>> __
>> I'm using this express-made address because personal addresses aren't
>> masked enough at this mail public archive. Public archive administrator
>> should fix this against automated addresses collectors.
>> El 21/11/17 a les 20:48, Narcis Garcia ha escrit:
>>> Estic posant a punt Debian 8 en un ordinador amb processador «Intel
>>> Pentium MMX» a 200MHz.
>>> La BIOS no reconeix discs més grans de 32GiB, i n'hi he posat 3 de 80GB
>>> que permeten limitar per maquinari la mida anunciada, a 32GiB. Així la
>>> BIOS arrenca l'ordinador admetent tots els discs durs.
>>>
>>> Al DebianInstaller, però, el partidor reconeix que els discs són de 80GB
>>> i els particiona i formateja sense problema. Aleshores he establert la
>>> següent configuració de disc:
>>>
>>> /dev/sda1: Partició primària d'1GB, ext4, per a muntar /boot
>>> /dev/sda2: Partició primària de la resta, volum per a RAID
>>> /dev/sdb1: Partició primària d'1GB, no utilitzada
>>> /dev/sdb2: Partició primària de la resta, volum per a RAID
>>> /dev/sdc1: Partició primària d'1GB, no utilitzada
>>> /dev/sdc2: Partició primària de la resta, volum per a RAID
>>>
>>> /dev/md0: RAID0 amb els 3 volums, formatat a ext4, per a l'arrel.
>>>
>>> La resta de procés d'instal·lació ha estat llarguíssima, evidentment a
>>> causa del processador. Al final li he fet instal·lar GRUB a /dev/sda
>>>
>>> En reiniciar cap a disc dur, es queda amb:
>>> error: unknown filesystem.
>>> Entering rescue mode...
>>> grub rescue>
>>>
>>> Si provo:
>>> grub rescue> ls
>>> (hd0) (hd0,msdos1) (hd0,msdos2) (hd1) (hd1,msdos1) (hd1,msdos2) (hd2)
>>> (hd2,msdos1) (hd2,msdos2)
>>>
>>> Si provo:
>>> grub rescue> ls (hd0,msdos1)/
>>> (hd0,msdos1): Filesystem is unknown.
>>> [igualment si provo amb qualsevol dels altres volums]
>>>
>>> Ja he provat a iniciar amb el Live-CD (standard) de Debian 8, fer chroot
>>> i "update-grub" + "grub-install /dev/sda" però el resultat sempre és el
>>> mateix: GRUB2 és l'únic que no reconeix ni tan sols la partició /boot
>>> dun sol gigabyte a l'inici del primer disc.
>>>
>>> Algú pot donar idees a provar?
>>>
>>> Gràcies.
>>>
>>

Re: (deb-cat) GRUB2, BIOS, LBA, mdadm

[Narcis Garcia]

Després de fer diversitat de proves amb els discs com a 32GiB de mida:

- La mateixa distribució amb el sistema de fitxers Ext3 falla igual.
- Amb una sola partició primària Ext4 de 10GB al primer disc dur, FUNCIONA.
- Amb dues particions primàries Ext4 al primer disc dur:
  (/boot de 1GB, arrel de 10GB) Falla amb el mateix missatge.

És a dir, que el problema no sembla tenir a veure amb la mida de les
particions, ni amb el RAID.



__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 21/11/17 a les 20:48, Narcis Garcia ha escrit:
> Estic posant a punt Debian 8 en un ordinador amb processador «Intel
> Pentium MMX» a 200MHz.
> La BIOS no reconeix discs més grans de 32GiB, i n'hi he posat 3 de 80GB
> que permeten limitar per maquinari la mida anunciada, a 32GiB. Així la
> BIOS arrenca l'ordinador admetent tots els discs durs.
> 
> Al DebianInstaller, però, el partidor reconeix que els discs són de 80GB
> i els particiona i formateja sense problema. Aleshores he establert la
> següent configuració de disc:
> 
> /dev/sda1: Partició primària d'1GB, ext4, per a muntar /boot
> /dev/sda2: Partició primària de la resta, volum per a RAID
> /dev/sdb1: Partició primària d'1GB, no utilitzada
> /dev/sdb2: Partició primària de la resta, volum per a RAID
> /dev/sdc1: Partició primària d'1GB, no utilitzada
> /dev/sdc2: Partició primària de la resta, volum per a RAID
> 
> /dev/md0: RAID0 amb els 3 volums, formatat a ext4, per a l'arrel.
> 
> La resta de procés d'instal·lació ha estat llarguíssima, evidentment a
> causa del processador. Al final li he fet instal·lar GRUB a /dev/sda
> 
> En reiniciar cap a disc dur, es queda amb:
> error: unknown filesystem.
> Entering rescue mode...
> grub rescue>
> 
> Si provo:
> grub rescue> ls
> (hd0) (hd0,msdos1) (hd0,msdos2) (hd1) (hd1,msdos1) (hd1,msdos2) (hd2)
> (hd2,msdos1) (hd2,msdos2)
> 
> Si provo:
> grub rescue> ls (hd0,msdos1)/
> (hd0,msdos1): Filesystem is unknown.
> [igualment si provo amb qualsevol dels altres volums]
> 
> Ja he provat a iniciar amb el Live-CD (standard) de Debian 8, fer chroot
> i "update-grub" + "grub-install /dev/sda" però el resultat sempre és el
> mateix: GRUB2 és l'únic que no reconeix ni tan sols la partició /boot
> dun sol gigabyte a l'inici del primer disc.
> 
> Algú pot donar idees a provar?
> 
> Gràcies.
> 

(deb-cat) GRUB2, BIOS, LBA, mdadm

[Narcis Garcia]

Estic posant a punt Debian 8 en un ordinador amb processador «Intel
Pentium MMX» a 200MHz.
La BIOS no reconeix discs més grans de 32GiB, i n'hi he posat 3 de 80GB
que permeten limitar per maquinari la mida anunciada, a 32GiB. Així la
BIOS arrenca l'ordinador admetent tots els discs durs.

Al DebianInstaller, però, el partidor reconeix que els discs són de 80GB
i els particiona i formateja sense problema. Aleshores he establert la
següent configuració de disc:

/dev/sda1: Partició primària d'1GB, ext4, per a muntar /boot
/dev/sda2: Partició primària de la resta, volum per a RAID
/dev/sdb1: Partició primària d'1GB, no utilitzada
/dev/sdb2: Partició primària de la resta, volum per a RAID
/dev/sdc1: Partició primària d'1GB, no utilitzada
/dev/sdc2: Partició primària de la resta, volum per a RAID

/dev/md0: RAID0 amb els 3 volums, formatat a ext4, per a l'arrel.

La resta de procés d'instal·lació ha estat llarguíssima, evidentment a
causa del processador. Al final li he fet instal·lar GRUB a /dev/sda

En reiniciar cap a disc dur, es queda amb:
error: unknown filesystem.
Entering rescue mode...
grub rescue>

Si provo:
grub rescue> ls
(hd0) (hd0,msdos1) (hd0,msdos2) (hd1) (hd1,msdos1) (hd1,msdos2) (hd2)
(hd2,msdos1) (hd2,msdos2)

Si provo:
grub rescue> ls (hd0,msdos1)/
(hd0,msdos1): Filesystem is unknown.
[igualment si provo amb qualsevol dels altres volums]

Ja he provat a iniciar amb el Live-CD (standard) de Debian 8, fer chroot
i "update-grub" + "grub-install /dev/sda" però el resultat sempre és el
mateix: GRUB2 és l'únic que no reconeix ni tan sols la partició /boot
dun sol gigabyte a l'inici del primer disc.

Algú pot donar idees a provar?

Gràcies.

-- 


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: presque avec grub2

[louis]

Le Wed, 4 Oct 2017 14:18:41 -,
miz...@elude.in a écrit :

> VOUS êtes l'admin et VOUS faites ce que bon vous semble.
> 
> ... la cohérence des partitions ...
> 
> 1° vous faites vos install puis vous faites un restart : ENSUITE
> *update-initramfs -u = mise à jour du swap/fsab.
> *update grub2 = mise à jour des partitions/boot.
> 
> _ chaque install de debian install par défault une swap.
> _ pas de efi = système effaçé/broken à court terme.
> 
> 2° gparted : c'est plus simple.
> 
> 3° no-resume est une option de dépannage à ne pas conserver si
> possible.
> 
> 5° redémarrer donc sur votre nouvelle partion installée.
> 
> 
> 
> pourquoi mettre à jour toutes vos partitions, tout votre système alors
> qu'il ne s'agit :
> 
> a) que d'une clé usb
> b) d'un essai d'un o.s sur une seule partition
> 
> dès le moment où vous vous déconnectez, l'usb est hors jeu, il suffit
> d'attendre quelques instant puis
> soit l'ôter
> soit la déclarer par le bios.
> ___
> 
> VOUS êtes l'admin et VOUS faites ce que bon vous semble.
> si cela vous convient c'est que cela va bien.
> 
> muzikali...@mailoo.org
> et mail que maille !
> 
> 

Merci pour vos conseils, vos aides et vos éclaircissements!

Tout est rentré dans l'ordre :)

Re: tout arrive avec grub2

[Pascal Hambourg]

Le 04/10/2017 à 15:08, lou a écrit :


l'installateur ma évidemment formater ma swap


Non, pas évidemment. L'installateur ne formate un swap existant que si 
on le laisse faire. On a le choix entre utiliser un swap existant et il 
sera formaté, ou ne pas l'utiliser et il ne sera pas formaté.



Maintenant, si je fait un #update-initramfs -u j'ai ça comme retour..


update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
W: initramfs-tools configuration sets
RESUME=UUID=a624326a-3308-41aa-be78-afc35f69067a W: but no matching
swap device is available.


Normal puisque l'UUID du swap a changé mais n'a pas été mis à jour dans 
la configuration d'initramfs-tools.



I: The initramfs will attempt to resume
from /dev/sda5 I: (UUID=86960075-465f-460d-9fe8-6d7a29ee7d9b)
I: Set the RESUME variable to override this.


Mais update-initramfs n'est pas idiot, donc il utilise à la place l'UUID 
du swap actif.



Donc l'initram à conserver l'ancien UUID de la swap et il faut
ré-écrire la varible à l'initram. J'ai bien compris?


Si tu ne veux plus avoir l'avertissement, il faut corriger l'UUID dans 
le fichier /etc/initramfs-tools/conf.d/resume.

Re: tout arrive avec grub2

[lou]

Le Tue, 3 Oct 2017 23:28:26 -,
miz...@elude.in a écrit :

> sda6 = ext4
> sda5 = swap
> 
> sdb6 = media = temp (usb ?)
> sdb5 = media = data (harddisk ?)
> 
> mount : vbox_vous êtes branché dessus ?
> mount : testing ? en double ?
> 
>   c *où est le boot efi ?*
> 
> __
> 
>   a *fichier mal configuré : je ne comprends pas du tout votre
> configuration.*
> 
>   b *votre panne vient peut-être du fait que deux partitions
> étaient montées en même temps.*
> _
> 
> J'avais une clé usb d'insérée au moment ou j'ai redémarré la machine
> et je l'ai pas déconnectée avant le redémarrage j'ai souvent fait
> ça (* moi aussi jusqu'au jour où cela bloque et en plus ça bousille
> la clé et les données*) et j'ai jamais eu de soucidevrais-je ?
> 
> * oui si elle est montée (ça tourne en boucle et ne s'éteint pas d'où
> l'impossibilité de rentrer) pourtant debian gère bien ces imprudences
> brouillonnes.*
> * non si elle est configuré comme login (nitrokey fait ça très bien
> mais on peut le faire à la main).*
> 
> 
> To: debian-user-french@lists.debian.org
> Subject: Re: Rien ne se passe après Grub2...oops oubliez la pièce
> jointe dans le dernier message...
> From: lou <muzikali...@mailoo.org>
> 
> *pour l'option no-resume je vous laisse chercher ou attendre les
> explications de sébastien.*
> 

Je vais expliquer mon fstab :)

Tout d'abord j'ai /dev/sda qui est mon disque ou je met mes tout ce qui
concerne mes OS en partition étendu...

/dev/sda5 qui est ma swap
/dev/sda6 qui est ma debian stable
/dev/sda7 que j'utilise avec virtual box, parce que je ne
le veut pas dans mon home (par défault)..
/dev/sda8 qui est une debian testing, pour tenter de commencer à faire
des rapports de bugs.

Pour ce qui est du boot efi, je croyais qu'il était dans /dev/sda6 dans
le dossi/boot via le mbr ou j'install grub.

/dev/sdb est un autre disque dur.
/dev/sdb1 est une partition pour mes fichiers temporaires d'internet
/dev/sdb2 est mon Data avec tous le reste...musique, video, etc
(celle-ci est encrypté avec LUKS) et je la monte à mon aise si j'en est
besoin. C'est pour ça que la ligne dans le fstab est commenter. Je ne
suis pas habituer de faire une partition avec LUKS et comme sa me
gênait pas, je la laissait commenter. Peut-être que je devrait
l'indiquer dans mon fstab avec l.option noauto, ce qui reviendrait au
même pour moi et ainsi j’éviterais sûrement des conflit future..

Je partitionne de cette façon, car j'install souvent des distributions
pour les essayers Sa me fait moin de backup à faire. cette
distribution "d'essaie" se retrouve donc en /dev/sda8..

Maintenant j'aimerais rajouter un point que je croyais pas pertinant,
mais à présent, oui.

Quand j'ai fait ma clé usb avec cp et que je ne l'ai pas déconnecter
avant de redemarrer, s'était pour faire une installation en /dev/sda8.
(qui est firmware_debian_9). Donc j'ai lancé L'installateur et fait le
processus. l'installateur ma évidemment formater ma swap ainsi que la
partition dédié à la racine. Quand j'ai booter sur le live, dans le
chroot, j'ai édité mon fstab pour changer le UUID de ma swap, qui
venait de changer, vu son formatage. Pour qu'il puisse la détecter, car
je croyait que s'était mon problème.

Maintenant, si je fait un #update-initramfs -u j'ai ça comme retour..

> update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
> W: initramfs-tools configuration sets
> RESUME=UUID=a624326a-3308-41aa-be78-afc35f69067a W: but no matching
> swap device is available. I: The initramfs will attempt to resume
> from /dev/sda5 I: (UUID=86960075-465f-460d-9fe8-6d7a29ee7d9b)
> I: Set the RESUME variable to override this.
L'UUID a624326a-3308-41aa-be78-afc35f69067a est l'ancien UUID de ma
swap...

blkid j’obtiens:
> /dev/sda5: UUID="86960075-465f-460d-9fe8-6d7a29ee7d9b" TYPE="swap"
> PARTUUID="234ee1e3-05"
Donc l'initram à conserver l'ancien UUID de la swap et il faut
ré-écrire la varible à l'initram. J'ai bien compris?

Dans ma pratique, quand j'install une autre distribution sur (/dev/sda8)
et qu'il formate la swap, si je redémarre sur /dev/sda6 (debian stable),
je me retrouve dans un shell ou (press ctrl+D to continue) alors
j'entre le mdp root pour aller changer le nouveau UUID de la swap et je
redémarre et tout va bien 

Donc, c'est le fait de ne pas avoir
déconnecter ma clé usb, lancer l'insatallateur, changer l'uuid en live
session, qui me donne ce compte rendu?

Merci pour l'explication du noresume Sebastien :)

MERCI! :p

Re: Rien ne se passe après Grub2...oops oubliez la pièce jointe dans le dernier message...

[Sébastien NOBILI]

Bonjour,

Le mardi 03 octobre 2017 à 17:23, lou a écrit :
> J'aimerais savoir ce que fait l'option du noyau "noresume" ?? et si je
> peux laisser l'option au noyau...?

L’option « noresume » dit au noyau de ne pas tenter de reprendre une mise en
veille. Lorsque tu mets en veille (hibernation), l’état de ton système est
enregistré dans la partition swap. Ton noyau va tenter de le restaurer.
J’imagine qu’il y avait des choses incohérentes dedans.

Tu peux laisser l’option, mais dans ce cas, tu ne pourras plus mettre ton
système en veille.

Tu peux aussi tester de redémarrer sans l’option. Normalement ta partition de
swap a dû être réinitialisée…

> Parce que, maintenant, je peux entrer dans ma debian :))

Bonne nouvelle !

Sébastien

Re: Rien ne se passe après Grub2...oops oubliez la pièce jointe dans le dernier message...

[lou]

Le Tue, 3 Oct 2017 17:16:17 +0200,
Sébastien NOBILI  a écrit :

> Le mardi 03 octobre 2017 à 10:48, louis a écrit :
> > Pensez-vous que le screenshot en PJ a à voir avec ce problème?  
> 
> Aaaah, voilà la pièce-jointe :D
> 
> Le « -.mount » est étrange… Un problème avec le contenu de fstab ou
> bien un problème d’interprétation de son contenu par Systemd.
> 
> Pourrais-tu nous envoyer le contenu du fichier « /etc/fstab » de ton
> système Debian (pas celui du LiveCD).
> 
> Si tu as des mots de passe dedans, efface-les avant.
> 
> Sébastien
> 

J'aimerais savoir ce que fait l'option du noyau "noresume" ?? et si je
peux laisser l'option au noyau...?
Parce que, maintenant, je peux entrer dans ma debian :))
MERCI!

Je poste quand même mon fstab... parce que je comprend toujours pas
pourquoi j'étais bloqué au démarrage.???..

Je n'est pas de double entrer UUID ou 2 swap et tout semble normale
pour ma part. J'ai une ligne commenter et s'est une partition chiffré
que je monte au moment où je suis dans ma debian et non au boot. 

> vous n'auriez pas branché un disk ou une vm ou un tail ou une usb
> chiffrée avant en oubliant de déconnectez correctement ?
> ou alors une manipulation de fichiers .conf mal sauvegardée ?
> ou un service par init /systemd toujours ouvert ? fermez le service :
> stop
J'avais une clé usb d'insérée au moment ou j'ai redémarré la machine et
je l'ai pas déconnectée avant le redémarrage j'ai souvent fait ça
et  j'ai jamais eu de soucidevrais-je?

Merci à vous 2 Sebastien & Mizett

Et oui mailoo marche toujours, mais je sais pas pour combien de
temps! ;-)

le fstab est en pièce jointe :D

Re: Rien ne se passe après Grub2...oops oubliez la pièce jointe dans le dernier message...

[Sébastien NOBILI]

Le mardi 03 octobre 2017 à 10:48, louis a écrit :
> Pensez-vous que le screenshot en PJ a à voir avec ce problème?

Aaaah, voilà la pièce-jointe :D

Le « -.mount » est étrange… Un problème avec le contenu de fstab ou bien un
problème d’interprétation de son contenu par Systemd.

Pourrais-tu nous envoyer le contenu du fichier « /etc/fstab » de ton système
Debian (pas celui du LiveCD).

Si tu as des mots de passe dedans, efface-les avant.

Sébastien