And now, for the long awaited sequel to "botched Ubuntu update": "Botched grub config"!
Uncategorized
13
Posts
4
Posters
0
Views
-
@yuki2501 temporarily manually edit the grub config in your root partition to do the proper thing on your actual daily driver computer (whle booted into kubuntu 19), then boot into the normal install on your daily driver machine, and re-regenerate the grub config from there?
@sys64738 but I can't boot the normal install until the grub config is updated under /boot/grub (I only edited the grub config under /etc/grub). The update part is what I need to do.
-
@sys64738 but I can't boot the normal install until the grub config is updated under /boot/grub (I only edited the grub config under /etc/grub). The update part is what I need to do.
@yuki2501 yes, connect the drive onto kubuntu 19 machine, mount its /boot partition somewhere, and edit the grub config there manually so you can boot your regular linux install
-
@yuki2501 yes, connect the drive onto kubuntu 19 machine, mount its /boot partition somewhere, and edit the grub config there manually so you can boot your regular linux install
@yuki2501 alternatively, with the 'e' key you can edit a grub boot option so you can do a one-time edit to make it boot maybe?
-
@yuki2501 alternatively, with the 'e' key you can edit a grub boot option so you can do a one-time edit to make it boot maybe?
@sys64738 It seems that I couldn't communicate my situation correctly.
The editing part is easy. Already mounted and everything. How do I tell grub-update to compile the configs and generate the boot files in media/originalpartition while my root is from the USB thumb drive?
-
@sys64738 It seems that I couldn't communicate my situation correctly.
The editing part is easy. Already mounted and everything. How do I tell grub-update to compile the configs and generate the boot files in media/originalpartition while my root is from the USB thumb drive?
@yuki2501 no, I was trying to tell you to edit the files that reside in your boot parittion and normally get generated by grub-update, so you can boot in your regular install instead to then do the fixing & running grub-update again
-
@yuki2501 no, I was trying to tell you to edit the files that reside in your boot parittion and normally get generated by grub-update, so you can boot in your regular install instead to then do the fixing & running grub-update again
@yuki2501 this would sidestep the entire "what does grub think my root drive is" issue
-
@sys64738 It seems that I couldn't communicate my situation correctly.
The editing part is easy. Already mounted and everything. How do I tell grub-update to compile the configs and generate the boot files in media/originalpartition while my root is from the USB thumb drive?
@yuki2501
You can change root ;) you know - chroot etc -
@yuki2501 this would sidestep the entire "what does grub think my root drive is" issue
@yuki2501 but yeah as the other reply said, you can also mount hte root partition from kubuntu 19, chroot to it, mount the other partitions of that system inside the chroot, and then run grub-update
-
@yuki2501 but yeah as the other reply said, you can also mount hte root partition from kubuntu 19, chroot to it, mount the other partitions of that system inside the chroot, and then run grub-update
@yuki2501 (going to sleep now though, it's past 3am here. goo luck!)
-
And now, for the long awaited sequel to "botched Ubuntu update": "Botched grub config"!
I had tried to add a GRUB_BADRAM parameter to my grub environment and it failed spectacularly: Now NOTHING BOOTS! Not even the grub prompt!
I managed to find an old Kubuntu 19 boot USB and managed to remove the offending line from the grub text config (under /etc/grub) file in my HDD.
But now I don't know how to update grub under /boot...
Edit: SOLVED!
@yuki2501 mount your Ubuntu install under, say, /mnt, mount your boot partition on /mnt/boot, then
chroot /mnt, if you regenerate your grub config from there it should work -
And now, for the long awaited sequel to "botched Ubuntu update": "Botched grub config"!
I had tried to add a GRUB_BADRAM parameter to my grub environment and it failed spectacularly: Now NOTHING BOOTS! Not even the grub prompt!
I managed to find an old Kubuntu 19 boot USB and managed to remove the offending line from the grub text config (under /etc/grub) file in my HDD.
But now I don't know how to update grub under /boot...
Edit: SOLVED!
I did it!!!
I followed the instructions at https://askubuntu.com/questions/145241/how-do-i-run-update-grub-from-a-livecd
and managed to restore my grub.
I can boot again!!! : 🥳
-
undefined oblomov@sociale.network shared this topic on
Gli ultimi otto messaggi ricevuti dalla Federazione
-
PR for the curious : https://github.com/Nuand/bladeRF/pull/1052
-
Remember when I said driver development isn't linear ? Here is another chapter.
I have had a bladeRF SDR for years. Brought to Morocco, where returning defective hardware isn't really an option - you get what you get. And what I got, I thought, was a slightly defective unit. Sending it oversea cost more than just ordering another.
The DC offset calibration was always a bit off:
Calibrated @ 347500000 Hz: I= 944 (Error: 3.44), Q=1328 (Error: 3.47)
Error values around 3.4? Not great, not terrible. But not what you want from a $400 SDR. I eventually gave up, shoved it in a closet, and bought a HackRF instead. The bladeRF sat there for years, collecting dust, while Nuand dropped the price and I told myself I'd gotten a lemon from a bad batch.
Then I tested it on FreeBSD.
Calibration failed immediately. Timeout errors everywhere. But that's what led me to the bug.
libusb_handle_events_timeout() returns LIBUSB_ERROR_TIMEOUT when the timeout expires with no events. That's not an error, the function working as documented. But the bladeRF driver was treating it as unexpected:
if (status < 0 && status != LIBUSB_ERROR_INTERRUPTED) {
log_warning("unexpected value from events processing...");
status = error_conv(status);
}That error_conv() call was corrupting the event loop timing. On Linux, the calibration "completed" — but with garbage results. The bug didn't blow up. It just silently poisoned the data.
One two-line fix:
if (status < 0 && status != LIBUSB_ERROR_INTERRUPTED &&
status != LIBUSB_ERROR_TIMEOUT) {After the fix:
Calibrated @ 347500000 Hz: I= 944 (Error: 0.41), Q=1328 (Error: 0.42)
My "defective" SDR now calibrates perfectly.
The hardware was never broken. The driver bug silently corrupted calibration for years. I spent years thinking I had bad hardware because error values of 3.4 looked like "marginal hardware" rather than "broken software."
FreeBSD didn't fix my SDR but testing on FreeBSD forced me to actually debug the problem instead of living with silent corruption.
Pushed the fix upstream. If your bladeRF calibration has always been "a bit off", try this patch.
-
Non è Lercio. Però qualcuno lo è. Prossimamente nel DSM, la profilazione della sinistra radicale.
(Corriere)
-
@Tionisla I've never seen a different kind of car dealers.
-
Scorza: “Il 2026 sulle barricate per difendere regole e democrazia”
La rivolta anti-regolazione del 2025 punta a far dettare le “regole” dalla tecnologia. Le norme restano lo scudo dei diritti: innovazione vera è distribuire i benefici a tutti
-
Le guerre di Putin, l’ex boss del potassio russo Baumgertner scomparso a Cipro
Il giorno dopo, strano "suicidio" in ambasciata russa a Nicosia. Il retroscena su @LaStampa
-
@stefano damn, seems car dealers all over the world are after all car dealers :-)
-
@Tionisla wow, what a story! Yes, rear traction. I was used to that kind of traction, so I knew how to manage it. But that car's suspensions were totally depleted.
