Re: [opensuse] Leap 15.1 - Nvidia Graphics driver = grub2 does not boot anymore - help very appreciated
On Monday 24 February 2020, stakanov wrote:
I have the problem of a machine with a broken Grub post Nivida driver update. This is nothing new that Nvidia is crap, but I find myself in the situation that I will have to coach over the phone how to repair the grub to a user with limited knowledge (no way to go down to Italy right now, for obvious reason) and honestly: never did the procedure and have no idea about it.
The error message: after booting into the /sda1/gub-efi fat partition the system stalls with: Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.
So, what do I have to do and what do I need? Thank you.
(The user currently should have only a installation DVD. So I suppose - without knowing it - that this shall be a case for live usb or for a rescue disc? Else?)
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
In my notes I saved this message from the past. The suggestion gets the broken root mounted and then suggests using yast to reestablish grub: Re: [opensuse] Boot problem after latest TW dup Date: Today 01:19:10 From: "Knurpht@openSUSE" <knurpht@opensuse.org> (opensuse.org) > ... Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs is located, f.e. /dev/sda2 Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast This worked for me last time (ext4 rootfs). There might be a simpler way, but it go me up and running. Once bootable, I often resolved nvidia X11 issues by just deinstalling then reinstalling the relevant nvidia driver. Generally I've had no issues with nvidia except when I've switched the hardware and need new drivers. I don't find it to be the cause of many woes (tried Radian once for a short while a decade ago, thought it was worse). Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 24 febbraio 2020 19:27:18 CET, Michael Hamilton ha scritto:
On Monday 24 February 2020, stakanov wrote:
I have the problem of a machine with a broken Grub post Nivida driver update. This is nothing new that Nvidia is crap, but I find myself in the situation that I will have to coach over the phone how to repair the grub to a user with limited knowledge (no way to go down to Italy right now, for obvious reason) and honestly: never did the procedure and have no idea about it.
The error message: after booting into the /sda1/gub-efi fat partition the system stalls with: Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.
So, what do I have to do and what do I need? Thank you.
(The user currently should have only a installation DVD. So I suppose - without knowing it - that this shall be a case for live usb or for a rescue disc? Else?)
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de In my notes I saved this message from the past. The suggestion gets the broken root mounted and then suggests using yast to reestablish grub:
Re: [opensuse] Boot problem after latest TW dup Date: Today 01:19:10 From: "Knurpht@openSUSE" <knurpht@opensuse.org> (opensuse.org)
> ...
Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs is located, f.e. /dev/sda2
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
This worked for me last time (ext4 rootfs). There might be a simpler way, but it go me up and running.
Once bootable, I often resolved nvidia X11 issues by just deinstalling then reinstalling the relevant nvidia driver. Generally I've had no issues with nvidia except when I've switched the hardware and need new drivers. I don't find it to be the cause of many woes (tried Radian once for a short while a decade ago, thought it was worse).
Michael
Thank you very much. Now if someone reads this, how does this procedure relate to btrfs? I hate it but the user though it heightens the fault tolerance to her "administrative efforts"? In effect it did well, ...until this occurred. Now I have no machine with btrfs under hand to try "just like that". but /boot/efi is fat / brfs and the home is a Raid1 (which is functional). I really appreciate your reply, thank you very much. Already very helpful. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday 25 February 2020, stakanov wrote:
In data lunedì 24 febbraio 2020 19:27:18 CET, Michael Hamilton ha scritto:
On Monday 24 February 2020, stakanov wrote:
I have the problem of a machine with a broken Grub post Nivida driver update. This is nothing new that Nvidia is crap, but I find myself in the situation that I will have to coach over the phone how to repair the grub to a user with limited knowledge (no way to go down to Italy right now, for obvious reason) and honestly: never did the procedure and have no idea about it.
The error message: after booting into the /sda1/gub-efi fat partition the system stalls with: Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.
So, what do I have to do and what do I need? Thank you.
(The user currently should have only a installation DVD. So I suppose - without knowing it - that this shall be a case for live usb or for a rescue disc? Else?)
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de In my notes I saved this message from the past. The suggestion gets the broken root mounted and then suggests using yast to reestablish grub:
Re: [opensuse] Boot problem after latest TW dup Date: Today 01:19:10 From: "Knurpht@openSUSE" <knurpht@opensuse.org> (opensuse.org)
> ...
Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs is located, f.e. /dev/sda2
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
This worked for me last time (ext4 rootfs). There might be a simpler way, but it go me up and running.
Once bootable, I often resolved nvidia X11 issues by just deinstalling then reinstalling the relevant nvidia driver. Generally I've had no issues with nvidia except when I've switched the hardware and need new drivers. I don't find it to be the cause of many woes (tried Radian once for a short while a decade ago, thought it was worse).
Michael
Thank you very much. Now if someone reads this, how does this procedure relate to btrfs? I hate it but the user though it heightens the fault tolerance to her "administrative efforts"? In effect it did well, ...until this occurred. Now I have no machine with btrfs under hand to try "just like that". but /boot/efi is fat / brfs and the home is a Raid1 (which is functional).
I really appreciate your reply, thank you very much. Already very helpful.
You could practice the recovery by setting up TW in a virtualbox. Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 24 febbraio 2020 20:41:17 CET, Michael Hamilton ha scritto:
On Tuesday 25 February 2020, stakanov wrote:
In data lunedì 24 febbraio 2020 19:27:18 CET, Michael Hamilton ha scritto:
On Monday 24 February 2020, stakanov wrote:
I have the problem of a machine with a broken Grub post Nivida driver update. This is nothing new that Nvidia is crap, but I find myself in the situation that I will have to coach over the phone how to repair the grub to a user with limited knowledge (no way to go down to Italy right now, for obvious reason) and honestly: never did the procedure and have no idea about it.
The error message: after booting into the /sda1/gub-efi fat partition the system stalls with: Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.
So, what do I have to do and what do I need? Thank you.
(The user currently should have only a installation DVD. So I suppose - without knowing it - that this shall be a case for live usb or for a rescue disc? Else?)
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
In my notes I saved this message from the past. The suggestion gets the
broken root mounted and then suggests using yast to reestablish grub: Re: [opensuse] Boot problem after latest TW dup Date: Today 01:19:10 From: "Knurpht@openSUSE" <knurpht@opensuse.org> (opensuse.org)
> ...
Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs
is located, f.e. /dev/sda2
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
This worked for me last time (ext4 rootfs). There might be a simpler way, but it go me up and running.
Once bootable, I often resolved nvidia X11 issues by just deinstalling then reinstalling the relevant nvidia driver. Generally I've had no issues with nvidia except when I've switched the hardware and need new drivers. I don't find it to be the cause of many woes (tried Radian once for a short while a decade ago, thought it was worse).
Michael
Thank you very much. Now if someone reads this, how does this procedure relate to btrfs? I hate it but the user though it heightens the fault tolerance to her "administrative efforts"? In effect it did well, ...until this occurred. Now I have no machine with btrfs under hand to try "just like that". but /boot/efi is fat / brfs and the home is a Raid1 (which is functional).
I really appreciate your reply, thank you very much. Already very helpful.
You could practice the recovery by setting up TW in a virtualbox.
Michael excellent idea.
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, boot from installation media, start installation, abort it. Choose boot installed system. The root partition should be detected, otherwise the system should propose some options. Regards, Francesco On Mon, Feb 24, 2020 at 8:19 PM stakanov <stakanov@eclipso.eu> wrote:
In data lunedì 24 febbraio 2020 19:27:18 CET, Michael Hamilton ha scritto:
On Monday 24 February 2020, stakanov wrote:
I have the problem of a machine with a broken Grub post Nivida driver update. This is nothing new that Nvidia is crap, but I find myself in the situation that I will have to coach over the phone how to repair the grub to a user with limited knowledge (no way to go down to Italy right now, for obvious reason) and honestly: never did the procedure and have no idea about it.
The error message: after booting into the /sda1/gub-efi fat partition the system stalls with: Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.
So, what do I have to do and what do I need? Thank you.
(The user currently should have only a installation DVD. So I suppose - without knowing it - that this shall be a case for live usb or for a rescue disc? Else?)
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de In my notes I saved this message from the past. The suggestion gets the broken root mounted and then suggests using yast to reestablish grub:
Re: [opensuse] Boot problem after latest TW dup Date: Today 01:19:10 From: "Knurpht@openSUSE" <knurpht@opensuse.org> (opensuse.org)
> ...
Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs is located, f.e. /dev/sda2
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
This worked for me last time (ext4 rootfs). There might be a simpler way, but it go me up and running.
Once bootable, I often resolved nvidia X11 issues by just deinstalling then reinstalling the relevant nvidia driver. Generally I've had no issues with nvidia except when I've switched the hardware and need new drivers. I don't find it to be the cause of many woes (tried Radian once for a short while a decade ago, thought it was worse).
Michael
Thank you very much. Now if someone reads this, how does this procedure relate to btrfs? I hate it but the user though it heightens the fault tolerance to her "administrative efforts"? In effect it did well, ...until this occurred. Now I have no machine with btrfs under hand to try "just like that". but /boot/efi is fat / brfs and the home is a Raid1 (which is functional).
I really appreciate your reply, thank you very much. Already very helpful.
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
stakanov wrote:
In data lunedì 24 febbraio 2020 19:27:18 CET, Michael Hamilton ha scritto:
Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs is located, f.e. /dev/sda2
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
Thank you very much. Now if someone reads this, how does this procedure relate to btrfs? I hate it but the user though it heightens the fault tolerance to her "administrative efforts"? In effect it did well, ...until this occurred. Now I have no machine with btrfs under hand to try "just like that". but /boot/efi is fat / brfs and the home is a Raid1 (which is functional).
I use (almost) the same recipe on my machine, should grub give issues. This is also btrfs with uefi boot. Just, as last command, instead of yast I just call grub2-install. This usually brings the system back to boot. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26/02/2020 16.16, Peter Suetterlin wrote:
stakanov wrote:
In data lunedì 24 febbraio 2020 19:27:18 CET, Michael Hamilton ha scritto:
Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs is located, f.e. /dev/sda2
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
Thank you very much. Now if someone reads this, how does this procedure relate to btrfs? I hate it but the user though it heightens the fault tolerance to her "administrative efforts"? In effect it did well, ...until this occurred. Now I have no machine with btrfs under hand to try "just like that". but /boot/efi is fat / brfs and the home is a Raid1 (which is functional).
I use (almost) the same recipe on my machine, should grub give issues. This is also btrfs with uefi boot.
Just, as last command, instead of yast I just call grub2-install.
This usually brings the system back to boot.
Yast boot module permits verifying the boot setup. To make YaST write it all to disk, just do a trivial change, such as changing the number of seconds the menu prompt waits for booting. Say it was 8, change to 7 or 9. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.0 x86_64 (Minas Tirith))
In data mercoledì 26 febbraio 2020 16:16:27 CET, Peter Suetterlin ha scritto:
stakanov wrote:
In data lunedì 24 febbraio 2020 19:27:18 CET, Michael Hamilton ha scritto:
Boot from an install medium, escape to a console by Ctrl-Alt-F2 In the bit below replace sdX# by the /dev/sdX# entry where your root fs
is located, f.e. /dev/sda2
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
Thank you very much. Now if someone reads this, how does this procedure relate to btrfs? I hate it but the user though it heightens the fault tolerance to her "administrative efforts"? In effect it did well, ...until this occurred. Now I have no machine with btrfs under hand to try "just like that". but /boot/efi is fat / brfs and the home is a Raid1 (which is functional).
I use (almost) the same recipe on my machine, should grub give issues. This is also btrfs with uefi boot.
Just, as last command, instead of yast I just call grub2-install.
This usually brings the system back to boot.
O.K. We tried both from install medium and from rescue system. We always come to the point that we are in yast ncurses (I think this is its name, the blueish CLI one) and we are trying to tell yast to rewrite the grub. But it fails, and it fails also with the following: mount /dev/sda3 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast It claims that it has no target, that vfat and btrfs do not support nested ...something and well: fstab gives me: https://paste.opensuse.org/51872619 And blockdevices are: https://paste.opensuse.org/96898695 As you can see in the three shots from smartphone: grub2-install /dev/sda1 gives doesn't support embedding, doesn't support blocklists. in Yast instead I get the "Error1". Now the fstab output give a hint and probably (but I have no idea) the right command would be grub2-install /dev/sda1/boot/grub2/x86_64-efi or would it have to be grub2-install /boot/grub2/x86_64-efi or else? I think this is just a syntax problem. Can anybody shed some light which target I have to give in the aforementioned configuration? Thank you. P.S. I did not find a way to use paste for the smartphone snapshots. Hints welcome, (paste seems to accept only text) _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data mercoledì 4 marzo 2020 11:57:42 CET, stakanov ha scritto: And this is the error message of yast when trying to install grub: https://paste.opensuse.org/58428712 _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
It was missing a mount. mount /dev/sda3 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount /dev/sda1 /boot/efi chroot /mnt grub2-install That was it. useful commands were: output of /etc/fsta and output of lsblk (to understand the structure). Just as a reference for who should be searching for it. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postf�cher sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
stakanov wrote:
It was missing a mount.
mount /dev/sda3 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount /dev/sda1 /boot/efi chroot /mnt grub2-install
I suspect that was "mount /dev/sda1 /mnt/boot/efi"? What I did last time was *after* the chroot issue a 'mount -a' -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
stakanov wrote:
It was missing a mount.
mount /dev/sda3 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount /dev/sda1 /boot/efi chroot /mnt grub2-install
I suspect that was "mount /dev/sda1 /mnt/boot/efi"?
What I did last time was *after* the chroot issue a 'mount -a' Yes, that was it. You know, it seams stupid, but when you have to do this over
In data giovedì 5 marzo 2020 15:17:23 CET, Peter Suetterlin ha scritto: the phone with someone not understanding any of the commands, it can be challenging. It is also that the error is not very specific. I just understood when I looked at fstab instead of blockdevice listing. Thank you very much for your help, all is good now. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 24/02/2020 à 19:27, Michael Hamilton a écrit :
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
even better
Then do: mount /dev/sdX# /mnt
cd /mnt
mount --bind /dev dev
use up arrow and replace dev by proc
mount --bind /proc proc
use up arrox then replace proc by sys
mount --bind /sys /mnt/sys chroot . #don't forget the dot :-)
then do whatever root need
yast
jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data lunedì 24 febbraio 2020 21:03:34 CET, jdd@dodin.org ha scritto:
Le 24/02/2020 à 19:27, Michael Hamilton a écrit :
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
even better
Then do: mount /dev/sdX# /mnt
cd /mnt
mount --bind /dev dev
use up arrow and replace dev by proc
mount --bind /proc proc
use up arrox then replace proc by sys
mount --bind /sys /mnt/sys chroot . #don't forget the dot :-)
then do whatever root need
yast
jdd And this would work also in a system with root in BTRFS? (I guess so, but I prefer to ask explicitly)
_________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
stakanov schrieb am 24.02.20 um 22:08:
In data lunedì 24 febbraio 2020 21:03:34 CET, jdd@dodin.org ha scritto:
Le 24/02/2020 à 19:27, Michael Hamilton a écrit :
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
even better
Then do: mount /dev/sdX# /mnt
cd /mnt
mount --bind /dev dev
use up arrow and replace dev by proc
mount --bind /proc proc
use up arrox then replace proc by sys
mount --bind /sys /mnt/sys chroot . #don't forget the dot :-)
then do whatever root need
yast
jdd And this would work also in a system with root in BTRFS? (I guess so, but I prefer to ask explicitly)
I use this in every filesystem in case of emergency. You can look into fstab if there are other local mounts, and you can add the respective commands, but mkinitrd needs info from /proc, /sys, and /mnt only. And none of these are special on btrfs comapred to, say, ext4. -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 25 febbraio 2020 12:50:01 CET, Werner Flamme ha scritto:
stakanov schrieb am 24.02.20 um 22:08:
In data lunedì 24 febbraio 2020 21:03:34 CET, jdd@dodin.org ha scritto:
Le 24/02/2020 à 19:27, Michael Hamilton a écrit :
Then do: mount /dev/sdX# /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt yast
even better
Then do: mount /dev/sdX# /mnt
cd /mnt
mount --bind /dev dev
use up arrow and replace dev by proc
mount --bind /proc proc
use up arrox then replace proc by sys
mount --bind /sys /mnt/sys chroot . #don't forget the dot :-)
then do whatever root need
yast
jdd
And this would work also in a system with root in BTRFS? (I guess so, but I prefer to ask explicitly)
I use this in every filesystem in case of emergency.
You can look into fstab if there are other local mounts, and you can add the respective commands, but mkinitrd needs info from /proc, /sys, and /mnt only. And none of these are special on btrfs comapred to, say, ext4.
--
Ciao Werner. Thank you so much. Very useful information. Thanks to all of you. _________________________________________________________________ ________________________________________________________ Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Carlos E. R. -
Francesco Teodori -
jdd＠dodin.org -
Michael Hamilton -
Peter Suetterlin -
stakanov -
Werner Flamme