Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: hendrikL on 2023/09/08, 11:52:33
-
German/Deutsch weiter unten!
Update (2024-01-10 | 10. January 2024):
If you didn't update (apt full-upgrade) your system since September 2023, than this is still needed/ relevant!
Wenn Euer System seit letztem September (2023) nicht auf den neuesten Stand gebracht wurde (apt full-upgrade), so ist dieses hier noch relevant!
Holding off on upgrade since before this issue started, will there be a time when a regular DU will just work without intervention? Thanks.
Cliff
You can full-upgrade, dist-upgrade or nala upgrade, depends on what you prefer!
But, if you have the btrfs-filesystem in use, first do
apt update
apt install siduction-scripts
after it you can run
apt full-upgrade (or what you prefer)
Maybe you need afterwards an "apt -f install" if something went wrong!
Do not reboot yet!
Before rebooting, please run
grub-install /dev/foo (foo= your Harddisk like sda or what ever)
update-grub
On an UEFI systems you do not need to address the device!
Now you should be on the save side to reboot!
Good luck!
##################
Man kann einen "full-upgrade", einen "dist-upgrade" oder einen "nala upgrade" durchführen, je nachdem, was bevorzugt wird!
Wenn das btrfs-Dateisystem verwendet wird, sollten zuerst die "siduction-scripts" installiert werden
apt update
apt install siduction-scripts
Danach erst folgendes ausführen!
apt full-upgrade (oder was bevorzugt wird)
Vielleicht braucht es danach ein "apt -f install", wenn etwas schief gelaufen ist!
Noch nicht neu starten!
Vor dem reboot/ Neustart folgendes ausführen:
grub-install /dev/foo (foo= deine Festplatte wie sda oder was auch immer)
update-grub
Bei einem UEFI-System muß das Device nicht angegeben werden!
Jetzt sollten Sie auf der sicheren Seite sein und neu starten können!
Viel Glück
-
Many Thanks !
Just did a fresh install (2023.1.0) on a new PC.
This information worked perfectly and saved my day !
Bruno
-
Vielen Dank für die kurze und prägnante Anleitung. Upgrade ist auf allen Systemen problemlos durchgelaufen. :)
-
Glücklicherweise sollten so langsam alle ihre Installationen wieder zum Laufen gebracht haben, bzw. sollte es jetzt reibungslos möglich sein.
Es sollte aber auch eine Mahnung sein, immer ein aktuelles Boot-Medium eines Siduction-Isos parat zu haben. Und man sollte seine Partitionierung kennen bzw. wissen, wie man sie sich anzeigen (und gegebenenfalls anpassen) kann. Ich selbst nutze ja gerne gparted, auch wenn es nachinstalliert werden muss.
Mich hatte es ja auch mit voller Breitseite erwischt. Ich war gerade dabei, mein System neu zu organisieren. Wollte eine Neuinstallation aufsetzen, als es mir mein altes System unbootbar machte, die Neuinstallation nach einem dist-upgrade ebenso im Nirvana versank und die ersten Lösungsansätze auch nicht funktionieren wollten. Ich war halt ein früher Vogel, sprich vor den ersten Warnungen schon betroffen. Der chroot-helper war auch nicht so ohne Weiteres nutzbar, da meine Shell in einer anderen Partition (/usr) ausgelagert war.
Gut, waren halt wieder ein paar Fingerübungen. Graue Haare kann ich keine mehr bekommen, sind schon alle grau.
Am Ende zeigt sich aber auch, welche Vorteile ein Linux-System in solchen Situation hat. Ich mag mir nicht vorstellen, wie ein Windows-Nutzer in einer vergleichbaren Situation dastehen würde.
Einen schönen Restsonntag noch.
edlin
-
... gparted, auch wenn es nachinstalliert werden muss.
Ich plädiere auch, gparted wieder in die "Grundausstattung" aufzunehmen, (wie es ja in Wintersky noch war!)
Dickes Lob wieder für die siduction-Support-Mannschaft, insbesondere für diesen Post!
Greetings
Tom
-
... gparted, auch wenn es nachinstalliert werden muss.
Ich plädiere auch, gparted wieder in die "Grundausstattung" aufzunehmen, (wie es ja in Wintersky noch war!)
Zustimmung zur (Wieder-)Aufnahme von gparted: +1.
Dickes Lob wieder für die siduction-Support-Mannschaft, insbesondere für diesen Post!
Dem stimme ich ebenfalls intensivst zu!
-
gparted: Ganz so schlimm ist es nicht. KDE-Plasma und LXQt bringen das Qt-Pendant partitionmanager mit und in Xfce ist gparted noch drin.
Ansonsten sollten wir das in „Ideas & Improvements“ diskutieren.
edlin
-
Unfortunately I still can't boot. Before or after a fresh install. The system just freezes when running grub-install in the chroot helper. I can use the live usb to boot the installed system but the result is the same. I'm not sure what's going on here. It was a perfectly running laptop before the grub glitch. I may try another live system outside of siduction just to see if there is a difference.
-
Mh, did you try to chroot by hand without the help of the chroot-helper? Efi or legacy Bios?
-
Nvidia?
-
I haven't tried to manually chroot yet. This is an old Intel based Acer with Intel graphics.
-
Same problem, solved by identifying which partition was efi, in my case sda/2. Used Super-Grub2 to get my first system up and then as root ran grub-install sda/2, then update-grub now I can boot from all distro's on my machine. It worked for me, don't know if it will help solve your issue, good luck.
tommy2
-
@eriefisher
or, wait, intel, did you try :
from our release notes
With some Intel graphics processors on some devices, the system may freeze shortly after booting into Live. To fix this, you must set the kernel parameter intel_iommu=igfx_off before rebooting.
-
Yes, I tried the boot code. No difference. I can get into the installed system with the use of a live iso and it runs fine. The problem is trying to install grub. The system just freezes up whether I run live and chroot or running the installed system. It takes about 15-20 seconds from the enter key and full lock up.
If I attempt to boot normally I just get " no bootable device". I can't figure out what's causing the lock up. Same happens on a fresh install. Everything goes fine until installing the bootloader and it freezes up.
-
...
If I attempt to boot normally I just get " no bootable device". ...
I once had that error, when I installed the OS on an early PCI-bus SSD. The BIOS on that motherboard didn't recognize that SSD as being a bootable device, and there was no fix available. To work around the issue, I installed /boot and grub on a small hdd and the rest of the OS on the SSD, and then it was fine.
Have you successfully booted an OS from that drive before?
-
Yes, this laptop has been running suction for several years now. The first install had some trouble with grub but a second install about a year and a half ago went without issue.
-
[...]
If I attempt to boot normally I just get " no bootable device". I can't figure out what's causing the lock up. Same happens on a fresh install. Everything goes fine until installing the bootloader and it freezes up.
I really think, that this "no bootable device" could be the key. What happens, when grub thinks it can install to the/a boot device and this does not answer? It hangs!? It is just difficult to analyze.
When you have an idea, let us hear it and proceed according to it.
Otherwise I would suggest to get us some information from the live system: What does "efibootmgr -v" say? An "ls -l /dev/x" could give us some insight too, where x is sd* and nvme*. Then an lsblk and "lsblk -f" might be of use. Finally the partition structure of the (future) boot device (something like "fdisk -l /dev/sda" or "fdisk -l /dev/nvme0n1" (assumption sda or nvme0n1 is the designated boot device)) tells us, where the EFI boot partition resides.
If you like, you can also install another boot-manager. "rEFInd" helped me a lot.
From my ideas, either the boot partition "vanishes", then you can not access any (boot-)manager at restart or the boot-disk becomes inactive (for whatever reason) or the second boot-manager kicks in, should "grub" be the culprit part.
Good luck!!!
-
The information requested. I hope someone can see something I don't. This is from the running system booted from a usb stick.
root@siducer:/home/dan# efibootmgr -v
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot0000* USB HDD: Generic USB Storage PciRoot(0x0)/Pci(0x15,0x0)/USB(3,0)/HD(2,GPT,817baa94-9d4a-4016-a775-f71f3dab0d9f,0xd4,0x1680)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
root@siducer:/home/dan# ls -l /dev/sda
brw-rw---- 1 root disk 8, 0 Sep 12 17:47 /dev/sda
root@siducer:/home/dan# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 300M 0 part /boot/efi
├─sda2 8:2 0 58.8G 0 part /
├─sda3 8:3 0 3.9G 0 part [SWAP]
└─sda4 8:4 0 402.8G 0 part /media/dan/DATA
sdb 8:16 1 14.9G 0 disk
└─sdb1 8:17 1 14.9G 0 part /media/dan/7597-EA86
root@siducer:/home/dan# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
│ vfat FAT32 EFI B756-5D7B 299.3M 0% /boot/efi
├─sda2
│ ext4 1.0 root f93d1610-2664-426c-885d-b4b32351563e 47.1G 13% /
├─sda3
│ swap 1 SWAP 68057ccd-9b8e-447b-8ee5-d060a5b3816a [SWAP]
└─sda4
ext4 1.0 DATA 0dd547a7-fc11-4f13-8c1c-2c29163c0bd4 349.3G 7% /media/dan/DATA
sdb
└─sdb1
vfat FAT32 7597-EA86 11.4G 24% /media/dan/7597-EA86
root@siducer:/home/dan# fdisk -l /dev/sda
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WD5000LPCX-2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 0B72D56E-CCE6-489D-9557-BFE8ADC11514
Device Start End Sectors Size Type
/dev/sda1 2048 616447 614400 300M Microsoft basic data
/dev/sda2 616448 123930623 123314176 58.8G Linux filesystem
/dev/sda3 123930624 132122623 8192000 3.9G Linux swap
/dev/sda4 132122624 976773119 844650496 402.8G Linux filesystem
root@siducer:/home/dan#
-
Thank you!
Well, there is a little bit, I can be detect:
BootOrder: 2001,2002,2003
Boot0000* USB HDD: Generic USB Storage PciRoot(0x0)/Pci(0x15,0x0)/USB(3,0)/HD(2,GPT,817baa94-9d4a-4016-a775-f71f3dab0d9f,0xd4,0x1680)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
Although you have a device "sda", which I assume is an internal disk (HD or SSD), there is no entry for it in the EFI boot list, at least not yet! The Boot0000 is your USB-Stick, which is ok, since you booted from it (successfully) and the entries "2001-2003" are just some other devices (possible USB-attachment, optical drive, and network).
If it stays like this, it is no wonder, that the message after a reboot is "no bootable device". With the stick gone, there is no entry for your disk!
Normally, grub-install will/should add an entry here, but this can be suppressed, e.g. by the "--no-nvram" option.
Otherwise your disk-configuration seems alright. There is an EFI-partition (sda1) and a root one (sda2).
If the installation data actually do get on that disk, I am sure it would boot, once there is an entry in the EFI-vars list.
If it gets stuck, the next time, you could check after the next boot from the stick, if boot files did actually get on the EFI-partition from the previous grub-install. From your lsblk-listing, it gets (correctly) mounted to /boot/efi. If you look around there (with "ls"), you should find an EFI/siduction subdirectory. If present, and containing .efi-files, grub-install worked up until here, at least. With a little bit of luck, there is also an EFI/BOOT directory. If so, and when there is not a "just BOOT" directory in /boot/efi already, then copy the EFI/BOOT to that (just BOOT) place. This would help to boot that disk similar to the stick at the next reboot. It would be a stop gap only, but can help, if grub-install did not create a propper disk entry in the EFi-vars list. We would still have to find out, why this is so, though, if it is the case.
May be, hopefully, my suspicion about the hard disk failing is incorrect, and grub-install simply does not succeed in creating an EFI boot entry and just "hangs" there every time.
So far my findings and "recipe" for now.
Again, good luck!!!
-
There's a few *buggy* UEFI implementations that don't create the proper boot entries or an EFI in the right place. @rosid's post is one good workaround.
-
This is some kind of manufacture/hardware/firmware issue. I just tried to install rEFInd and it froze the system up. I'm going to try some bios adjustments.
-
Well I'm giving up for a while on this thing. I pulled out an old HP with siduction on it. It hasn't been updated for a few months now. It has a power port issue so it got shelved. I fired it up, did a dist-upgrade and rebooted. Grub starts but the laptop won't boot. Grub_load_image not found.
Fired up the latest live usb and did a grub-install and update-grub. Then an update and dist-upgrade then reboot. No boot.
I don't get it. Two very different machines with totally different hardware. If the grub issue has been sorted out what the heck is going on.
-
Well, try to install rEFInd there, too. It is totally independent of grub. If you succeed, grub is somehow responsible, but then you can start siduction via grub and we can "work" on grub. If not, then it is not the boot-manager.
Try to turn off a CSM, at least temporarily, to guarantee EFI boot.
By the way: Is "secure boot" accidentally 'on'?
There is still a lot of debugging potential (for both hardware systems), if you are adventurous enough :) (e.g. we can try to "manually" make an EFI entry via efibootmgr).
-
I tried rEFInd. It installed without error. However, when I rebooted it tried to use grub and failed. Reboot a live system and purged everything grub, reinstalled rEFInd and rebooted, grub still starts up and fails.
Getting late here and I'm burnt out and out of laptops. I'll have another look in the morning.
-
Ok, we shall track this down :), starting with the HP, where rEFInd works.
I am away for the better part of tomorrow, or more appropriately, today (Thursday), though; thus I can not "react", until later.
Still: good luck!!!
-
@erifisher:
What model of an HP do you have.
I recently renewed the encrypted Installation of my HP8470p completely after 5 years.
Run quite into difficulties with the strange HP UEFI-BIOS and had to restore some directories from the backup of the EFI partition.
Especially, the "boot" directory and/or the "bootx64.efi" file in the root directory of it seems to be required.
Regards
Reiner
-
I managed to get the HP up and running again via a fresh install. While I was running live I did and apt update/dist-upgrade then started the install. I allowed the installer to wipe all the partitions and let it go. Everything completed without error and rebooted cleanly. I hated to reinstall but I can work on getting it set up the way it was, maybe better.
Now I just have to deal with the Acer. I'll start another thread for that one once I get going on it. Thanks for all the input. It's great to have the support of other users.
-
hi all,
i was also hit by this issue today morning.
in my case UEFI was activated all the time (MSI mainboard), but the efibootmgr listed more than 200 boot options, and had to be cleaned up. how and why they appeared - i do not know. the relevant entries were these two:
--> old EFI from siduction_2021.3.0 original installation of the operating system
--> new EFI siduction which came with the grub upgrade
looping over all not necessary entries with the following command, helped me get that cleaned
efibootmgr -b <bootnumber> -B
setting the boot order did not persist on my machine
so, what i have now is this, and it works
root@sidbox:~# efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002
Boot0001* siduction HD(1,GPT,473c0e32-f3b7-6740-909e-271626ab25c3,0x1000,0x96000)/File(\EFI\SIDUCTION\GRUBX64.EFI)
Boot0002* UEFI: Samsung SSD 860 EVO 500GB, Partition 1 PciRoot(0x0)/Pci(0x17,0x0)/Sata(4,65535,0)/HD(1,GPT,473c0e32-f3b7-6740-909e-271626ab25c3,0x1000,0x96000)..BO
thanks to ro_sid for the right pointer. thanks to the whole community. you rock.
best
absolut
-
I had to update the "Bios" of my ASRock Z77 Pro3 from 2.10 to 2.20 to solve the Problem of no boot systems on the second SSD with EFI Partition on the first SSD.
-
Ran into this fun bug on an old HP craptop I honestly didn't even remember might be affected.
Sure enough, found myself staring at the UEFI screen following a DU+reboot. For bonus points, using chroot-helper+grub-install+update-grub on a live usb with siduction-2023.1.1-Standing_on_the_Shoulders_of_Giants-kde-amd64-202401191500.iso didn't work (iso from testbuilds).
The commands ran as expected without errors, then reboot and faced with a sad grub rescue screen:
error: symbol `grub_disk_native_sectors' not found.
Thankfully, boot-repair-disk managed to sort it. Flashed a spare usb stick with the image, clicked the auto fix button and let it do its thing. Rebooted and all was fine again. No idea why chroot-helper came up short though. Sharing my adventure in case someone else ran into the same weirdness.
The tool: https://sourceforge.net/projects/boot-repair-cd/
Repair log: https://paste.debian.net/hidden/19f72847
-
I ran into this months old issue the same day you did on my wife's PC, that had not been updated in six months or so.I had totally forgotten about this issue, since i did not run into it in the first place on my devices.
So, thanks to your report, I threw siduction image and boot-repair-disk on my Ventoy stick and had at it. Fortunately, chrooting in and taking care of GRUB2 was enough. But good to know, boot-repair-disk sorts it out with a click if needed.
-
hey, joined the group of affected users today with my mum's notebook... Now downloading the repair-tool ;) Thank you for the hint!
(somehow i have to manage to look into "upgrade warnings" before hitting "apt-get dist-upgrade"...)
-
Hello everyone!
Just registered to describe what I experienced/did.
Did a dist-upgrade and lost all grub boot screen decoration, only ASCII art now. But that would have been fine if the system would boot. Which it didn't.
So I used a live medium to boot (still wintersky, maybe that is another problem), chrooted, grub-install, update-grub: No dice. Still not booting.
I'll have tell some background on me: I started using Linux with SuSE 8.0 (now called openSUSE), had to deal with Ubuntu Desktops and "Servers" at work (Their server distributions don't really serve a purpose in my opinion) and then switched to Aptosid. - Took me a few releases to get that they are really unfriendly (I just agreed to my posts not being insulting... >:( ). Finally found out that there was a certain fork focusing on the wishes and problems of the community. Absolutely loved PaintItBlack! So here I am.
Now I'm a freak and occasionally back up my system partition. (Call it "System Restore Point" if you like. Some of it may be related to bad experiences in the past.) In any case it just takes a boot from a live medium and like 10 more Minutes of extracting a tarball, chrooting, grub installing and updating and I'm back to some working state.
Found the forum and read the Install Warning. (Never got the hint to look this up before... :o) ) The additional grub-install; update-grub after the dist-upgrade showed no errors but the system still did not boot.
So I did that: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051271 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051271) In my case there were six grub packages that I downgraded. Since in chroot the resolution of the packages failed for some reason, I just got dem directly from the debian repo to the partition and used dpkg to install them, grub-install; update-grub and I was back to a booting system.
Currently, the system is up to date except for grub.
Maybe that will help somebody else. Used this manual to chroot: https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#chroot-Methode (https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#chroot-Methode) (Their server distributions are no good but their manuals definitely are.) Since /etc/mtab is a link, I moved it to /etc/mtab.lnk before the cp command and back before rebooting.