Sid update/upgrade seems to mess with other partitions in same drive??

este.el.paz · 2019/10/12, 03:16:17

Gents, et al:
Second time in a week after running a standard "apt update; apt dist-upgrade" in my Siduction install, seems like something is getting "modified" in grub such that on restart and trying to switch to another linux partition, the name or location of the partition has been changed from, e.g., sdb8 to sda8 . . . showing the name of the system correctly, "OpenSUSE TW" but clicking on it just runs a short dmesg window and then stalls . . . fails to load the GUI.
Rebooting today I found the same thing, where Siduction is in "sdb" but the partition gets renamed to "sda" . . . Siduction is the top hit in Grub and it seems to boot itself, but not others???
A few days back I had to boot to . . . ubuntu-mate . . . and then run "update-grub" and that brought all the systems back into proper grub alignment . . . but PITA to have to do that after every Siduction upgrade?

Any thoughts on how to get Siduction to play with others on grub?

unklarer · 2019/10/12, 09:47:55

Quote from: este.el.pazAny thoughts on how to get Siduction to play with others on grub?

Since you do not provide any useful information, I assume that both grubs (depending on the update) are present in the MBR in your configuration.

- start siduction AND reinstall Grub into the MRB. Run update-grub and make sure that os-prober works correctly.

- restart and select ubuntu. Remove the execution rights from the file /etc/grub.d/30_os-prober.
Then install its grub into the PBR of the partition.
Update the whole thing with update-grub

este.el.paz · 2019/10/12, 16:27:40

@unklarer:
Good name, very clear . . . so OK, yes, not enough information, it was a quick dash after finding a recurring problem . . . running on a '12 Mac Pro, so we don't use MBR . . . and this is multi-boot with multi-disk . . . . The Siduction install is in the same disk as two OpenSUSE and possibly two OSX installs; and the ubuntu installs are in another disk that I pointed grub to that EFI, which is why I think I can boot ubuntu after Siduction seems to "re-write" its grub config???

I think another problem is that the official sda has OSX 10.14 and that is the new format APFS, and that doesn't show up as a named install in the ubuntu "update-grub" . . . but it still identifies that the linux installs are in sdb and sdc . . . but seemingly Siduction writes itself as being in the top position and is bootable, but writes the two other linux installs in the same disk as "somewhere else" . . .

Stuff to do this morning, but I can look through your suggestions later, but I don't see this as a "problem with ubuntu interfering with Siduction" because when I ran "update-grub" last night in ubuntu it found the systems and had them in the right disks. But seems like a "Siduction problem" that "finds itself, considers its disk as "#1" but moves everybody elses, what "IUUD" numbers to another place that doesn't exist?

Possibly because of the APFS format in what is the real sda??

I may try to move that disk to #4 slot and see if that "helps" Siduction to again play well with others . . . but, this is a new problem in the last week, as previously all of the systems and disks were as they are now, and no problem with grub launching . . . I trace it to Siduction because after two update/dis-upgrades grub lost track of where stuff is, etc.

unklarer · 2019/10/12, 21:48:25

Grub didn't lose the overview, you did!

Yes, and you still don't provide relevant information.

Yes, and at EFI I'm already out.

melmarker · 2019/10/12, 22:44:32

@unklarer - unfortunately there is only one way with calamares and UEFI not to install a bootloader - manual partitioning and leave the EFI partition out - should work (Source: Demm, KaOS) - will file a bug report about soon, just talked with the upstream maintainer.

@este.el.paz ^^ - so it will take a while, sorry for the mess.

este.el.paz · 2019/10/12, 22:51:46

Quote from: unklarer on 2019/10/12, 21:48:25
Grub didn't lose the overview, you did!

Yes, and you still don't provide relevant information.
Yes, and at EFI I'm already out.

Alrighty, thanks for the post, very "helpful" . . . much more clarity has been offered--still don't know what info needs to be provided to be "relevant" to the post.

After that last post i made I rebooted and found that grub lists the three linux installs that are actually in sdb, as being in "sda" . . . but still sees the "third" disk where the ubuntu installs are as "sdc" rather than "sdb" . . . and that I think was after I had run "update-grub" in U-MATE . . . so I was able to use the grub menu to select the other ubuntu install in disk three, but the OpenSUSE partitions that are in disk two were still listed as "sda" . . . and likely will not boot.
@melmarker:
Just saw your post as I was about to upload mine . . . alrighty, thanks . . . this isn't a fresh install, but it is a fresh problem. So what is the suggestion to just let Siduction alone for awhile before running another update/upgrade?

dibl · 2019/10/13, 02:15:45

Quote from: este.el.paz... still don't know what info needs to be provided to be "relevant" to the post. ....

For "hdd mixup" type problems:

Code Select

# fdisk -lu

and

Code Select

# blkid -c /dev/null -o list are a good place to begin.

este.el.paz · 2019/10/13, 02:36:14

@dibl:
Alrighty, thanks for that data, when I get back into Siduction I'll post back with it. Playing with a Leap 15.2 Alpha install in my laptop at the moment . . . usual "alpha" stuff . . . some good and some not good, etc.

melmarker · 2019/10/13, 04:09:44

@este.el.paz - mixed up disk names should not be a problem, nobody sane use them today

The real problem is UEFI together with how Installers work.

There should be only one installation which manage the boot - right now this is not easy possible with Calamares. So the problem is known, but not fixed yet. Don't know the other possible installers if they do it right.

Talked with calamares upstream today about:

Quote
2019-10-12 19:56:00 <agaida> [ade]: just stumbled upon again
2019-10-12 19:56:03 <agaida> https://i.imgur.com/Xg0LFbz.png - uefi
2019-10-12 19:56:03 <agaida> https://i.imgur.com/Fo9y1yM.png - legacy
2019-10-12 19:56:32 <agaida> it should be possible for uefi __not__ to run a grub install
2019-10-12 19:57:40 <agaida> should i open a new issue for it, not found anything matching
2019-10-12 20:31:13 <[ade]> yes, open an issue (but as with all these UEFI / grub specifics, it hurts my brain)
2019-10-12 20:44:08 <crazy> agaida: [ade] I can't really remember but I think the InstallPath for bootloader is only used for !EFI
2019-10-12 20:49:30 <crazy> [ade]: agaida https://github.com/calamares/calamares/issues/517
2019-10-12 21:01:09 <agaida> oh - such a young one

So there will be a solution in near future - at least for calamares, dunno about other installers.

este.el.paz · 2019/10/14, 01:42:55

@dibl:
Ran those commands, there was a bunch of "RAM" data showing some 15 items that were "64 MB"?? I deleted that data, because I thought we were looking at the HDD partitions . . . which these commands seem to be showing properly, it is the "sdb" disk that Siduction is in "sdb5" and /home is sharing possibly "sdb9" . . . .

But, it still is in Grub where the other installs in sdb are labeled as "sda" and don't load, only Siduction loads . . . .

@melmarker: OK, thanks, still not exactly following on the "calamares" data, as the install was run a few months back, etc. But, I'll stay tuned . . . it does seem like maybe the "update-grub" move in ubuntu did work, as after several minutes of black screen I was able to log into an sdb partition that was named as "sda" in Grub, this time it worked to get to GUI.

dibl · 2019/10/14, 19:00:57

Yes, I distro-surfed for awhile, years ago when I first started using Linux. It's good to try a variety of distros and find what best suits you and your work requirements. But I also remember the hassles with Grub, which apparently haven't improved over the years. I've been happy with my one OS for quite a few years now, and don't have to think about Grub any more.

The best guide that I know for working with Grub is here.

melmarker · 2019/10/14, 19:07:35

Grub has improved a lot - user and normal developer knowledge not

este.el.paz · 2019/10/14, 19:37:56

@dibl && melmarker:
Thanks for the replies, it's just for sh*ts & giggles to have a number of choices, "variety is the spice of life," etc.

Well, I spoke too soon, the disk that has problems "sdb" . . . that shows up in the "lsdisk" or whatever I attached as "sdb" but shows up in Grub as "sda" . . . continues to have "issues" but only with the latest install, which is OS TW running the nouveau driver, there selecting "sda8" brought a demsg like window that froze and didn't break through to the GUI even after waiting for 8 minutes. Whereas, the install that predates the Siduction install on that disk, the Gecko Rolling MATE install, grub shows it as "sda7" rather than where it actually is in "sdb7" . . . with Nvidia drivers installed, about 3.5 minutes of black "booting blind" window then breaks through to the GUI . . . .

I since rebooted into U-MATE and again ran "update-grub" which it did, then it loaded a bunch of "grub-efi" packages . . . but I have the U-MATE/Lubuntu installs pointed to "sdc" EFI . . . which is why they are unaffected by the Siduction upgrades . . . but then may not be in fact reaching over to "sdb" . . . ?? It's a bit complicated, but "odd" that two of the three installs on "sdb" are booting, albeit slowly . . . but not the latest OpenSuSe install . . . . Whereas before the recent Siduction update/upgrade all 5 linux installs were accessible via Grub . . . .

este.el.paz · 2019/10/25, 23:08:27

Quote from: melmarker on 2019/10/13, 04:09:44
@este.el.paz - mixed up disk names should not be a problem, nobody sane use them today The real problem is UEFI together with how Installers work.

There should be only one installation which manage the boot - right now this is not easy possible with Calamares. So the problem is known, but not fixed yet. Don't know the other possible installers if they do it right.

Talked with calamares upstream today about:
Quote
2019-10-12 19:56:00 <agaida> [ade]: just stumbled upon again
2019-10-12 19:56:03 <agaida> https://i.imgur.com/Xg0LFbz.png - uefi
2019-10-12 19:56:03 <agaida> https://i.imgur.com/Fo9y1yM.png - legacy
2019-10-12 19:56:32 <agaida> it should be possible for uefi __not__ to run a grub install
2019-10-12 19:57:40 <agaida> should i open a new issue for it, not found anything matching
2019-10-12 20:31:13 <[ade]> yes, open an issue (but as with all these UEFI / grub specifics, it hurts my brain)
2019-10-12 20:44:08 <crazy> agaida: [ade] I can't really remember but I think the InstallPath for bootloader is only used for !EFI
2019-10-12 20:49:30 <crazy> [ade]: agaida https://github.com/calamares/calamares/issues/517
2019-10-12 21:01:09 <agaida> oh - such a young one

So there will be a solution in near future - at least for calamares, dunno about other installers.

@melmarker:
Just wondering if there is any "update" on this thread as far as some distortion to the grub listing that seemed to come into play with a Siduction update/upgrade that somehow "lost" one distro, but not the other that is installed on the same disk?

Siduction appears to be the "controller" of grub on that disk, but this was not from running an install, but possibly the sequelae of that install; another distro was added after the Siduction install and rather than that one takiing over Grub, Siduction seemed to hold onto it, but then "break" the ID so that it doesn't boot . . . .

Has @agaida come up with anything that might show up in another run of apt update/upgrade in Siduction or that is still in the tubes?
thnx.

melmarker · 2019/10/26, 00:16:01

all i had to say is sayed - and if i ever here stories about "sda" or "sdb" three things might happend:

a) it might be that i run away screeming
b) it might be that i get angry
c) it might be that i get angry and run away screeming

So please do us a favour and don't let it come so far - and please never ever use or talk about "sda" or "sdb" - i don't know the internal implementation of Apples UEFI - but a normal UEFI loader should look like that:

Code Select


# efibootmgr -v                                                                                                                                                                      :(
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,0000,0003,0004
Boot0000* Windows Boot Manager  HD(1,GPT,fb9d1a2b-6546-463c-a6ca-32f29fd8c720,0x800,0x113000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* siduction     HD(1,GPT,fb9d1a2b-6546-463c-a6ca-32f29fd8c720,0x800,0x113000)/File(\EFI\siduction\grubx64.efi)
Boot0002* debian        HD(1,GPT,fb9d1a2b-6546-463c-a6ca-32f29fd8c720,0x800,0x113000)/File(\EFI\debian\shimx64.efi)
Boot0003* arch  HD(1,GPT,fb9d1a2b-6546-463c-a6ca-32f29fd8c720,0x800,0x113000)/File(\EFI\arch\grubx64.efi)
Boot0004* Hard Drive    BBS(HD,,0x0)AMGOAMNO........u.C.r.u.c.i.a.l._.C.T.5.2.5.M.X.3.0.0.S.S.D.1....................A.................................>..Gd-.;.A..MQ..L. . . . . . . . .6.1.4.4.4.1.2.8.D.5.9.9......AMBOAMNO........o.C.r.u.c.i.a.l._.C.T.5.2.5.M.X.3.0.0.S.S.D.1....................A...........................>..Gd-.;.A..MQ..L. . . . . . . . .6.1.6.4.4.1.F.A.3.7.5.E......AMBOAMNO........o.C.r.u.c.i.a.l._.C.T.5.2.5.M.X.3.0.0.S.S.D.1....................A...........................>..Gd-.;.A..MQ..L. . . . . . . . .6.1.8.3.3.1.6.F.2.7.E.F......AMBOAMNO........o.S.a.m.s.u.n.g. .S.S.D. .8.4.0. .P.R.O. .S.e.r.i.e.s....................A...........................>..Gd-.;.A..MQ..L.1.S.R.2.E.N.D.A.2.1.8.8.7.3. .N. . . . ......AMBOAMNO........o.S.a.m.s.u.n.g. .S.S.D. .8.5.0. .E.V.O. .2.5.0.G.B....................A...........................>..Gd-.;.A..MQ..L.2.S.P.1.X.N.G.A.3.8.2.8.5.7. .X. . . . ......AMBOAMNO........o.S.T.3.0.0.0.V.N.0.0.0.-.1.H.J.1.6.6....................A...........................>..Gd-.;.A..MQ..L. . . . . . . . . . . . .6.W.1.A.Z.P.P.D......AMBOAMNO........o.S.T.3.0.0.0.V.N.0.0.0.-.1.H.J.1.6.6....................A...........................>..Gd-.;.A..MQ..L. . . . . . . . . . . . .6.W.2.A.Q.4.Y.Y......AMBO

and this loader points to the efi dir at exactly this drive :
HD(1,GPT,fb9d1a2b-6546-463c-a6ca-32f29fd8c720,0x800,0x113000)/File(\EFI\siduction\grubx64.efi)

thats all - basically - and it would be nice if ther would be only one linux entry - hmm - maybe two, one as fall back. One will see that siduction is my default loader - right now cala can mess this up, not the best idea ever. Second thing that can happend: the nvram filesystem is simply full after some time, can lead to funny bugs - one can google for it.