[opensuse] Boot failure after update from 42.2 to 42.3 "Grub-tpm-measure not found"
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 30/10/17 19:45, stakanov wrote:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
My own situation is probably of no help in your case, but it might suggest there's a relation to your problem. I just upgraded a 42.2 machine to 42.3 using the Upgrade function on the DVD. I double-checked each of the upgrade categories as I usually do, and didn't change anything relevant in the Boot section, but when the procedure reached the stage of going for a reboot GRUB bottomed out. Not having a clue what to do next I think I booted in recovery mode, had a look in YaST -> System -> Boot Loader options and changed from GRUB2 to GRUB2 with EFI. It then rebooted with no problems. That system is an Intel NUC which had a fresh 42.1 install with EFI and has now been upgraded twice (no such issue from 42.1 -> 42.2). I imagine that error shouldn't have happened. gumb -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
30.10.2017 21:45, stakanov пишет:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version. It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report. Boot from live image and provide content of /etc/default/grub_installdevice as well as result of bootinfoscript run (get it from github, sourceforge one is way outdated). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 31 ottobre 2017 04:26:43 CET, Andrei Borzenkov ha scritto:
30.10.2017 21:45, stakanov пишет:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version.
It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report.
Boot from live image and provide content of /etc/default/grub_installdevice as well as result of bootinfoscript run (get it from github, sourceforge one is way outdated).
Priviet Andrei. I will provide, due to circumstances that may take a day or two (having some trouble in family, sorry). So do not take the delay for being disinterested. What you described does somewhat fit, as I did a zypper dup but there had been other discs that (today used for other means) may have had an old copy of grub. So stand by please, info comes soon. Thanks. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 31/10/17 03:26, Andrei Borzenkov wrote:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some
30.10.2017 21:45, stakanov пишет: point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version.
It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report.
Sounds to me like YaST gets confused if you've got a multiboot situation (or the user gets confused and screws things up ...) I've got the stock MBR that chained into gentoo-grub on my gentoo partition, that I then chained SUSE-grub on my SUSE partition if that's what I wanted. I don't know what's happened with my upgrade from 42.2 to 42.3, but it now boots straight into SUSE-grub. I *think* it's probably just changed the active partition, but YaST certainly seems to play fast and loose with the previous setup ... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 31 ottobre 2017 04:26:43 CET, Andrei Borzenkov ha scritto:
30.10.2017 21:45, stakanov пишет:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version.
It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report.
Boot from live image and provide content of /etc/default/grub_installdevice as well as result of bootinfoscript run (get it from github, sourceforge one is way outdated).
Ok. I have now the content of grubinstalldevice and for comparison the .old version of it (that was bootable). I tried to run the script but I do get an error message that is: line 7: syntaxerror near to the unattendet token "newline" line 7: '<!DOCTYPE html > Now the content of the files: current is /dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part3 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054 /dev/disk/by-id/scsi-350024e90013e385a-part6 activate generic_mbr As opposed to the "old" version /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HIS1VZJ1KS407054-part6 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054-part3 activate generic_mbr The change came only into being with the update from 42.2 to 42.3 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
05.11.2017 21:45, stakanov пишет:
In data martedì 31 ottobre 2017 04:26:43 CET, Andrei Borzenkov ha scritto:
30.10.2017 21:45, stakanov пишет:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version.
It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report.
Boot from live image and provide content of /etc/default/grub_installdevice as well as result of bootinfoscript run (get it from github, sourceforge one is way outdated).
Ok. I have now the content of grubinstalldevice and for comparison the .old version of it (that was bootable). I tried to run the script but I do get an error message that is: line 7: syntaxerror near to the unattendet token "newline" line 7: '<!DOCTYPE html >
You need to save raw file, not HTML page. Or you can simply download release tarball to avoid any confusion.
Now the content of the files: current is
/dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part3 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054 /dev/disk/by-id/scsi-350024e90013e385a-part6 activate generic_mbr
As opposed to the "old" version
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HIS1VZJ1KS407054-part6 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054-part3 activate generic_mbr
The change came only into being with the update from 42.2 to 42.3
Well, .old file confirms my hypothesis (although we still do not know actual boot block content). I have no idea what and when changed it, I would not expect any change without you going into YaST bootloader and trying to modify configuration. As a general comment, having multiple location can lead to other sort of problems and should better be avoided. There is no real reason to have it (and I suspect it is leftover from the legacy grub which was far less sensitive to it). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data martedì 7 novembre 2017 19:00:32 CET, Andrei Borzenkov ha scritto:
05.11.2017 21:45, stakanov пишет:
In data martedì 31 ottobre 2017 04:26:43 CET, Andrei Borzenkov ha scritto:
30.10.2017 21:45, stakanov пишет:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version.
It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report.
Boot from live image and provide content of /etc/default/grub_installdevice as well as result of bootinfoscript run (get it from github, sourceforge one is way outdated).
Ok. I have now the content of grubinstalldevice and for comparison the .old version of it (that was bootable). I tried to run the script but I do get an error message that is: line 7: syntaxerror near to the unattendet token "newline" line 7: '<!DOCTYPE html >
You need to save raw file, not HTML page. Or you can simply download release tarball to avoid any confusion.
Now the content of the files: current is
/dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part3 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054 /dev/disk/by-id/scsi-350024e90013e385a-part6 activate generic_mbr
As opposed to the "old" version
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HIS1VZJ1KS407054-part6 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054-part3 activate generic_mbr
The change came only into being with the update from 42.2 to 42.3
Well, .old file confirms my hypothesis (although we still do not know actual boot block content). I have no idea what and when changed it, I would not expect any change without you going into YaST bootloader and trying to modify configuration.
As a general comment, having multiple location can lead to other sort of problems and should better be avoided. There is no real reason to have it (and I suspect it is leftover from the legacy grub which was far less sensitive to it).
Here you have the result of bootinfoscript (from git-hub) http://susepaste.org/90387648 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Nov 8, 2017 at 12:38 PM, stakanov <stakanov@eclipso.eu> wrote:
In data martedì 7 novembre 2017 19:00:32 CET, Andrei Borzenkov ha scritto:
05.11.2017 21:45, stakanov пишет:
In data martedì 31 ottobre 2017 04:26:43 CET, Andrei Borzenkov ha scritto:
30.10.2017 21:45, stakanov пишет:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version.
It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report.
Boot from live image and provide content of /etc/default/grub_installdevice as well as result of bootinfoscript run (get it from github, sourceforge one is way outdated).
Ok. I have now the content of grubinstalldevice and for comparison the .old version of it (that was bootable). I tried to run the script but I do get an error message that is: line 7: syntaxerror near to the unattendet token "newline" line 7: '<!DOCTYPE html >
You need to save raw file, not HTML page. Or you can simply download release tarball to avoid any confusion.
Now the content of the files: current is
/dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part3 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054 /dev/disk/by-id/scsi-350024e90013e385a-part6 activate generic_mbr
As opposed to the "old" version
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HIS1VZJ1KS407054-part6 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054-part3 activate generic_mbr
The change came only into being with the update from 42.2 to 42.3
Well, .old file confirms my hypothesis (although we still do not know actual boot block content). I have no idea what and when changed it, I would not expect any change without you going into YaST bootloader and trying to modify configuration.
As a general comment, having multiple location can lead to other sort of problems and should better be avoided. There is no real reason to have it (and I suspect it is leftover from the legacy grub which was far less sensitive to it).
Here you have the result of bootinfoscript (from git-hub)
Well, you have grub2 installed in MBR of /dev/sda and /dev/sdb (as seen from your live system) and referring to /boot/grub2 on /dev/sdb6, but all entries in /etc/default/grub_installdevice point only to sdb. So assuming your BIOS boot device is sda, it perfectly explains what happened. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data mercoledì 8 novembre 2017 13:24:37 CET, hai scritto:
On Wed, Nov 8, 2017 at 12:38 PM, stakanov <stakanov@eclipso.eu> wrote:
In data martedì 7 novembre 2017 19:00:32 CET, Andrei Borzenkov ha scritto:
05.11.2017 21:45, stakanov пишет:
In data martedì 31 ottobre 2017 04:26:43 CET, Andrei Borzenkov ha scritto:
30.10.2017 21:45, stakanov пишет:
This is a very puzzling error as I did not install trusted grub and I do not have tpm on the system. The system is also not UEFI. The update was from 42.2 (working well) to 42.3 (screwed it up and I am now in rescue mode). Did anybody encounter this or does understand what the issue actually is?
TPM support was added to stock grub2. The error suggests that your core.img does not match /boot/grub2. The usual reason is that at some point you used grub2-install manually on the "wrong" device (device that does not match YaST configuration). So now after grub2 update new core.img was written somewhere else and you continue to boot old version.
It may also happen if you ever changed bootloader location in YaST as it probably does not wipe out bootloader in old location. If this is indeed what happened, this warrants bug report.
Boot from live image and provide content of /etc/default/grub_installdevice as well as result of bootinfoscript run (get it from github, sourceforge one is way outdated).
Ok. I have now the content of grubinstalldevice and for comparison the .old version of it (that was bootable). I tried to run the script but I do get an error message that is: line 7: syntaxerror near to the unattendet token "newline" line 7: '<!DOCTYPE html >
You need to save raw file, not HTML page. Or you can simply download release tarball to avoid any confusion.
Now the content of the files: current is
/dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part3 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054 /dev/disk/by-id/scsi-350024e90013e385a-part6 activate generic_mbr
As opposed to the "old" version
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HIS1VZJ1KS407054-part6 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054-part3 activate generic_mbr
The change came only into being with the update from 42.2 to 42.3
Well, .old file confirms my hypothesis (although we still do not know actual boot block content). I have no idea what and when changed it, I would not expect any change without you going into YaST bootloader and trying to modify configuration.
As a general comment, having multiple location can lead to other sort of problems and should better be avoided. There is no real reason to have it (and I suspect it is leftover from the legacy grub which was far less sensitive to it).
Here you have the result of bootinfoscript (from git-hub)
Well, you have grub2 installed in MBR of /dev/sda and /dev/sdb (as seen from your live system) and referring to /boot/grub2 on /dev/sdb6, but all entries in /etc/default/grub_installdevice point only to sdb. So assuming your BIOS boot device is sda, it perfectly explains what happened.
Now the question is, why did this happen after a simple "zypper dup"? Should I simple accept the fact as is and rename the .old file to current? Would this happen again after a regular zypper dup for 15 and especially is there anything I can do on this (admittedly historical) system, that received a lot of hardware upgrades (besides others you may expect a lot of new hdd during the years. I personally do not know how to "clean" an mbr of former grub entries without having to format the whole disk.... Sorry for sending this first as pm, my error. Therefore redirected to the list. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* stakanov <stakanov@eclipso.eu> [11-08-17 10:24]:
In data mercoledì 8 novembre 2017 13:24:37 CET, hai scritto:
On Wed, Nov 8, 2017 at 12:38 PM, stakanov <stakanov@eclipso.eu> wrote:
In data martedì 7 novembre 2017 19:00:32 CET, Andrei Borzenkov ha scritto:
05.11.2017 21:45, stakanov пишет:
In data martedì 31 ottobre 2017 04:26:43 CET, Andrei Borzenkov ha scritto:
30.10.2017 21:45, stakanov пишет: > This is a very puzzling error as I did not install trusted grub and I
[...]
Sorry for sending this first as pm, my error. Therefore redirected to the list.
you might even consider trimming your quoting to only that necessary for understanding your post as strongly suggested in openSUSE mailing list netiquette, 7 levels is somewhat excessive. trimming is courteous and shows consideration to those who might help with your problems. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
08.11.2017 18:22, stakanov пишет: [... trimming so I am not jumped on by self-appointed police of this list ...]
Now the content of the files: current is
/dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part3 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054 /dev/disk/by-id/scsi-350024e90013e385a-part6 activate generic_mbr
As opposed to the "old" version
/dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HIS1VZJ1KS407054-part6 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD502HI_S1VZJ1KS407054-part3 activate generic_mbr
... Here you have the result of bootinfoscript (from git-hub)
Well, you have grub2 installed in MBR of /dev/sda and /dev/sdb (as seen from your live system) and referring to /boot/grub2 on /dev/sdb6, but all entries in /etc/default/grub_installdevice point only to sdb. So assuming your BIOS boot device is sda, it perfectly explains what happened.
Now the question is, why did this happen after a simple "zypper dup"?
What "this"? Changes in grub_installdevice? It does not matter, as both versions refer to sdb only. grub2 in MBR of sda? How should we know this. The fact that it boots from sda? It is your system, I presume you know how it is configured. Again in case you did not understand. You have grub2 in MBR of your boot disk (which I bet is sda) and have configured your openSUSE to put bootloader in (multiple locations of) sdb. So when grub2 package was updated only /boot/grub2 content was touched - but not code in sda MBR. This worked as long as new grub2 versions remained mostly compatible. Once you updated to very different version, bootloader kernel in MBR of boot disk (sda?) stopped providing necessary services for new grub2 modules in /boot/grub2.
Should I simple accept the fact as is and rename the .old file to current?
It will not change anything.
Would this happen again after a regular zypper dup for 15 and especially is there anything I can do on this (admittedly historical) system, that received a lot of hardware upgrades (besides others you may expect a lot of new hdd during the years. I personally do not know how to "clean" an mbr of former grub entries without having to format the whole disk....
Start with telling us what is your boot disk.
Sorry for sending this first as pm, my error. Therefore redirected to the list.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data mercoledì 8 novembre 2017 18:16:15 CET, Andrei Borzenkov ha scritto:
08.11.2017 18:22, stakanov пишет: [... trimming so I am not jumped on by self-appointed police of this list ...] [Well said. I hope that is not too much trimmed. Maybe there is an important netiquette on this too....?]
Start with telling us what is your boot disk.
O.K. First of all: this is "my" system, in the sense that I took care for it. It is my fathers system at my parents home. To be honest I had not to care too much because it just worked. Historically it was a windows system so this is what explains a few of the weirdo things here. Discs are sda, sdb, sdc, and sdd. Initially the sdb was the windows one and was the first disc but after a repair it turns out that: sda is in one only partition of 298 GB and should bear only data with NFTS partition (windows) The sdb was historicall the first disc running with win. sdb 1 160GB NTFS (seems the "own data of users" Windows sdb 2 110GB NTFS (old system disk of Win) Then the partitioner shows: sdb6 with 40 GB ext4 (leap root) sdb7 with 2 GB ext4 (leap swap) sdb5 with 153 GB (? - I do not really recall if this got /var or /home or if it was abandoned. I think it is part of home as LVM, it is ext4) sdc is windows data disc, all dedicated to backup Acronis (so it should not enter in the problem). sdd is 1.8 TB of data with user /home The system should start from sdb, as I have not a /boot, the MBR therefore. Why it did have another location or MBR is not known to me, with 42.2 it booted normally, with 42.3 it stopped to work. And I did not change any setting in yast since at least 12.2. I hope that was somewhat understandable. My father is 91 years old and my parents rely quite a lot on having a running Linux. I would just like to recover the data and have a running system. If grub can be reconfigured to start the otherwise well situated system, I will be happy to do this. Otherwise I would have to know what exactly tell the installer (once read in the existing partitions) in order to not run into this problem again. Thanks in advance. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2017-11-08 at 22:59 +0100, stakanov wrote:
In data mercoledì 8 novembre 2017 18:16:15 CET, Andrei Borzenkov ha scritto:
Start with telling us what is your boot disk.
O.K. First of all: this is "my" system, in the sense that I took care for it. It is my fathers system at my parents home. To be honest I had not to care too much because it just worked. Historically it was a windows system so this is what explains a few of the weirdo things here.
Discs are sda, sdb, sdc, and sdd.
This can be seen in the bootinfo output you posted before. You just need to say which one you want to boot from :-)
Initially the sdb was the windows one and was the first disc but after a repair it turns out that: sda is in one only partition of 298 GB and should bear only data with NFTS partition (windows)
sda1: __________________________________________________________________________ File system: ntfs Boot sector type: Windows 2000/XP: NTFS Boot sector info: No errors found in the Boot Parameter Block. /dev/sda1 * 63 625,134,191 625,134,129 7 NTFS / exFAT / HPFS
The sdb was historicall the first disc running with win. sdb 1 160GB NTFS (seems the "own data of users" Windows sdb 2 110GB NTFS (old system disk of Win)
/dev/sdb1 63 335,854,889 335,854,827 7 NTFS / exFAT / HPFS /dev/sdb2 335,854,890 566,982,044 231,127,155 7 NTFS / exFAT / HPFS /dev/sdb3 * 566,982,045 976,768,064 409,786,020 5 Extended /dev/sdb5 655,435,998 976,768,064 321,332,067 83 Linux ext3 /dev/sdb6 566,982,171 650,857,409 83,875,239 83 Linux ext4 ==> boot /dev/sdb7 650,857,473 655,435,934 4,578,462 82 Linux swap / Solaris sdb6 is a boot partition of 40 GB? Or perhaps "root". Then sdb5 could be home.
Then the partitioner shows: sdb6 with 40 GB ext4 (leap root) sdb7 with 2 GB ext4 (leap swap) sdb5 with 153 GB (? - I do not really recall if this got /var or /home or if it was abandoned. I think it is part of home as LVM, it is ext4)
Hum. If you do not know what it is, check, format and reuse.
sdc is windows data disc, all dedicated to backup Acronis (so it should not enter in the problem). sdd is 1.8 TB of data with user /home
Partition Boot Start Sector End Sector # of Sectors Id System /dev/sdc1 * 63 32,129 32,067 7 NTFS / exFAT / HPFS /dev/sdc2 32,130 488,397,167 488,365,038 5 Extended /dev/sdc5 32,193 488,392,064 488,359,872 bc Acronis BackUp /dev/sdc2 ends after the last sector of /dev/sdc sdc2 and sdc5 are extrange. :-? Festplatte /dev/sde: 28,9 GiB, 31004295168 Bytes, 60555264 Sektoren Partition Boot Start Sector End Sector # of Sectors Id System /dev/sde1 * 0 5,130,239 5,130,240 0 Empty /dev/sde2 304 8,495 8,192 ef EFI (FAT-12/16/32) /dev/sde1 overlaps with /dev/sde2 <================= GUID Partition Table detected, but does not seem to be used. <============== Partition Attrs Start Sector End Sector # of Sectors System /dev/sde1 0 5,129,515 5,129,516 Data partition (Windows/Linux) /dev/sde2 304 8,495 8,192 Data partition (Windows/Linux) There are problems with sde. /dev/sdd1 2,048 3,907,028,991 3,907,026,944 83 Linux HOME sdb6/etc/fstab: /dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part7 swap swap defaults 0 0 /dev/disk/by-id/ata-SAMSUNG_HD502HI_S1VZJ1KS407054-part6 / ext4 data=journal,acl,user_xattr 1 1 UUID=6c891ed2-3d73-4abd-a112-c3e33a055f22 /home ext4 defaults 1 2 Translated: /dev/sdb7 swap swap defaults 0 0 /dev/sdb6 / ext4 data=journal,acl,user_xattr 1 1 /dev/sdd1 /home ext4 defaults 1 2
The system should start from sdb, as I have not a /boot, the MBR therefore. Why it did have another location or MBR is not known to me, with 42.2 it booted normally, with 42.3 it stopped to work. And I did not change any setting in yast since at least 12.2. I hope that was somewhat understandable.
Andrei explained why. Probably "/etc/default/grub" is wrong.
My father is 91 years old and my parents rely quite a lot on having a running Linux. I would just like to recover the data and have a running system. If grub can be reconfigured to start the otherwise well situated system, I will be happy to do this. Otherwise I would have to know what exactly tell the installer (once read in the existing partitions) in order to not run into this problem again.
Well, can you boot the system? I guess not. Boot an openSUSE live system. Mount sdb6 on /mnt, for instance. Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev cd /mnt chroot /mnt yast (text mode) navigate to the section on boot, and change the configuration to be correct: install generic MBR on sdb, install grub in "/dev/sdb3", mark it bootable (it already is), install grub files in /dev/sdb6 More or less, I know how to do it but not from memory. Notice that grub has to be installed "partially" in the extended partition, and the files in a logical partition. Alternatively, backup and install fresh in sdb telling Yast to take the entire disk, without a NEW home partition. Use the existing one in sdd1. I would probably do this, to reuse that unused space. You also have to tell the bios to boot from the second disk. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloDkoEACgkQtTMYHG2NR9UalQCfTbf52s9Ch5SqjF0tY+ConIUZ xBIAoIxVjriMat2YQxf/p4VPG29cEURU =Jdxr -----END PGP SIGNATURE-----
In data giovedì 9 novembre 2017 00:25:46 CET, Carlos E. R. ha scritto:
Well, can you boot the system? I guess not.
No, it gives the error as of above.
sdc2 and sdc5 are extrange. :-? This is easily explained. The Acronis Software for windows is a backup programm that creates a proprietary formatting on the disk and compresses data with it. Therefore only Acronis Software can access this system backup. Linux certainly can not nor can grub.
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sde1 * 0 5,130,239 5,130,240 0 Empty /dev/sde2 304 8,495 8,192 ef EFI (FAT-12/16/32)
/dev/sde1 overlaps with /dev/sde2 <=================
GUID Partition Table detected, but does not seem to be used. <==============
Partition Attrs Start Sector End Sector # of Sectors System /dev/sde1 0 5,129,515 5,129,516 Data partition (Windows/Linux) /dev/sde2 304 8,495 8,192 Data partition (Windows/Linux)
There are problems with sde. Well, that I am subscribing without hesitations. I should not even have an sde disc!
Boot an openSUSE live system. Mount sdb6 on /mnt, for instance.
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
cd /mnt chroot /mnt yast (text mode)
O.K. up to here I am with you. Just will need the live DVD.
navigate to the section on boot, and change the configuration to be correct: install generic MBR on sdb, install grub in "/dev/sdb3", mark it bootable (it already is), install grub files in /dev/sdb6
Is this the yast menu point: "personalized boot partition"?
More or less, I know how to do it but not from memory.
Notice that grub has to be installed "partially" in the extended partition, and the files in a logical partition.
This part I do not understand. How would I do this?
Alternatively, backup and install fresh in sdb telling Yast to take the entire disk, without a NEW home partition. Use the existing one in sdd1. I would probably do this, to reuse that unused space.
You also have to tell the bios to boot from the second disk.
-- Cheers,
Carlos E. R.
I think once I manage to do all this, it would be nice to migrate only linux to a new ssd and then to format and reuse the former system disc. But I do not know if this is possible to do this without a fresh install. (it is just that he has a lot of specific graphics programms installed (believe it or not, he is using blender and other programs. So I would like to avoid to have to search for all programms installed again. P.S. thank you for your help. Also thank you to Andrei. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
stakanov composed on 2017-11-09 09:52 (UTC+0100):
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
cd /mnt chroot /mnt yast (text mode)
O.K. up to here I am with you. Just will need the live DVD.
FWIW, IMO, if I were in your position, and disinclined to research the best possible choice, I'd very likely choose Mageia 5.1 live media. Here's why: 1-rpm distro 2-4.4 kernel, which is what 42.3 uses 3-I'm a multibooter, and Mageia is traditionally (based on Mandrake and Mandriva lineage) my 2nd choice distro (behind openSUSE), thus familiar 4-42.3 and 5.1 both use an iteration of pre-release Grub 2.02. All that said, not needing live media for occasional rescue purposes is one of the secondary benefits of multiboot configuration. :-) BTW, all of my PCs have generic MBR code installed. Grub is installed to partitions only. ;-) -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/11/17 08:52, stakanov wrote:
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
http://www.system-rescue-cd.org/ Based on gentoo, but the point is it's a dedicated rescue distro, with all the recovery tools you could want ... Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.1711091243250.32342@Telcontar.valinor> On Thursday, 2017-11-09 at 09:52 +0100, stakanov wrote:
In data giovedì 9 novembre 2017 00:25:46 CET, Carlos E. R. ha scritto:
Well, can you boot the system? I guess not.
No, it gives the error as of above.
sdc2 and sdc5 are extrange. :-? This is easily explained. The Acronis Software for windows is a backup programm that creates a proprietary formatting on the disk and compresses data with it. Therefore only Acronis Software can access this system backup. Linux certainly can not nor can grub.
Right, I understand that it manages the *contents* of the partition, raw. But what it can not manage is the partition definition itself, not if the resulting partition is inconsistent with others.
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sde1 * 0 5,130,239 5,130,240 0 Empty /dev/sde2 304 8,495 8,192 ef EFI (FAT-12/16/32)
/dev/sde1 overlaps with /dev/sde2 <=================
GUID Partition Table detected, but does not seem to be used. <==============
Partition Attrs Start Sector End Sector # of Sectors System /dev/sde1 0 5,129,515 5,129,516 Data partition (Windows/Linux) /dev/sde2 304 8,495 8,192 Data partition (Windows/Linux)
There are problems with sde. Well, that I am subscribing without hesitations. I should not even have an sde disc!
It is very small, 28,9 GiB
Boot an openSUSE live system. Mount sdb6 on /mnt, for instance.
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
No, it must be an openSUSE disk because you intend to fire up YaST. You can try with the rescue ISO for 13.2, or the one for TW (yes, there is one, I don't know if it is finished). Or you can do what I did: Install Leap in a very small spare partition in another disk. 8 or 9 GB would suffice. For this job, I think you do not need any: just boot Leap install media: there is an option (or there should be, I have not looked or I don't remember) to boot a very small text rescue image. Very few tools, but enough for the procedure I described. If you don't have any, download the NET install disk for the same Leap as you are recovering.
Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
cd /mnt chroot /mnt yast (text mode)
O.K. up to here I am with you. Just will need the live DVD.
Right. yast: (notice that it runs yast from the installed system, not from the rescue system)
navigate to the section on boot, and change the configuration to be correct: install generic MBR on sdb, install grub in "/dev/sdb3", mark it bootable (it already is), install grub files in /dev/sdb6
Is this the yast menu point: "personalized boot partition"?
More or less, I know how to do it but not from memory.
Notice that grub has to be installed "partially" in the extended partition, and the files in a logical partition.
This part I do not understand. How would I do this?
Ok, I will look later at how my laptop is done, because I don't remember; but I have to do it later, I can't access it right now.
I think once I manage to do all this, it would be nice to migrate only linux to a new ssd and then to format and reuse the former system disc. But I do not know if this is possible to do this without a fresh install. (it is just that he has a lot of specific graphics programms installed (believe it or not, he is using blender and other programs. So I would like to avoid to have to search for all programms installed again.
Perfectly possible, I did it myself less than a month ago.
P.S. thank you for your help. Also thank you to Andrei.
Welcome :-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloEQTgACgkQtTMYHG2NR9UZOwCeMrJVxeRnTD6+tYY7q/ZqOu/S 1fcAnA9lcdwQQvtzZOjakcHLuNyDR78+ =G33y -----END PGP SIGNATURE-----
Carlos E. R. composed on 2017-11-09 12:51 (UTC+0100):
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
No, it must be an openSUSE disk because you intend to fire up YaST.
???...
You can try with the rescue ISO for 13.2, or the one for TW (yes, there is one, I don't know if it is finished).
Or you can do what I did: Install Leap in a very small spare partition in another disk. 8 or 9 GB would suffice.
For this job, I think you do not need any: just boot Leap install media: there is an option (or there should be, I have not looked or I don't remember) to boot a very small text rescue image. Very few tools, but enough for the procedure I described. If you don't have any, download the NET install disk for the same Leap as you are recovering.
O.K. up to here I am with you. Just will need the live DVD.
Right.
yast:
(notice that it runs yast from the installed system, not from the rescue system)
So then why do you say the live media must be openSUSE rather than Mageia? The way I understand chroot, only the kernel plus the content of the bind mounts comes from the booted media, while the rest, including YaST2, comes from the chrooted-to filesystem. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2017-11-09 12:51 (UTC+0100):
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
No, it must be an openSUSE disk because you intend to fire up YaST.
???...
You can try with the rescue ISO for 13.2, or the one for TW (yes, there is one, I don't know if it is finished).
Or you can do what I did: Install Leap in a very small spare partition in another disk. 8 or 9 GB would suffice.
For this job, I think you do not need any: just boot Leap install media: there is an option (or there should be, I have not looked or I don't remember) to boot a very small text rescue image. Very few tools, but enough for the procedure I described. If you don't have any, download the NET install disk for the same Leap as you are recovering.
O.K. up to here I am with you. Just will need the live DVD.
Right.
yast:
(notice that it runs yast from the installed system, not from the rescue system)
So then why do you say the live media must be openSUSE rather than Mageia? The way I understand chroot, only the kernel plus the content of the bind mounts comes from the booted media, while the rest, including YaST2, comes from the chrooted-to filesystem. So you say, if I am e.g. using Mageia 6 live (which I did up to now) and do
In data giovedì 9 novembre 2017 13:49:18 CET, Felix Miata ha scritto: the commands as of above, I should be able to start yast. Would be perfect. I think I will try. Or I can try the commands with the "rescue system" of leap install media, but I have the feeling I can do more stupid things there (I am able to mount unmount and use the CLI but it takes more concentration and IMO there is a larger margin for PEBKAC errors.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-09 a las 07:49 -0500, Felix Miata escribió:
Carlos E. R. composed on 2017-11-09 12:51 (UTC+0100):
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
No, it must be an openSUSE disk because you intend to fire up YaST.
???...
You can try with the rescue ISO for 13.2, or the one for TW (yes, there is one, I don't know if it is finished).
Or you can do what I did: Install Leap in a very small spare partition in another disk. 8 or 9 GB would suffice.
For this job, I think you do not need any: just boot Leap install media: there is an option (or there should be, I have not looked or I don't remember) to boot a very small text rescue image. Very few tools, but enough for the procedure I described. If you don't have any, download the NET install disk for the same Leap as you are recovering.
O.K. up to here I am with you. Just will need the live DVD.
Right.
yast:
(notice that it runs yast from the installed system, not from the rescue system)
So then why do you say the live media must be openSUSE rather than Mageia? The way I understand chroot, only the kernel plus the content of the bind mounts comes from the booted media, while the rest, including YaST2, comes from the chrooted-to filesystem.
Same kernel, same libs, same versions, same directories. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloE10wACgkQja8UbcUWM1z3NQEAjmpZK8IaSaXUusPv19ONBIaQ 0zAuRiITNB+sgbiP9TwBAJ6WKQL9C7lvPt4GvgY08C9ar/PdyV3T+XjKazAPKXko =UJxw -----END PGP SIGNATURE-----
Carlos E. R. composed on 2017-11-09 23:31 (UTC+0100): ...
(notice that it runs yast from the installed system, not from the rescue system)
So then why do you say the live media must be openSUSE rather than Mageia? The way I understand chroot, only the kernel plus the content of the bind mounts comes from the booted media, while the rest, including YaST2, comes from the chrooted-to filesystem.
Same kernel, same libs, same versions, same directories.
Hence, as long as there isn't an obstacle on account of some obscure absence or conflict in the substituted kernel, the libs, software versions and directories are those needed, thos on the 42.3 repair target chrooted to, where the Grub repair is needed, not those on the rescue media. Absent a kernel incompatibility, it should not matter what distro is on the live media, which is effectively bypassed while in the chroot. Without actually testing the specific distro media suggested, I would expect a lot better likelihood of repair success from a live Mageia release using a matching 4.4 kernel version and Grub version than I would from a 4 years older live openSUSE 13.1 kernel 3.11 or 3 years older live openSUSE 13.2 kernel 3.16, with their correspondingly older Grubs, directory structure, software versions, and libs. Less than a week ago I did a chroot across distros, from Debian Stretch, but I don't remember to what (or for what), whether an openSUSE, a Mageia, or a Fedora. Whichever it was, it got the job done. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-11-10 00:35, Felix Miata wrote:
Carlos E. R. composed on 2017-11-09 23:31 (UTC+0100): ...
(notice that it runs yast from the installed system, not from the rescue system)
So then why do you say the live media must be openSUSE rather than Mageia? The way I understand chroot, only the kernel plus the content of the bind mounts comes from the booted media, while the rest, including YaST2, comes from the chrooted-to filesystem.
Same kernel, same libs, same versions, same directories.
Hence, as long as there isn't an obstacle on account of some obscure absence or conflict in the substituted kernel, the libs, software versions and directories are those needed, thos on the 42.3 repair target chrooted to, where the Grub repair is needed, not those on the rescue media. Absent a kernel incompatibility, it should not matter what distro is on the live media, which is effectively bypassed while in the chroot.
Without actually testing the specific distro media suggested, I would expect a lot better likelihood of repair success from a live Mageia release using a matching 4.4 kernel version and Grub version than I would from a 4 years older live openSUSE 13.1 kernel 3.11 or 3 years older live openSUSE 13.2 kernel 3.16, with their correspondingly older Grubs, directory structure, software versions, and libs.
You can use the small live rescue system in the Leap install media.
Less than a week ago I did a chroot across distros, from Debian Stretch, but I don't remember to what (or for what), whether an openSUSE, a Mageia, or a Fedora. Whichever it was, it got the job done.
Mmm. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
In data giovedì 9 novembre 2017 12:51:12 CET, Carlos E. R. ha scritto:
Content-ID: <alpine.LSU.2.21.1711091243250.32342@Telcontar.valinor>
On Thursday, 2017-11-09 at 09:52 +0100, stakanov wrote:
In data giovedì 9 novembre 2017 00:25:46 CET, Carlos E. R. ha scritto:
Well, can you boot the system? I guess not.
No, it gives the error as of above.
sdc2 and sdc5 are extrange. :-?
This is easily explained. The Acronis Software for windows is a backup programm that creates a proprietary formatting on the disk and compresses data with it. Therefore only Acronis Software can access this system backup. Linux certainly can not nor can grub.
Right, I understand that it manages the *contents* of the partition, raw. But what it can not manage is the partition definition itself, not if the resulting partition is inconsistent with others.
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sde1 * 0 5,130,239 5,130,240 0 Empty /dev/sde2 304 8,495 8,192 ef EFI (FAT-12/16/32)
/dev/sde1 overlaps with /dev/sde2 <=================
GUID Partition Table detected, but does not seem to be used. <==============
Partition Attrs Start Sector End Sector # of Sectors System /dev/sde1 0 5,129,515 5,129,516 Data partition (Windows/Linux) /dev/sde2 304 8,495 8,192 Data partition (Windows/Linux)
There are problems with sde.
Well, that I am subscribing without hesitations. I should not even have an sde disc!
It is very small, 28,9 GiB
Boot an openSUSE live system. Mount sdb6 on /mnt, for instance.
Well, this is a main problem, how to find a openSUSE live system as AFAIK, leap does not have one. If I take TW I am not sure a) that it exists b) that it will be compatible , TW is quite far from current leap 42.3. Would live DVD of Mageia do.... I do not know that either.
No, it must be an openSUSE disk because you intend to fire up YaST.
You can try with the rescue ISO for 13.2, or the one for TW (yes, there is one, I don't know if it is finished).
Or you can do what I did: Install Leap in a very small spare partition in another disk. 8 or 9 GB would suffice.
For this job, I think you do not need any: just boot Leap install media: there is an option (or there should be, I have not looked or I don't remember) to boot a very small text rescue image. Very few tools, but enough for the procedure I described. If you don't have any, download the NET install disk for the same Leap as you are recovering.
Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
cd /mnt chroot /mnt yast (text mode)
O.K. up to here I am with you. Just will need the live DVD.
Right.
yast:
(notice that it runs yast from the installed system, not from the rescue system)
navigate to the section on boot, and change the configuration to be correct: install generic MBR on sdb, install grub in "/dev/sdb3", mark it bootable (it already is), install grub files in /dev/sdb6
Is this the yast menu point: "personalized boot partition"?
More or less, I know how to do it but not from memory.
Notice that grub has to be installed "partially" in the extended partition, and the files in a logical partition.
This part I do not understand. How would I do this?
Ok, I will look later at how my laptop is done, because I don't remember; but I have to do it later, I can't access it right now.
I think once I manage to do all this, it would be nice to migrate only linux to a new ssd and then to format and reuse the former system disc. But I do not know if this is possible to do this without a fresh install. (it is just that he has a lot of specific graphics programms installed (believe it or not, he is using blender and other programs. So I would like to avoid to have to search for all programms installed again.
Perfectly possible, I did it myself less than a month ago.
P.S. thank you for your help. Also thank you to Andrei.
Welcome :-)
-- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar)
This is somewhat complicated. I get (with either option rescure leap and mageia) the following answer: mount.bin: mount point /mnt/proc does not exist. Do I have to create manually a folder with the corresponding names in /mnt in order to do this? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LSU.2.21.1711092336170.26583@minas-tirith.valinor> El 2017-11-09 a las 17:47 +0100, stakanov escribió:
In data giovedì 9 novembre 2017 12:51:12 CET, Carlos E. R. ha scritto:
Content-ID: <alpine.LSU.2.21.1711091243250.32342@Telcontar.valinor> On Thursday, 2017-11-09 at 09:52 +0100, stakanov wrote:
In data giovedì 9 novembre 2017 00:25:46 CET, Carlos E. R. ha scritto:
Well, can you boot the system? I guess not.
...
Boot an openSUSE live system. Mount sdb6 on /mnt, for instance.
...
For this job, I think you do not need any: just boot Leap install media: there is an option (or there should be, I have not looked or I don't remember) to boot a very small text rescue image. Very few tools, but enough for the procedure I described. If you don't have any, download the NET install disk for the same Leap as you are recovering.
Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
cd /mnt chroot /mnt yast (text mode)
O.K. up to here I am with you. Just will need the live DVD.
This is somewhat complicated. I get (with either option rescure leap and mageia) the following answer: mount.bin: mount point /mnt/proc does not exist.
Do I have to create manually a folder with the corresponding names in /mnt in order to do this?
You get that error because you have not mounted the targed root partition *in* /mnt. Do an "ls /mnt" and you should see your root filesystem. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloE2IQACgkQja8UbcUWM1yftgD/Wt5l0cIIYWIimkFOTH1GY0ch K4G5seI3xN+iYR4pYMYA/1tb845j1tvU7/ZlxQkVgqHu+GebPoBNrWbsQPWN3afj =EdBj -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-09 a las 12:51 +0100, Carlos E. R. escribió:
On Thursday, 2017-11-09 at 09:52 +0100, stakanov wrote:
In data giovedì 9 novembre 2017 00:25:46 CET, Carlos E. R. ha scritto:
Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
cd /mnt chroot /mnt yast (text mode)
O.K. up to here I am with you. Just will need the live DVD.
Right.
yast:
(notice that it runs yast from the installed system, not from the rescue system)
navigate to the section on boot, and change the configuration to be correct: install generic MBR on sdb, install grub in "/dev/sdb3", mark it bootable (it already is), install grub files in /dev/sdb6
...
This part I do not understand. How would I do this?
Ok, I will look later at how my laptop is done, because I don't remember; but I have to do it later, I can't access it right now.
Here goes: (watch out for possible line wrap at your end) YaST2 - menu @ minas-tirith.valinor ┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ YaST Control Center │ └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ ┌────────────────────────────────┐ ┌───────────────────────────────────────────────────────────────────────────────┐ │Software │ │/etc/sysconfig Editor │ │System │ │Boot Loader <=================== │ │Hardware │ │Date and Time │ │Network Services │ │Fonts │ │Security and Users │ │Kernel Settings │ │Virtualization │ │Language │ │Support │ │Network Settings │ │Miscellaneous │ │Partitioner │ │ │ │Services Manager │ │ │ │ │ ... │ │ │ │ └────────────────────────────────┘ └───────────────────────────────────────────────────────────────────────────────┘ [Help] [Run][Quit] F1 Help F9 Quit YaST2 - bootloader @ minas-tirith.valinor Boot Loader Settings ┌Boot Code Options──Kernel Parameters──Bootloader Options───────────────────────────────────────────────────────────┐ │ ================ Boot Loader │ │ GRUB2▒▒▒▒▒▒▒▒▒↓ │ │ │ │ │ │ ┌Boot Loader Location───────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │ [ ] Boot from Boot Partition │ │ │ │ [ ] Boot from Master Boot Record │ │ │ │ [x] Boot from Extended Partition │ │ │ │ [ ] Custom Boot Partition │ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ │ [ ] Set active Flag in Partition Table for Boot Partition │ │ │ │ │ │ [x] Write generic Boot Code to MBR │ │ │ │ │ │ [ ] Enable Trusted Boot Support │ │ │ │ │ │ [Edit Disk Boot Order] │ │ │ YaST2 - bootloader @ minas-tirith.valinor Boot Loader Settings ┌Boot Code Options──Kernel Parameters──Bootloader Options───────────────────────────────────────────────────────────┐ │ =================== │ │ │ │ Timeout in Seconds [x] Probe Foreign OS │ │ ↓ 8↑ <========= (1) │ │ [ ] Hide Menu on Boot │ │ │ │ │ │ Default Boot Section │ │ openSUSE Leap 42.2▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒↓ │ │ │ │ │ │ ┌[ ] Protect Boot Loader with Password──────────────────────────────────────────────────────────────────────────┐ │ │ │ [x] Protect Entry Modification Only │ │ │ │ Password for GRUB2 User 'root' Retype Password │ │ │ │ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ │ │ │ └───────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ │ │ (1) Changing the Timeout in seconds just 1 second forces the whole thing to be saved to disk on exit. It is a trick to force reinstall of grub with YaST. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloE1vQACgkQja8UbcUWM1xOswD7BWeD4G4OBoL6a7Y03/c3CafW dd7ETdOTG4G+XwDxOW8BAJztXtZzg81sMUyjGV/nvz8XGphC8HRG6mFQUHkG0PHT =4oJk -----END PGP SIGNATURE-----
In data giovedì 9 novembre 2017 23:30:05 CET, Carlos E. R. ha scritto:
El 2017-11-09 a las 12:51 +0100, Carlos E. R. escribió:
On Thursday, 2017-11-09 at 09:52 +0100, stakanov wrote:
In data giovedì 9 novembre 2017 00:25:46 CET, Carlos E. R. ha scritto:
Do: mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys mount --bind /dev /mnt/dev
cd /mnt chroot /mnt yast (text mode)
O.K. up to here I am with you. Just will need the live DVD.
Right.
yast:
(notice that it runs yast from the installed system, not from the rescue system)
navigate to the section on boot, and change the configuration to be correct: install generic MBR on sdb, install grub in "/dev/sdb3", mark it bootable (it already is), install grub files in /dev/sdb6
...
This part I do not understand. How would I do this?
Ok, I will look later at how my laptop is done, because I don't remember; but I have to do it later, I can't access it right now.
Here goes:
-- Cheers Carlos E. R.
(from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith))
Thank so much, I will put it into my "library of solutions". I solved with the BIOS setting. As told below, I will have still to debug three fail messages during boot. Help will be appreciated. BTW. The "update experience from 42.2 to 3 was astonishing rough. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
09.11.2017 00:59, stakanov пишет:
In data mercoledì 8 novembre 2017 18:16:15 CET, Andrei Borzenkov ha scritto:
08.11.2017 18:22, stakanov пишет: [... trimming so I am not jumped on by self-appointed police of this list ...] [Well said. I hope that is not too much trimmed. Maybe there is an important netiquette on this too....?]
Start with telling us what is your boot disk.
O.K. First of all: this is "my" system, in the sense that I took care for it. It is my fathers system at my parents home. To be honest I had not to care too much because it just worked. Historically it was a windows system so this is what explains a few of the weirdo things here. Discs are sda, sdb, sdc, and sdd. Initially the sdb was the windows one and was the first disc but after a repair it turns out that: sda is in one only partition of 298 GB and should bear only data with NFTS partition (windows) The sdb was historicall the first disc running with win. sdb 1 160GB NTFS (seems the "own data of users" Windows sdb 2 110GB NTFS (old system disk of Win) Then the partitioner shows: sdb6 with 40 GB ext4 (leap root) sdb7 with 2 GB ext4 (leap swap) sdb5 with 153 GB (? - I do not really recall if this got /var or /home or if it was abandoned. I think it is part of home as LVM, it is ext4) sdc is windows data disc, all dedicated to backup Acronis (so it should not enter in the problem). sdd is 1.8 TB of data with user /home
The system should start from sdb, as I have not a /boot, the MBR therefore.
I cannot parse this sentence.
Why it did have another location or MBR is not known to me, with 42.2 it booted normally, with 42.3 it stopped to work. And I did not change any setting in yast since at least 12.2. I hope that was somewhat understandable.
All this information is in BIS output. What BIS cannot know is what disk your BIOS boots from. You still did not answer that. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 9 novembre 2017 18:53:15 CET, Andrei Borzenkov ha scritto:
09.11.2017 00:59, stakanov пишет:
In data mercoledì 8 novembre 2017 18:16:15 CET, Andrei Borzenkov ha scritto:
08.11.2017 18:22, stakanov пишет: [... trimming so I am not jumped on by self-appointed police of this list ...]
[Well said. I hope that is not too much trimmed. Maybe there is an important netiquette on this too....?]
Start with telling us what is your boot disk.
O.K. First of all: this is "my" system, in the sense that I took care for it. It is my fathers system at my parents home. To be honest I had not to care too much because it just worked. Historically it was a windows system so this is what explains a few of the weirdo things here. Discs are sda, sdb, sdc, and sdd. Initially the sdb was the windows one and was the first disc but after a repair it turns out that: sda is in one only partition of 298 GB and should bear only data with NFTS partition (windows) The sdb was historicall the first disc running with win. sdb 1 160GB NTFS (seems the "own data of users" Windows sdb 2 110GB NTFS (old system disk of Win) Then the partitioner shows: sdb6 with 40 GB ext4 (leap root) sdb7 with 2 GB ext4 (leap swap) sdb5 with 153 GB (? - I do not really recall if this got /var or /home or if it was abandoned. I think it is part of home as LVM, it is ext4) sdc is windows data disc, all dedicated to backup Acronis (so it should not enter in the problem). sdd is 1.8 TB of data with user /home
The system should start from sdb, as I have not a /boot, the MBR therefore.
I cannot parse this sentence.
Why it did have another location or MBR is not known to me, with 42.2 it booted normally, with 42.3 it stopped to work. And I did not change any setting in yast since at least 12.2. I hope that was somewhat understandable.
All this information is in BIS output. What BIS cannot know is what disk your BIOS boots from. You still did not answer that.
LOL, this is because I am tarded :-) I looked into the BIOS. So: sda is the fist boot device in the BIOS. sdb is only the second in boot order. If I change the boot order to sdb as first device, can that work already? Could it be so easy? So to answer your question: sda is the boot device HDD boot priority in order 1. SCSI-1 : HD321KJ 2. SCSI-2 : HD502HI 3. SCSI-0 : WDC WD20EYRX-00D 4. SCSI-3 : WD2500JS-00MHB0 sorry that it took so long for me to understand. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
09.11.2017 21:32, stakanov пишет:
In data giovedì 9 novembre 2017 18:53:15 CET, Andrei Borzenkov ha scritto:
09.11.2017 00:59, stakanov пишет:
In data mercoledì 8 novembre 2017 18:16:15 CET, Andrei Borzenkov ha scritto:
08.11.2017 18:22, stakanov пишет: [... trimming so I am not jumped on by self-appointed police of this list ...]
[Well said. I hope that is not too much trimmed. Maybe there is an important netiquette on this too....?]
Start with telling us what is your boot disk.
O.K. First of all: this is "my" system, in the sense that I took care for it. It is my fathers system at my parents home. To be honest I had not to care too much because it just worked. Historically it was a windows system so this is what explains a few of the weirdo things here. Discs are sda, sdb, sdc, and sdd. Initially the sdb was the windows one and was the first disc but after a repair it turns out that: sda is in one only partition of 298 GB and should bear only data with NFTS partition (windows) The sdb was historicall the first disc running with win. sdb 1 160GB NTFS (seems the "own data of users" Windows sdb 2 110GB NTFS (old system disk of Win) Then the partitioner shows: sdb6 with 40 GB ext4 (leap root) sdb7 with 2 GB ext4 (leap swap) sdb5 with 153 GB (? - I do not really recall if this got /var or /home or if it was abandoned. I think it is part of home as LVM, it is ext4) sdc is windows data disc, all dedicated to backup Acronis (so it should not enter in the problem). sdd is 1.8 TB of data with user /home
The system should start from sdb, as I have not a /boot, the MBR therefore.
I cannot parse this sentence.
Why it did have another location or MBR is not known to me, with 42.2 it booted normally, with 42.3 it stopped to work. And I did not change any setting in yast since at least 12.2. I hope that was somewhat understandable.
All this information is in BIS output. What BIS cannot know is what disk your BIOS boots from. You still did not answer that.
LOL, this is because I am tarded :-) I looked into the BIOS. So: sda is the fist boot device in the BIOS. sdb is only the second in boot order.
If I change the boot order to sdb as first device, can that work already? Could it be so easy?
Yes, I expect it to boot in this case. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 9 novembre 2017 19:40:59 CET, Andrei Borzenkov ha scritto:
Yes, I expect it to boot in this case.
O.K. it is official I am tarded. The BIOS setting solved the issue. I would have never thought at the BIOS. Still I am not sure that I really did understand why grub legacy with the same settings worked...and grub2 didn't. Anyway, now it works and I can repair all the "damage" from failed migration (post did not migrate, I had archives fortunately). Same for passwords, server settings, all email had to be set up. The rest seems to work but I get three error messages at boot: postfix transport server failed to start kernel modules failed to load and a third one that I do not recall at the moment. Will try to open a thread on this to get rid of the error and speed up boot, maybe you will have an input on the kernel module thing. See you then in case. Anyway,Большое спасибо! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-09 a las 21:05 +0100, stakanov escribió:
In data giovedì 9 novembre 2017 19:40:59 CET, Andrei Borzenkov ha scritto:
Yes, I expect it to boot in this case.
O.K. it is official I am tarded. The BIOS setting solved the issue. I would have never thought at the BIOS. Still I am not sure that I really did understand why grub legacy with the same settings worked...and grub2 didn't. Anyway, now it works and I can repair all the "damage" from failed migration (post did not migrate, I had archives fortunately).
I do a full backup (image) before upgrades. If things go badly, I restore backup and try again solving the problem appropriately.
Same for passwords, server settings, all email had to be set up. The rest seems to work but I get three error messages at boot: postfix transport server failed to start kernel modules failed to load
Maybe you need mkinidrd. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloE3JAACgkQja8UbcUWM1ylMwD/SCyFw8yn4JhqMRDVbg4REx77 6+CZ43UcLuO4dcEV7bUBAILrq27VTCXitTd9PPmrwuSV+rVR7eBe+PECjKbcdLCt =Sfm1 -----END PGP SIGNATURE-----
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Felix Miata -
gumb -
Patrick Shanahan -
stakanov -
Wols Lists