1:31 p.m.
Hello all.
I need some help.
Firstly: Please forgive the formatting - I'm new to this medium and not sure what the
accepted conventions are, the HyperKitty interface is ...very basic. Also please forgive
the length, I just don't know how to make it shorter without losing potentially
relevant detail. If I've asked this in the wrong place, by all means punt my backside
in the direction of the right place.
I seem to have got myself in a bit of a mess and I’ve having trouble finding documentation
that I can apply directly to my case . This is my first time on Linux so I’m not familiar
with much of the terminology or background of these systems.
**Background**
I have an internal drive that used to successfully dual boot windows and a LUKS-encrypted
F36 installation with BTRFS.
I also had some spare unpartitioned space, which I used to fully install some other linux
distros (including another F36 installation) to troubleshoot other minor problems (a
tri-boot, so to speak)
**What went wrong**
The new distros installed fine, but I discovered afterwards I could no longer find/boot
into my original LUKS F36 installation. In my igornance, I tried deleting clearing the new
installation partitions, and now, if I select the Fedora option thru my BIOS boot menu, I
just get to a 'grub> ’ prompt.
I’ve tried a few commands there to boot manually but nothing worked and it wouldn’t even
decrypt the root partition, worse still, somehow this process accidentally wiped the
ORIGINAL LUKS F36 /boot partition too. I have no idea how.
**What I have now**
Partitioning follows:
nvme0n1p1: EFI partition (both win and DF36)
nvme0n1p2: MS Reserved
nvme0n1p3: Win10
nvme0n1p5: Original Fedora /boot (accidentally wiped)
nvme0n1p6: LUKS volume
nvme0n1p7: Former ‘third OS’ boot partition (wiped)
nvme0n1p8: Former ‘third OS’ root partition (also wiped)
nvme0n1p4: Win Recovery
**What I am trying to do**
Unbork everything, somehow?
I tried using these instructions in the official Fedora Docs, but they seem to be …wrong?
Out of date? They didn’t work, I suspect due to LUKS/BTRFS. [
https://docs.fedoraproject.org/en-US/Fedora/23/html/Multiboot_Guide/commo...]
The I found these...other Fedora Docs? Which seemed more up to date and looked like they
had relevant bits, bit still seem directly applicable and didn't work.
[https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#r...]
The only success I’ve had is with this guide:
https://fedoramagazine.org/os-chroot-101-covering-btrfs-subvolumes/ .
I’ve managed to chroot (a very dumb word) thru a LiveUSB session, with the following
commands:
>cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt
>mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root
>mount /dev/mapper/fedora_crypt /mnt/home -t btrfs -o subvol=home
>mount /dev/nvme0n1p5 /mnt/boot
>mkdir /mnt/boot/efi
>mount /dev/nvme0n1p1 /mnt/boot/efi
>mount --bind /dev /mnt/dev
>mount -t proc /proc /mnt/proc
>mount -t sysfs /sys /mnt/sys
>mount -t tmpfs tmpfs /mnt/run
>mkdir -p /mnt/run/systemd/resolve/
>nano /mnt/run/systemd/resolve/stub-resolv.conf (enter 'nameserver 1.1.1.1',
save)
>chroot /mnt
I can ping google, and browse the original home folder with ls, so it looks like ‘im in’
the original installation via chroot (which is still a dumb word)
What the problems are
From there, I go back to the Fedora Docs and run
>dnf reinstall grub2-efi grub2-efi-modules shim
That seems to work? Downloads and seems to install without any errors.
The next step though;
>grub2-mkconfig -o /boot/grub2/grub.cfg
fails with the following:
> /usr/sbin/grub2-probe: error: failed to get canonical path of
‘/dev/mapper/fedora_crypt’
I have no idea what that means.
On the side, I also sees that despite the grub reinstall, theres no vmlinuz or initramfs
kernel files in the reconstructed /boot partition, so I tried running
>dracut --regenerate-all
which results in
>dracut: Can’t write to /boot/efi/[long-ass id code string]/[kernel
version]: Directory /boot/efi/[long-ass id code string]/[kernel version] does not exist or
is not accessible.
This is true - that folder isn’t in /boot/efi. But I dont remember ever seeing it there,
and just to check I did a fresh test install on another drive and theres nothing like that
there either.
So now I’m lost
What I’m looking for
I’m fairly sure the error messages I’m seeing are a result of oversights from my
cobbled-together method and gneral lack of understanding. So if anyone knows what I missed
and how/why, that’d help …but honestly I still really don’t know what’s going on and
suspect I’m probably going to run into another problem just as quick
Really, I’m after some sort of clear, up to date walk-through with entry-level
language/detail, on how exactly to rebuild from scratch the EFI/boot partitions for F36
with a LUKS encrypted root, using BTRFS. I know the installation itself is fine and should
be recoverable, I just dont know how all these different bits fit togther, and none of the
guides out there seem to explain/unify the different bits into a cohesive procedure for
the unfamiliar.
Thanks very much.
1:59 p.m.
On 10/28/22 11:31, Jake D wrote:
I’ve managed to chroot (a very dumb word) thru a LiveUSB session,
with the following commands:
It's better not to call things dumb without understanding. It's short
for CHange ROOT, which does what it says.
>> cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt
>> mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root
>> mount /dev/mapper/fedora_crypt /mnt/home -t btrfs -o subvol=home
>> mount /dev/nvme0n1p5 /mnt/boot
>> mkdir /mnt/boot/efi
>> mount /dev/nvme0n1p1 /mnt/boot/efi
>> mount --bind /dev /mnt/dev
>> mount -t proc /proc /mnt/proc
>> mount -t sysfs /sys /mnt/sys
>> mount -t tmpfs tmpfs /mnt/run
>> mkdir -p /mnt/run/systemd/resolve/
>> nano /mnt/run/systemd/resolve/stub-resolv.conf (enter 'nameserver
1.1.1.1', save)
>> chroot /mnt
>> dnf reinstall grub2-efi grub2-efi-modules shim
That seems to work? Downloads and seems to install without any errors.
The next step though;
>> grub2-mkconfig -o /boot/grub2/grub.cfg
fails with the following:
>> /usr/sbin/grub2-probe: error: failed to get canonical path of
‘/dev/mapper/fedora_crypt’
I have no idea what that means.
What does "ls -l /dev/mapper/fedora_crypt" show?
On the side, I also sees that despite the grub reinstall, theres no
vmlinuz or initramfs kernel files in the reconstructed /boot partition, so I tried running
grub has nothing directly to do with those files.
>> dracut --regenerate-all
which results in
>> dracut: Can’t write to /boot/efi/[long-ass id code string]/[kernel version]:
Directory /boot/efi/[long-ass id code string]/[kernel version] does not exist or is not
accessible.
This is true - that folder isn’t in /boot/efi. But I dont remember ever seeing it there,
and just to check I did a fresh test install on another drive and theres nothing like that
there either.
That's one of the possible places for it to write the files. Did it
find the right place? If not, you'll have to specify the file yourself.
"rpm -q kernel-core"
e.g. kernel-core-5.18.13-200.fc36.x86_64
"dracut /boot/initramfs-5.18.13-200.fc36.x86_64.img 5.18.13-200.fc36.x86_64"
You will also have to re-install the kernel-core package to the vmlinuz
file installed.
At this point, it might just be easier to do a backup and re-install.
2:26 p.m.
What does "ls -l /dev/mapper/fedora_crypt" show?
Do I run this from...'within' the 'chroot' thing, or just in the live USB
after i do 'luks open'?
That's one of the possible places for it to write the files. Did
it
find the right place? If not, you'll have to specify the file yourself.
I don't know? I don't know where or what any of this should be doing, or it
I'm doing the right thing.
"rpm -q kernel-core"
e.g. kernel-core-5.18.13-200.fc36.x86_64
"dracut /boot/initramfs-5.18.13-200.fc36.x86_64.img 5.18.13-200.fc36.x86_64"
You will also have to re-install the kernel-core package to the vmlinuz
file installed.
I'm sorry, I'm not quite understanding the instructions here?
is "rpm -q kernel-core" a command I should run? if so, where/when?
"e-install the kernel-core package to the vmlinuz " may as well be fre nch to me
- I've been using linux for 4 weeks now and I'm sorry but I just don't
understand this rapid fire technical jargon.
At this point, it might just be easier to do a backup and re-install.
Not an option.
If it comes to that, I'm done with my linux experiment. Theres a month of work gone
into fixing all the bugs and glitches and problems I've run into, and the whole reason
this thing started was because I couldn't get snapper to work properly to back up that
work, and I was trying to troubleshoot that by testing it on a clean fresh 'test'
installation, so I wouldn't risk my main one. Instead, it's killed it.
2:50 p.m.
On 10/28/22 12:26, Jake D wrote:
> What does "ls -l /dev/mapper/fedora_crypt" show?
Do I run this from...'within' the 'chroot' thing, or just in the live USB
after i do 'luks open'?
within the chroot.
> That's one of the possible places for it to write the files.
Did it
> find the right place? If not, you'll have to specify the file yourself.
I don't know? I don't know where or what any of this should be doing, or it
I'm doing the right thing.
Do you have any initramfs files in /boot?
> "rpm -q kernel-core"
> e.g. kernel-core-5.18.13-200.fc36.x86_64
> "dracut /boot/initramfs-5.18.13-200.fc36.x86_64.img
5.18.13-200.fc36.x86_64"
> You will also have to re-install the kernel-core package to the vmlinuz
> file installed.
I'm sorry, I'm not quite understanding the instructions here?
is "rpm -q kernel-core" a command I should run? if so, where/when?
Yes. You need to find out which kernel version(s) you have installed in
order to run the following command.
"e-install the kernel-core package to the vmlinuz " may as
well be fre nch to me - I've been using linux for 4 weeks now and I'm sorry but I
just don't understand this rapid fire technical jargon.
First try "dnf upgrade kernel". If there's a new kernel available, then
it's much easier, you don't have to worry about the initramfs or
reinstalling the kernel.
Otherwise, "dnf reinstall kernel-core".
> At this point, it might just be easier to do a backup and
re-install.
Not an option.
If it comes to that, I'm done with my linux experiment. Theres a month of work gone
into fixing all the bugs and glitches and problems I've run into, and the whole reason
this thing started was because I couldn't get snapper to work properly to back up that
work, and I was trying to troubleshoot that by testing it on a clean fresh 'test'
installation, so I wouldn't risk my main one. Instead, it's killed it.
Then you're probably done. This much damage is difficult to repair
without some knowledge about what you're doing. I'm curious about all
the issues you were having because that's unusual. Did you ask here
about those issues?
3:14 p.m.
Do you have any initramfs files in /boot?
Not at present, Like I said, it was wiped
Yes. You need to find out which kernel version(s) you have installed
in
order to run the following command.
I'm sorry, which command? dnf upgrade kernel? Is that also inside chrrot ?
First try "dnf upgrade kernel". If there's a new
kernel available, then
it's much easier, you don't have to worry about the initramfs or
reinstalling the kernel.
Otherwise, "dnf reinstall kernel-core".
I'm having profound difficulty following what command to run under what circumstance,
where, and in what order. The commands have changed multiple times now and I'm
completely lost.
I'm not technically familiar enough to just ... 'know' where to do this. Could
you please explain a clear sequence of what I should run, where, in relation to the steps
I ourtlined in the OP?
Then you're probably done. This much damage is difficult to
repair
without some knowledge about what you're doing. I'm curious about all
the issues you were having because that's unusual. Did you ask here
about those issues?
Thats disappointing. I didnt realise Linux was so fragile. Windows recovery is normally
very easy by comparison
The issues were wide ranging. Much of the course software would not install as described.
Virtual machines were a nightmare and still dont work properly. Lots of hardware
problematic or not supported (display, touchpad, touchscreen) , extremely sluggish
performance, the software center repeatedly crashing and repository issues... a LOT.
I've asked in a few other place and generally got little to no response at all. I had
a dollar for every time people had told me 'thats unusual, Fedora is really
good!', but then having no explanation or solution, I could probably buy a windows
license off eBay and done a different course
As it is, class starts on Monday and my computer wont boot. I'd prefer not to forfeit
my course fee but if this is genuinely unsolvable, I guess I've learned at least one
lesson about Linux....
4:52 p.m.
On 10/28/22 13:14, Jake D wrote:
> Then you're probably done. This much damage is difficult to
repair
> without some knowledge about what you're doing. I'm curious about all
> the issues you were having because that's unusual. Did you ask here
> about those issues?
Thats disappointing. I didnt realise Linux was so fragile. Windows recovery is normally
very easy by comparison
That's funny. Randomly delete some system files and the boot partition
and ask a new user to fix it. Good luck. Almost always, even for not
new users, any serious windows problem is solved by reinstalling the system.
The issues were wide ranging. Much of the course software would not
install as described. Virtual machines were a nightmare and still dont work properly. Lots
of hardware problematic or not supported (display, touchpad, touchscreen) , extremely
sluggish performance, the software center repeatedly crashing and repository issues... a
LOT. I've asked in a few other place and generally got little to no response at all.
I had a dollar for every time people had told me 'thats unusual, Fedora is really
good!', but then having no explanation or solution, I could probably buy a windows
license off eBay and done a different course
I have installed Fedora on a very wide variety of laptops and almost
never had any issues. The only serious issues were an unsupported wifi
card and a BIOS that absolutely insisted on booting windows.
As it is, class starts on Monday and my computer wont boot. I'd
prefer not to forfeit my course fee but if this is genuinely unsolvable, I guess I've
learned at least one lesson about Linux....
Hopefully the lesson is that installing over an existing install is
going to cause some problems with that original install.
Since you've already solved all the problems once, won't it be easy to
redo that? Maybe try asking in here for help, since I can't imagine
what solutions you found and I wouldn't be surprised that random
"solutions" you find online would be causing you even more problems.
6:07 p.m.
That's funny. Randomly delete some system files and the boot
partition
and ask a new user to fix it. Good luck. Almost always, even for not
new users, any serious windows problem is solved by reinstalling the system.
This is demonstrably not true, but also not relevant and I have no interest in getting
bogged down arguing about it.
I have installed Fedora on a very wide variety of laptops and almost
never had any issues. The only serious issues were an unsupported wifi
card and a BIOS that absolutely insisted on booting windows.
Okay...good for you? I don't see how this helps my situation, not why you seem to have
bought it up as if to...deny what I've already observed in my own case?
Hopefully the lesson is that installing over an existing install is
going to cause some problems with that original install.
Yes, although I'm starting to see some wider lessons about the nature of Linux itself
and the discussions around it. But for now I want to focus on fixing my current problem.
Since you've already solved all the problems once, won't it
be easy to
redo that? Maybe try asking in here for help, since I can't imagine
what solutions you found and I wouldn't be surprised that random
"solutions" you find online would be causing you even more problems.
No, a lot of those fixes I frankly dont remember now, and in several cases, I'm not
even sure what I did that actually solved the problem.
And the discussion here so far is very discouraging in terms of getting any productive
advice. I'm trying as hard as I am able to provide as much detail as I can, and keep
up, and everyone seems largely intent on lording as much terminology as they can over me
to gloat at my inability to translate it to meaningful actions, quibbling over side
points, or now, seemingly denying there's a problem in the first place.
Case in point being you own choice to ignore my request to clarify the scatter-shot of
previously mentioned commands, in favor of going on a tangent about how "well, all
my laptops work", as if all you're really interested in is invalidating me for
asking in the first place.
Frankly, it's offputting and more than a little offensive.
6:21 p.m.
On 10/28/22 16:07, Jake D wrote:
Case in point being you own choice to ignore my request to clarify
the scatter-shot of previously mentioned commands, in favor of going on a tangent about
how "well, all my laptops work", as if all you're really interested in is
invalidating me for asking in the first place.
They weren't scatter-shot, but you are lacking the background to
understand them. As (I think) Chris already mentioned, I can't give you
an exact list of commands to run and it will be fixed. You broke some
really low-level bits and it will take someone with detailed knowledge
to walk you through it step by step. And as you've repeatedly stated,
you don't understand these technical explanations, so this isn't going
to work. Really, your only option at this point is a re-install.
2:08 p.m.
On Fri, Oct 28, 2022 at 2:32 PM Jake D <techsupport_accounts(a)riseup.net> wrote:
I’ve managed to chroot (a very dumb word) thru a LiveUSB session,
with the following commands:
>>cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt
>>mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root
>>mount /dev/mapper/fedora_crypt /mnt/home -t btrfs -o subvol=home
>>mount /dev/nvme0n1p5 /mnt/boot
>>mkdir /mnt/boot/efi
>>mount /dev/nvme0n1p1 /mnt/boot/efi
>>mount --bind /dev /mnt/dev
>>mount -t proc /proc /mnt/proc
>>mount -t sysfs /sys /mnt/sys
>>mount -t tmpfs tmpfs /mnt/run
>>mkdir -p /mnt/run/systemd/resolve/
>>nano /mnt/run/systemd/resolve/stub-resolv.conf (enter 'nameserver
1.1.1.1', save)
>>chroot /mnt
Stab in the dark - within the chroot jail maybe it knows about the
mounted *tree* but it doesn't know about the mounts themselves? In
other words, by doing the mounts outside of the chroot, you are
updating /etc/mnttab in the "Live USB" environment, but /etc/mnttab in
the chroot environment is not updated.
If this is the case, maybe doing this will get you farther:
>>cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt
>>mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root
>>mount --bind /dev /mnt/dev
>>mount --bind /dev /mnt/dev
>>mount -t proc /proc /mnt/proc
>>mount -t sysfs /sys /mnt/sys
>>mount -t tmpfs tmpfs /mnt/run
>>chroot /mnt
>>mount /dev/mapper/fedora_crypt /home -t btrfs -o subvol=home
>>mount /dev/nvme0n1p5 /boot
>>mkdir /mnt/boot/efi
>>mount /dev/nvme0n1p1 /boot/efi
>>mkdir -p /run/systemd/resolve/
>>nano /run/systemd/resolve/stub-resolv.conf (enter 'nameserver 1.1.1.1',
save)
Another thing I'm not sure of is whether or not you need something in
the chroot /boot *before* you can use dnf, etc.
Alternative - maybe do a fresh install using the wiped partitions to
get a complete and reasonably valid /boot, and leverage that to find
and boot the LUKS partition?
Never had to do this, so hoping it helps or at least gives ideas.
2:31 p.m.
Stab in the dark - within the chroot jail maybe it knows about the
mounted *tree* but it doesn't know about the mounts themselves? In
other words, by doing the mounts outside of the chroot, you are
updating /etc/mnttab in the "Live USB" environment, but /etc/mnttab in
the chroot environment is not updated.
I'm sorry but I really dont understand the terminology/jargon here.
Are you saying I did the commands in the wrong order? I'm just following the
instructions in the link I included.
Alternative - maybe do a fresh install using the wiped partitions to
get a complete and reasonably valid /boot, and leverage that to find
and boot the LUKS partition?
I did try this, thats how I noticed the vmlinuz , iniramfs files were missing...but
apparenly that doesnt matter?
I'm not sure. I dont really understand.
3:53 p.m.
On Fri, Oct 28, 2022 at 3:31 PM Jake D <techsupport_accounts(a)riseup.net> wrote:
> Stab in the dark - within the chroot jail maybe it knows about
the
> mounted *tree* but it doesn't know about the mounts themselves? In
> other words, by doing the mounts outside of the chroot, you are
> updating /etc/mnttab in the "Live USB" environment, but /etc/mnttab in
> the chroot environment is not updated.
I'm sorry but I really dont understand the terminology/jargon here.
"Live USB" - the environment you are in when booted off the Live USB,
before you enter the "chroot" command
"chroot jail" - the environment you are in after issuing the "chroot"
command
/etc/mnttab - when you issue a "mount" command, information about the
mount is saved in /etc/mnttab. But when you "chroot /mnt", you are in
the "chroot jail", and within that environment you cannot access the
/etc/mnttab from the "Live USB" environment; therefore the "chroot
jail" does not know the *details* about the mounts. Even worse, the
/etc/mnttab file in the "chroot jail" (which is actually
/mnt/etc/mnttab) probably has stale data from the last time the
"chroot jail" environment was actually booted. So from within the
"chroot jail" you can see the directory tree, but you can't see the
details of how they were mounted.
Hope this helps you understand the terminology/jargon.
Are you saying I did the commands in the wrong order? I'm just
following the instructions in the link I included.
I'm saying the order *may* be significant depending on what you want
to do within the "chroot jail". If you are only doing simple file
operations, it may not matter. But when you start doing OS-level
operations it may matter a great deal. And you are attempting
OS-level operations.
2:46 p.m.
On Fri, 2022-10-28 at 18:31 +0000, Jake D wrote:
Firstly: Please forgive the formatting - I'm new to this medium
and
not sure what the accepted conventions are, the HyperKitty interface
is ...very basic.
HyperKitty is a web front-end for what is really a mailing list. Most
people here access the list via a standard mailer rather than the web
interface, which (IMHO) gives better results, including proper quoting.
Just an FYI.
poc
3:21 p.m.
HyperKitty is a web front-end for what is really a mailing list.
Most
people here access the list via a standard mailer rather than the web
interface, which (IMHO) gives better results, including proper quoting.
I 'm not really sure what a "standard mailer" is or what you mean by
'mailing list', and honestly I'm a bit more focused on getting the computer to
boot at all by monday. This was one of the resources on the course material and I'm
asking everywhere I can, I'm a bit frantic frankly.
4:44 p.m.
On Fri, 2022-10-28 at 20:21 +0000, Jake D wrote:
> HyperKitty is a web front-end for what is really a mailing list.
> Most
> people here access the list via a standard mailer rather than the
> web
> interface, which (IMHO) gives better results, including proper
> quoting.
I 'm not really sure what a "standard mailer" is or what you mean by
'mailing list', and honestly I'm a bit more focused on getting the
computer to boot at all by monday. This was one of the resources on
the course material and I'm asking everywhere I can, I'm a bit
frantic frankly.
Never mind.
poc
8:35 a.m.
On Fri, Oct 28, 2022, at 4:21 PM, Jake D wrote:
> HyperKitty is a web front-end for what is really a mailing list.
Most
> people here access the list via a standard mailer rather than the web
> interface, which (IMHO) gives better results, including proper quoting.
I 'm not really sure what a "standard mailer" is or what you mean by
'mailing list', and honestly I'm a bit more focused on getting the
computer to boot at all by monday. This was one of the resources on
the course material and I'm asking everywhere I can, I'm a bit frantic
frankly.
Panic is one of the best known paths to data loss.
Before making any further changes, I advise a backup of important user data. Do not
attempt repair or reinstallation until there's at least two independent copies of your
important data.
--
Chris Murphy
3 p.m.
On Fri, Oct 28, 2022, at 2:31 PM, Jake D wrote:
Hello all.
I need some help.
My opinion: This is probably easier in a live discussion on IRC or Matrix. There's
just too much back and forth required.
But the absolute easiest thing to do is mount the encrypted btrfs, make a backup of the
home directory, and then clean install followed by restoring the home directory files from
the backup.
Otherwise you and at just one other person have to have a fairly intense conversation
about very low level esoterics. Boot is very distro specific. There's maybe two or
three dozen steps to repair this setup. They all have to be exactly correct or it
won't work. Much of this logic is in the installer.
--
Chris Murphy
3:27 p.m.
My opinion: This is probably easier in a live discussion on IRC or
Matrix. There's
just too much back and forth required.
Are these different forums? I just googled 'Fedora matrix 'and I'm getting a
lot of very varied hits
But the absolute easiest thing to do is mount the encrypted btrfs,
make a backup of the
home directory, and then clean install followed by restoring the home directory files
from
the backup.
I understand what you're saying but as I mentioned in a previous comment, I have 4
weeks of setup already in place on this system. Theres not really any files on there worth
covering but more dayd and days of fiddling to get things working, much of which im
sturggling to remember,
Reinstall is essentially a complete writeoff. THeres no way I'll have it setup up
again by Monday, I'll have to withdraw from the class and thats a large course fee
forfeiture I'd rather avoid.
I really can't believe that these Linux systems are so fragile and the ONLY option is
to start over, is there nothing like Resotre Points in windows?
5:27 p.m.
On Fri, 2022-10-28 at 20:27 +0000, Jake D wrote:
I really can't believe that these Linux systems are so fragile
and
the ONLY option is to start over, is there nothing like Resotre
Points in windows?
Hmm, hahaha, is this a troll?
Was there anything ever more self-destructive than Windows? It
regularly shot itself in the foot, you didn't even have to do anything.
Yes, you can have a backup and restore kind of thing on Linux. But you
have to set something up first. If you haven't done that, then you can
boot from something else and put back the files you destroyed. Or you
can re-install.
Windows was exactly the same. If you didn't prepare ahead of time for
the oncoming disaster, your recourse was usually a re-install. With
all the fun and games that involved for your OS and all your programs,
finding all your registration details, or paying for them again because
you can't.
Likewise with Macs. If you want restore points, or whatever name they
call it, you have to set it up beforehand.
I can't say that I've ever hosed a Linux install in the somewhere
around 20 years I've been using it for. But I've had Windows bollix
itself up quite severely, many times. It does it all by itself quite
happily, *you* don't have to be messing around with system files for it
to kill itself. It can mangle its brains simply booting up or shutting
down, and doing a Windows update that it controlled entirely by itself
was another round of russian roulette.
--
NB: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the list.
The following system info data is generated fresh for each post:
uname -rsvp
Linux 5.19.15-201.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 13
18:58:38 UTC 2022 x86_64
6:09 p.m.
No, it's not a troll.
Thank-you for your otherwise completely irrelevant , unsolicited and entirely unhelpful
opinion piece. I'm sorry for not realising Windows upsets you so much and is therefore
inferior, and for daring to ask if Linux has similar recovery functionality, after being
told the only answer is to completely start from scratch. Clearly, I should have realised
immediately that this means it's the more resilient system.
I will immediately stop using my working windows partition and stare at my non booting
"grub> prompt instead. Also can you advise which bridge you wish for me to jump
off as punishment for my question?
12:18 a.m.
On Fri, 2022-10-28 at 23:09 +0000, Jake D wrote:
No, it's not a troll.
It does appear otherwise.
Thank-you for your otherwise completely irrelevant , unsolicited
and
entirely unhelpful opinion piece.
NB: I responded to you in EXACTLY the same way as your opening post.
Go back and read your own first post.
You chucked a tantrum at us and got a telling off. You should expect
that. Judging by your attitude in your posts, you ought to be used to
it.
For anybody to give you a step-by-step set of instructions to unmunge
your system, you'd need to tell us precisely everything you did that
screwed it up in the first place. We're not bloody mind-readers!
And we understand that you may not be able to do that. So your least
painful approach may well be re-install. The system will take care of
making itself work again for you. And nine times out of ten a fresh
installation of Linux just works without you having to tweak it. But
you really need to know where you went wrong, so you don't do the same
thing again.
You've been given advice on where to start. You don't understand it,
that's fair enough. You've been given advice more suited to someone
who's not in a position to dig themselves out of a hole - re-install is
going to be your easiest solution. If you don't want to do that,
you're going to have to learn more about what you're getting into.
Here's some more advice you probably won't like: Multi-booting (any
computer, any OS) can be a pain, and it may be best to only attempt
that after you've learnt how a system works. Your safest approach to
learning a new system is to get a second hard drive, unplug your first
one, install onto a fresh drive in isolation, and learn how the system
works.
--
uname -rsvp
Linux 3.10.0-1160.76.1.el7.x86_64 #1 SMP Wed Aug 10 16:21:17 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
10:34 a.m.
On Sat, Oct 29, 2022, at 1:18 AM, Tim via users wrote:
Here's some more advice you probably won't like:
Multi-booting (any
computer, any OS) can be a pain, and it may be best to only attempt
that after you've learnt how a system works. Your safest approach to
learning a new system is to get a second hard drive, unplug your first
one, install onto a fresh drive in isolation, and learn how the system
works.
Multiboot is probably fragile. Or at least it is inclined toward chaos, in that we cannot
account for everything.
Fedora only tests and blocks releases against Windows and macOS existing first, and Fedora
second. As there's no manifestation of support beyond community support, is anything
supported? We more or less say things that we are willing to block release on are
supported, as in they have to work at the time a version is released. But there's lots
of buts. And one of those buts is, if you're setting up a system in a way we
aren't testing, we certainly aren't going to block release on such edge cases that
affect few users. Triboot is definitely one of those.
But case in point, lets say you have a completely clean system. Install Fedora copy A, and
then you want to do a dual boot of two Fedoras. Say, Fedora Workstation and KDE. Or Fedora
35 and 36. Dual boot Fedoras. Supported? Nope. We have no release criterion for that. Only
bugs that happen independent of that configuration would be blockers, not bugs that only
manifest as part of a dual boot Fedora installation.
--
Chris Murphy
10:22 a.m.
On Fri, Oct 28, 2022, at 7:09 PM, Jake D wrote:
No, it's not a troll.
Thank-you for your otherwise completely irrelevant , unsolicited and
entirely unhelpful opinion piece. I'm sorry for not realising Windows
upsets you so much and is therefore inferior, and for daring to ask if
Linux has similar recovery functionality, after being told the only
answer is to completely start from scratch. Clearly, I should have
realised immediately that this means it's the more resilient system.
I will immediately stop using my working windows partition and stare at
my non booting "grub> prompt instead. Also can you advise which bridge
you wish for me to jump off as punishment for my question?
Multiboot systems are inherently complex. Like, you really have had a train derailment.
And you're asking for help with that as if there's a button you can push to fix
that. There's no button for train derailments. It's a customized recovery every
time that requires esoteric knowledge. Everything about it is manual.
Are trains fragile? I'm not sure that's the best description but yeah once they
start going off the rails it's a catastrophic system.
--
Chris Murphy
11:54 p.m.
On 10/28/22 4:27 PM, Jake D wrote:
I really can't believe that these Linux systems are so fragile
and the ONLY option is to start over
Wanted to hop in here real fast and say:
Pop!_OS, which is my primary distro (with Fedora being my secondary),
has the option to go into recovery (has a small partition just for
up-to-date recovery media) and reinstall your OS without losing any
personal files.
AFAIK, it's one of the only distributions that has something like it.
-srw
12:53 a.m.
On 10/28/22 21:54, Slade Watkins via users wrote:
On 10/28/22 4:27 PM, Jake D wrote:
> I really can't believe that these Linux systems are so fragile and the ONLY
option is to start over
Wanted to hop in here real fast and say:
Pop!_OS, which is my primary distro (with Fedora being my secondary),
has the option to go into recovery (has a small partition just for
up-to-date recovery media) and reinstall your OS without losing any
personal files.
AFAIK, it's one of the only distributions that has something like it.
By default, Fedora does that as well (and probably most current Linux
distros). You can re-install the OS and as long as you use the same
/home partition and don't format it, you won't lose any personal files.
Unless you're referring to the recovery partition, which isn't really
that useful, since you'll likely either still have the original install
media or you'll want to download the latest version anyway.
10:27 a.m.
On Sat, Oct 29, 2022, at 12:54 AM, Slade Watkins via users wrote:
On 10/28/22 4:27 PM, Jake D wrote:
> I really can't believe that these Linux systems are so fragile and the ONLY
option is to start over
Wanted to hop in here real fast and say:
Pop!_OS, which is my primary distro (with Fedora being my secondary),
has the option to go into recovery (has a small partition just for
up-to-date recovery media) and reinstall your OS without losing any
personal files.
AFAIK, it's one of the only distributions that has something like it.
Fedora doesn't have a recovery partition. But there is a (sort of hidden, or at least
non-obvious) way of doing a custom installation while preserving home. There isn't
detailed documentation for it. It's just a test case.
https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_pres...
This is more official than the draft dual boot one I posted previously, in that I try to
keep this one up to date. But it's just a test case, intended for a test setup to make
sure installer functionality isn't lost. It's not really intended as installation
advise. It could be adapted into a Quick Doc for that purpose though.
But my understanding of the original poster's issue is that he now has a bunch of
system level customizations. Not so much user level customizations. Therefore the reuse
home directory method wouldn't help much.
--
Chris Murphy
9:27 a.m.
On Fri, Oct 28, 2022, at 4:27 PM, Jake D wrote:
> My opinion: This is probably easier in a live discussion on IRC
or Matrix. There's
> just too much back and forth required.
Are these different forums? I just googled 'Fedora matrix 'and I'm
getting a lot of very varied hits
https://chat.fedoraproject.org
IRC and Matrix are chat protocols. There's a bridge in place so that, in effect,
you're in the same channel whether you join #fedora on libera.chat (IRC) or #fedora on
fedora.im (Matrix). You can get a native matrix account via element.io or you can get a
Fedora account and use that to connect to Fedora's matrix home server. Why you pick
one vs another depends on how big your matrix presence is, I guess. You're finding
multiple options because of multiple eras: IRC then matrix.org then Fedora got its own
matrix home servers. But you can access them all with any method due to the behind the
scenes bridging. I personally use cmurf:fedora.im (matrix using the Fedora matrix home
servers)
> But the absolute easiest thing to do is mount the encrypted
btrfs, make a backup of the
> home directory, and then clean install followed by restoring the home directory files
from
> the backup.
I understand what you're saying but as I mentioned in a previous
comment, I have 4 weeks of setup already in place on this system.
Theres not really any files on there worth covering but more dayd and
days of fiddling to get things working, much of which im sturggling to
remember,
Reinstall is essentially a complete writeoff. THeres no way I'll have
it setup up again by Monday, I'll have to withdraw from the class and
thats a large course fee forfeiture I'd rather avoid.
OK, there is another option which is a clean install along side the existing installation,
but following this clean install you'll abandon the new root and switch to the old
root that has all your customizations. Basically you'll be doing a clean install just
to get all the nuggets in /boot and /boot/efi in the proper shape. Some post install
surgery will still necessary though...
Is it more complicated to do a modified dual boot where we have two roots and then switch
the roots and make the necessary changes to /etc/fstab and BLS snippets in
/boot/loader/entries? Or just manually create every file we need? Uhhh.... I think
it's probably easier to do the side by side installation, preserving the existing
root. And then abandon the new root, while keeping the replacement /boot/efi/EFI/fedora
and /boot
But that's a guess.
So this is a draft I helped write for having dual boot Fedoras, i.e. two roots.
https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs
That needs a number of modifications for your situation though. So I think before going
down that road we should discuss whether that's really the best option or not.
I really can't believe that these Linux systems are so fragile
and the
ONLY option is to start over, is there nothing like Resotre Points in
windows?
Not automatically and only for the root (/) and home (/home). You've toasted the /boot
volume which is functionally like Windows' system volume that it boots from initially,
if you wipe that, you'd be totally screwed on Windows too. And also these days on
Windows you don't get automatic restore points either, you'd have to have done it
before the mistake.
--
Chris Murphy
7 a.m.
On Fri, Oct 28, 2022 at 5:01 PM Chris Murphy <lists(a)colorremedies.com>
wrote:
On Fri, Oct 28, 2022, at 2:31 PM, Jake D wrote:
> Hello all.
>
> I need some help.
My opinion: This is probably easier in a live discussion on IRC or Matrix.
There's just too much back and forth required.
But the absolute easiest thing to do is mount the encrypted btrfs, make a
backup of the home directory, and then clean install followed by restoring
the home directory files from the backup.
Sound advice.
Otherwise you and at just one other person have to have a fairly intense
conversation about very low level esoterics. Boot is very distro specific.
There's maybe two or three dozen steps to repair this setup. They all have
to be exactly correct or it won't work. Much of this logic is in the
installer.
and differs over time as well as distro, so is hard to deal with for those
of use who have to work with multiple distros and versions.
<https://0pointer.net/blog/brave-new-trusted-boot-world.html> has a summary
of the current linux
boot process, then discusses a proposal for a Unified Kernel Image (UKI)
that is intended to
improve security and simplify the user side of the configuration process.
--
George N. White III
4:53 p.m.
On Oct 28, 2022, at 14:32, Jake D <techsupport_accounts(a)riseup.net> wrote:
Hello all.
I need some help.
Firstly: Please forgive the formatting - I'm new to this medium and not sure what
the accepted conventions are, the HyperKitty interface is ...very basic. Also please
forgive the length, I just don't know how to make it shorter without losing
potentially relevant detail. If I've asked this in the wrong place, by all means punt
my backside in the direction of the right place.
I seem to have got myself in a bit of a mess and I’ve having trouble finding
documentation that I can apply directly to my case . This is my first time on Linux so I’m
not familiar with much of the terminology or background of these systems.
**Background**
I have an internal drive that used to successfully dual boot windows and a LUKS-encrypted
F36 installation with BTRFS.
I also had some spare unpartitioned space, which I used to fully install some other linux
distros (including another F36 installation) to troubleshoot other minor problems (a
tri-boot, so to speak)
**What went wrong**
The new distros installed fine, but I discovered afterwards I could no longer find/boot
into my original LUKS F36 installation. In my igornance, I tried deleting clearing the new
installation partitions, and now, if I select the Fedora option thru my BIOS boot menu, I
just get to a 'grub> ’ prompt.
Well the good news is that if it is booting to a grub prompt, it is most likely not a
problem with the EFI volume, because it is booting into grub. You just need to regenerate
the contents of the /boot volume, which most importantly needs a kernel, an initrd and
some grub configuration files.
When booting off rescue media, make sure you boot it as an EFI device. Some hardware will
default to booting legacy firmware when choosing external media, for some reason.
Check if there is a /sys/firmware/efi/ directory when you’re booted into the rescue media,
otherwise you won’t be able to update the EFI settings for any new bootloader you
install.
I’ve tried a few commands there to boot manually but nothing worked
and it wouldn’t even decrypt the root partition, worse still, somehow this process
accidentally wiped the ORIGINAL LUKS F36 /boot partition too. I have no idea how.
**What I have now**
Partitioning follows:
nvme0n1p1: EFI partition (both win and DF36)
nvme0n1p2: MS Reserved
nvme0n1p3: Win10
nvme0n1p5: Original Fedora /boot (accidentally wiped)
nvme0n1p6: LUKS volume
nvme0n1p7: Former ‘third OS’ boot partition (wiped)
nvme0n1p8: Former ‘third OS’ root partition (also wiped)
nvme0n1p4: Win Recovery
**What I am trying to do**
Unbork everything, somehow?
I tried using these instructions in the official Fedora Docs, but they seem to be …wrong?
Out of date? They didn’t work, I suspect due to LUKS/BTRFS. [
https://docs.fedoraproject.org/en-US/Fedora/23/html/Multiboot_Guide/commo...]
The I found these...other Fedora Docs? Which seemed more up to date and looked like they
had relevant bits, bit still seem directly applicable and didn't work.
[https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#r...]
The only success I’ve had is with this guide:
https://fedoramagazine.org/os-chroot-101-covering-btrfs-subvolumes/ .
I’ve managed to chroot (a very dumb word) thru a LiveUSB session, with the following
commands:
>> cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt
>> mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root
>> mount /dev/mapper/fedora_crypt /mnt/home -t btrfs -o subvol=home
>> mount /dev/nvme0n1p5 /mnt/boot
>> mkdir /mnt/boot/efi
>> mount /dev/nvme0n1p1 /mnt/boot/efi
>> mount --bind /dev /mnt/dev
>> mount -t proc /proc /mnt/proc
>> mount -t sysfs /sys /mnt/sys
>> mount -t tmpfs tmpfs /mnt/run
>> mkdir -p /mnt/run/systemd/resolve/
>> nano /mnt/run/systemd/resolve/stub-resolv.conf (enter 'nameserver
1.1.1.1', save)
>> chroot /mnt
I can ping google, and browse the original home folder with ls, so it looks like ‘im in’
the original installation via chroot (which is still a dumb word)
What the problems are
From there, I go back to the Fedora Docs and run
>> dnf reinstall grub2-efi grub2-efi-modules shim
That seems to work? Downloads and seems to install without any errors.
The next step though;
>> grub2-mkconfig -o /boot/grub2/grub.cfg
fails with the following:
>> /usr/sbin/grub2-probe: error: failed to get canonical path of
‘/dev/mapper/fedora_crypt’
I have no idea what that means.
Most likely the OS didn’t use fedora_crypt as the luks device, so it got hung up there.
I wonder if you could check the /etc/fstab for the device name?
On the side, I also sees that despite the grub reinstall, theres no
vmlinuz or initramfs kernel files in the reconstructed /boot partition, so I tried
running
>> dracut --regenerate-all
which results in
>> dracut: Can’t write to /boot/efi/[long-ass id code string]/[kernel version]:
Directory /boot/efi/[long-ass id code string]/[kernel version] does not exist or is not
accessible.
This is true - that folder isn’t in /boot/efi. But I dont remember ever seeing it there,
and just to check I did a fresh test install on another drive and theres nothing like that
there either.
So now I’m lost
As others have said, it’s missing kernels, so making an initrd is impossible.
dnf reinstall ‘kernel-*’
… should get you back to having all the kernel related packages installed.
What I’m looking for
I’m fairly sure the error messages I’m seeing are a result of oversights from my
cobbled-together method and gneral lack of understanding. So if anyone knows what I missed
and how/why, that’d help …but honestly I still really don’t know what’s going on and
suspect I’m probably going to run into another problem just as quick
Really, I’m after some sort of clear, up to date walk-through with entry-level
language/detail, on how exactly to rebuild from scratch the EFI/boot partitions for F36
with a LUKS encrypted root, using BTRFS. I know the installation itself is fine and should
be recoverable, I just dont know how all these different bits fit togther, and none of the
guides out there seem to explain/unify the different bits into a cohesive procedure for
the unfamiliar.
It sounds like you only wiped the /boot partition, which should be fairly easy to get
back. Reinstalling the kernel and grub2 packages will get you the packaged bits, and
running dracut like you ran should get you the initrd, although only after you’ve got the
kernel.
After everything is reinstalled, then run the grub2-mkconfig command to create the grub
config file in your new /boot partition.
Just make sure you do everything from the chroot in an EFI booted rescue environment,
either on a livecd or booting the NetBoot iso with the rescue option.
--
Jonathan Billings
6:13 p.m.
Well the good news is that if it is booting to a grub prompt, it is
most likely not a
problem with the EFI volume, because it is booting into grub. You just need to
regenerate
the contents of the /boot volume, which most importantly needs a kernel, an initrd and
some grub configuration files.
Thankyou for having one of the more helpful replies. I understand at least this paragraph,
however I'm still quite unsure of the specifics
When booting off rescue media, make sure you boot it as an EFI
device. Some hardware will
default to booting legacy firmware when choosing external media, for some reason.
I believe it is, my BIOS was set to EFI mode, or so I am told.
Check if there is a /sys/firmware/efi/ directory when you’re booted
into the rescue media,
otherwise you won’t be able to update the EFI settings for any new bootloader you
install.
There is, with a collection of files and folders in it.
Most likely the OS didn’t use fedora_crypt as the luks device, so it
got hung up there.
I wonder if you could check the /etc/fstab for the device name?
I could try this, with some more specific instruction on how to do it? I don't recall
having a 'device name' so I dont know really how to find it. Is this also done in
'chroot?'
As others have said, it’s missing kernels, so making an initrd is
impossible.
dnf reinstall ‘kernel-*’
… should get you back to having all the kernel related packages installed.
Starting to have difficulty followiing. I partially recognise this command, but i have no
idea where/when to use it, or what the correct result should look like.
It sounds like you only wiped the /boot partition, which should be
fairly easy to get
back. Reinstalling the kernel and grub2 packages will get you the packaged bits, and
running dracut like you ran should get you the initrd, although only after you’ve got
the
kernel.
I dont follow this at all I'm afraid. I understand some of the jargon but I
haven't a clue how to practically execute these as working steps.
Could you at all possibly boil this down into clear commands and instruction on when to
use them, in what order? Otherwise it all just feels like "the solution is to fix the
problem, you know how to do that right?'
After everything is reinstalled, then run the grub2-mkconfig command
to create the grub
config file in your new /boot partition.
I do recall this! So I should be able to do that last part myself. But I need help with
the other steps leading up to it
Thankyou for actually helping
9:51 a.m.
On Fri, Oct 28, 2022, at 5:53 PM, Jonathan Billings wrote:
It sounds like you only wiped the /boot partition, which should be
fairly easy to get back.
But /boot/grub2 and /boot/loader/entries are on /boot so the real grub.cfg and BLS
snippets are gone, which are trivial to create if you're an expert. If you're not,
it might as well be ouji board antics.
There's so many tiny things like this that the installer does, that it sorta makes it
a grand experiment in "what the hell did we miss" doing the fix manually.
We can just (a) reformat the boot partition, get its new fsUUID put into (b)
/boot/efi/EFI/fedora/grub.cfg and (c) /etc/fstab on the existing root (d) mount everything
in the proper order so we can do a chroot (e) run grub2.mkconfig (f) do a dnf reinstall
kernel so that we for sure have a vmlinuz on /boot and modules of the same version in /usr
and BLS snippet
But uhh what am I missing? Like, I'd just reboot at this point and wait for the
failure to give me a hint what I'm missing. But in this case, the user gets stuck in a
way they maybe can't get out of or describe and then we're worse off having
wasted the time.
Reinstalling the kernel and grub2 packages
will get you the packaged bits, and running dracut like you ran should
get you the initrd, although only after you’ve got the kernel.
reinstalling the kernel will run dracut, we don't need to run it again
After everything is reinstalled, then run the grub2-mkconfig command to
create the grub config file in your new /boot partition.
Just make sure you do everything from the chroot in an EFI booted
rescue environment, either on a livecd or booting the NetBoot iso with
the rescue option.
So unfortunately Live images don't have Anaconda rescue environments. And while the
netinstaller does, it will fail to find /boot by UUID in the /etc/fstab because it
doesn't exist anymore so the assembly and chroot will fail.
The manual method means high likelihood of missing a step or getting it in the wrong
order. Or asking someone to test all the steps in a VM.
Hence why reinstallation is easier.
If it's Btrfs, we can keep the old root and swap roots.
We need to fix two things (a) change the rootflags=subvol argument in the BLS snippets, so
they mount root subvolume instead of root00 subvolume (b) update the /boot fsUUID in
/etc/fstab
Right? Is that it? I think that's it.
OH OK there is one more problem. Probably the kernel in the new /boot is old and that
version's modules don't exist anymore in the (old) root subvolume's /usr and
therefore we can't boot. So yeah that has to get fixed somehow...
If the Btrfs volume is mounted normally (without any options) to /mnt we can copy the old
kernel modules from the new root to the old root and now the old root will boot.
cp -r /mnt/root00/usr/lib/modules/$theonlydirpresent /mnt/root/usr/lib/modules/
Right? That will return fairly instantly because it'll be a reflink copy, so it might
lead some folks to think it didn't work because it was too fast :P What should be true
is in the first path with root00, if you hit TAB after the last /, it should autocomplete
the only directory present which is the shipping kernel for Fedora 36.
Or hey I have that kernel in a btrfs snapshot I created after an F36 clean install. It
should be 5.17.5-300.fc36.x86_64 so the actual command ought to be
cp -r /mnt/root00/usr/lib/modules/5.17.5-300.fc36.x86_64 /mnt/root/usr/lib/modules/
OK I think that's everything?
--
Chris Murphy
11:21 a.m.
On Fri, 28 Oct 2022 18:31:41 -0000
"Jake D" <techsupport_accounts(a)riseup.net> wrote:
I seem to have got myself in a bit of a mess and I’ve having trouble
finding documentation that I can apply directly to my case . This is
my first time on Linux so I’m not familiar with much of the
terminology or background of these systems.
On every linux system there is a help system called man. So, if you
don't recognize a command, you usually can just do a, for example
man ls
or
man cp
or
man chroot
so you can understand what the command is doing, and the various
options that you can use to tune the command.
**Background**
I have an internal drive that used to successfully dual boot windows
and a LUKS-encrypted F36 installation with BTRFS.
I also had some spare unpartitioned space, which I used to fully
install some other linux distros (including another F36 installation)
to troubleshoot other minor problems (a tri-boot, so to speak)
**What went wrong**
The new distros installed fine, but I discovered afterwards I could
no longer find/boot into my original LUKS F36 installation.
This is where you should have asked for help. At that point, it would
have been simple to recover the system. UEFI only allows a single
version of fedora (or any OS) to boot without some alterations that are
complicated, and above your level of knowledge at this point.
As Chris said, and I've personally experienced, panic mode is not the
time to make any serious decisions. It has to do with human
psychology. When we are in panic mode, we are in the acute stress
response mode of our brain, fight or flight. In this state, we do not
have access to our frontal cortex, so we lose all of our reasoning
ability. A great precursor to making bad decisions. Take a few
moments to inhale deeply, hold the breath for a few counts, and then
exhale fully. Do this 5 or 10 times. That returns the brain to the
default state, where your frontal cortex is again available.
In my
igornance, I tried deleting clearing the new installation partitions,
and now, if I select the Fedora option thru my BIOS boot menu, I just
get to a 'grub> ’ prompt.
Right, it is trying to boot the linux partitions that you wiped. When
it doesn't find them it drops you to a limited shell (command
environment) in order to try to fix it. Way above your pay grade, and
the chroot environment is a lot easier to work with to do the same
thing, so you don't have to work at the grub prompt.
I’ve tried a few commands there to boot manually but nothing worked
and it wouldn’t even decrypt the root partition, worse still, somehow
this process accidentally wiped the ORIGINAL LUKS F36 /boot partition
too. I have no idea how.
**What I have now**
Partitioning follows:
nvme0n1p1: EFI partition (both win and DF36)
nvme0n1p2: MS Reserved
nvme0n1p3: Win10
nvme0n1p5: Original Fedora /boot (accidentally wiped)
nvme0n1p6: LUKS volume
nvme0n1p7: Former ‘third OS’ boot partition (wiped)
nvme0n1p8: Former ‘third OS’ root partition (also wiped)
nvme0n1p4: Win Recovery
**What I am trying to do**
Unbork everything, somehow?
I tried using these instructions in the official Fedora Docs, but
they seem to be …wrong? Out of date? They didn’t work, I suspect due
to LUKS/BTRFS. [
https://docs.fedoraproject.org/en-US/Fedora/23/html/Multiboot_Guide/commo...]
The I found these...other Fedora Docs? Which seemed more up to date
and looked like they had relevant bits, bit still seem directly
applicable and didn't work.
[https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#r...]
The only success I’ve had is with this guide:
https://fedoramagazine.org/os-chroot-101-covering-btrfs-subvolumes/ .
I’ve managed to chroot (a very dumb word) thru a LiveUSB session,
with the following commands:
>>cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt
>>mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root
>>mount /dev/mapper/fedora_crypt /mnt/home -t btrfs -o subvol=home
>>mount /dev/nvme0n1p5 /mnt/boot
>>mkdir /mnt/boot/efi
>>mount /dev/nvme0n1p1 /mnt/boot/efi
>>mount --bind /dev /mnt/dev
>>mount -t proc /proc /mnt/proc
>>mount -t sysfs /sys /mnt/sys
>>mount -t tmpfs tmpfs /mnt/run
>>mkdir -p /mnt/run/systemd/resolve/
>>nano /mnt/run/systemd/resolve/stub-resolv.conf (enter 'nameserver
>>1.1.1.1', save) chroot /mnt
I can ping google, and browse the original home folder with ls, so it
looks like ‘im in’ the original installation via chroot (which is
still a dumb word)
The car is still there, but you've removed the starter.
What the problems are
From there, I go back to the Fedora Docs and run
>>dnf reinstall grub2-efi grub2-efi-modules shim
What does
ls -n /boot/efi/EFI/fedora
show?
Here,
# ls /boot/efi/EFI/fedora/
BOOTIA32.CSV BOOTX64.CSV grubia32.efi grubx64.efi mmia32.efi mmx64.efi shim.efi
shimia32.efi shimx64.efi
That seems to work? Downloads and seems to install without any errors.
Run
dnf reinstall kernel-core
If that command complains that the kernel isn't installed, then run
dnf install kernel-core
but that shouldn't be necessary, because you deleted the files outside
of the package manager (dnf), it will still think they are installed
according to its internal records.
Then run,
ls -n /boot
Are there a bunch of files there? Do some of them have names like
vmlinuz... or initramfs...?
Then
cd /boot/loader/entries
ls -n *
There should be a files there ending in conf.
Here,
# ls /boot/loader/entries
ac21376ffcd448c1a1c1ebe04e09a89b-0-rescue.conf
ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc5.20220914git3245cb65fd91.39.20220918.fc37.x86_64.conf
ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc1.20220819git4c2d0b039c5c.16.20220821.fc37.x86_64.conf
ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc7.20220930git987a926c1d8a.51.20221002.fc37.x86_64.conf
ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc2.20220826git4c612826bec1.22.20220828.fc37.x86_64.conf
ac21376ffcd448c1a1c1ebe04e09a89b-6.0.3-300.20221023.fc37.x86_64.conf
ac21376ffcd448c1a1c1ebe04e09a89b-6.0.0-0.rc3.25.20220829.fc37.x86_64.conf
You might only have one or two.
If this is all true, and only if it is all true, you just need to go
into /boot/grub2 and run the command grub2-mkconfig
cd /boot/grub2
grub2-mkconfig -o grub.cfg
At this point, your system should be able to boot your fedora
install again.
The next step though;
>>grub2-mkconfig -o /boot/grub2/grub.cfg
fails with the following:
>> /usr/sbin/grub2-probe: error: failed to get canonical path of
>> ‘/dev/mapper/fedora_crypt’
I have no idea what that means.
This command examines your whole system and checks for bootable
partitions. A canonical path is an absolute path, a path without
ambiguity.
This might be a side effect of the missing kernel and initramfs. If it
is still happening, what does running
blkid
show?
How about
less /etc/fstab
or
cat /etc/fstab
On the side, I also sees that despite the grub reinstall, theres no
vmlinuz or initramfs kernel files in the reconstructed /boot
partition, so I tried running
>>dracut --regenerate-all
You don't need to run the dracut command, because the kernel install
does that automatically.
You were so close, only missing the kernel reinstall step. Good job
for a complete noob working from incomplete documentation! And you
persevered and recovered from your own mistakes, you have potential. :-)
1:09 p.m.
stan via users composed on 2022-10-29 09:21 (UTC-0700):
UEFI only allows a single
version of fedora (or any OS) to boot without some alterations that are
complicated
Besides making GRUB_DISTRIBUTOR= in /etc/default/grub a unique string and applying
the change, what are those alterations?
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
1:39 p.m.
On Sat, 29 Oct 2022 14:09:26 -0400
Felix Miata <mrmazda(a)earthlink.net> wrote:
stan via users composed on 2022-10-29 09:21 (UTC-0700):
> UEFI only allows a single
> version of fedora (or any OS) to boot without some alterations that
> are complicated
Besides making GRUB_DISTRIBUTOR= in /etc/default/grub a unique string
and applying the change, what are those alterations?
I did some investigation of sdboot, which allows multiple versions to
boot uefi from the same efi partition, and it didn't seem trivial.
I hadn't even looked into creating a new partition under /boot/efi/EFI
with a unique name, and what would be required for it to work. Is it
really as simple as changing GRUB_DISTRIBUTOR= in /etc/default/grub, and
everything else happens automatically?
1:55 p.m.
On Sat, 29 Oct 2022 11:39:00 -0700
stan via users <users(a)lists.fedoraproject.org> wrote:
On Sat, 29 Oct 2022 14:09:26 -0400
Felix Miata <mrmazda(a)earthlink.net> wrote:
> stan via users composed on 2022-10-29 09:21 (UTC-0700):
>
> > UEFI only allows a single
> > version of fedora (or any OS) to boot without some alterations
> > that are complicated
>
> Besides making GRUB_DISTRIBUTOR= in /etc/default/grub a unique
> string and applying the change, what are those alterations?
I did some investigation of sdboot, which allows multiple versions to
boot uefi from the same efi partition, and it didn't seem trivial.
I hadn't even looked into creating a new partition under /boot/efi/EFI
with a unique name, and what would be required for it to work. Is it
really as simple as changing GRUB_DISTRIBUTOR= in /etc/default/grub,
and everything else happens automatically?
How would dnf know about that changed name in order to install the shim?
How would the OS be installed initially, since the defaults are for the
current location? Wouldn't the install image have to have that built
in before install? It seems to me that there would be a default
install, then adding the change to the grub default, and then moving
the /boot/efi/EFI/fedora to /boot/efi/EFI/unique_name. I'm not sure
what would happen if an update came in for the shim package. Would dnf
install it in the old default location or the new location?
5:38 p.m.
stan via users composed on 2022-10-29 11:55 (UTC-0700):
> I hadn't even looked into creating a new partition under
/boot/efi/EFI
> with a unique name, and what would be required for it to work. Is it
> really as simple as changing GRUB_DISTRIBUTOR= in /etc/default/grub,
> and everything else happens automatically?
How would dnf know about that changed name in order to install the
shim?
DNF knows because it's a front-end to RPM, which operates according to the content
of the grub2-efi rpm and /etc/default/grub, Grub's config file. Pretend it has
.conf appended if necessary to understand. The value set for GRUB_DISTRIBUTOR=
establishes the location on the ESP where the efi file(s) must be located.
How would the OS be installed initially, since the defaults are for
the
current location?
I have no idea whether the default location can be overridden /during/ Fedora
installation. As long as the location has been made unique for each previous
installation, it doesn't matter that the default is used initially. Just make
# dnf reinstall shim-* grub2-efi-* grub2-common
part of your standard first boot order of business, and the efi directory /should/
be good indefinitely. But, be on the lookout for unexpected changes to
/etc/default/grub that might change it.
There remains the issue of whose bootloader has priority in firmware memory, and
on what occasions when OS maintenance activity has reason to touch it. Efibootmgr
is the utility for managing the NVRAM entries while fully booted, while BIOS setup
includes its own. My solution to avoiding OS touching is to install any bootloader
at all on a minimal selection of installations, such as only one. On others that
have a bootloader installed, I omit the ESP from their fstabs, preventing them
from finding conditions prerequisite to touching.
Finally, I build /boot/grub2/custom.cfg from scratch that uses volume LABELs and
symlinks to kernels and initrds, and customize /etc/grub.d/ to cause its entries
to head Grub's menu.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
9:23 a.m.
On Sat, 29 Oct 2022 18:38:53 -0400
Felix Miata <mrmazda(a)earthlink.net> wrote:
stan via users composed on 2022-10-29 11:55 (UTC-0700):
>> I hadn't even looked into creating a new partition under
>> /boot/efi/EFI with a unique name, and what would be required for
>> it to work. Is it really as simple as changing GRUB_DISTRIBUTOR=
>> in /etc/default/grub, and everything else happens automatically?
> How would dnf know about that changed name in order to install the
> shim?
DNF knows because it's a front-end to RPM, which operates according
to the content of the grub2-efi rpm and /etc/default/grub, Grub's
config file. Pretend it has .conf appended if necessary to
understand. The value set for GRUB_DISTRIBUTOR= establishes the
location on the ESP where the efi file(s) must be located.
This is good to know. I had assumed that the shim location was
hardcoded in the rpm, so this is more flexible.
> How would the OS be installed initially, since the defaults are for
> the current location?
I have no idea whether the default location can be overridden
/during/ Fedora installation. As long as the location has been made
unique for each previous installation, it doesn't matter that the
default is used initially. Just make
# dnf reinstall shim-* grub2-efi-* grub2-common
part of your standard first boot order of business, and the efi
directory /should/ be good indefinitely. But, be on the lookout for
unexpected changes to /etc/default/grub that might change it.
It seems that Fedora could facilitate this by appending a (random?)
suffix to the GRUB_DISTRIBUTOR value during install, so that this step
was automatically completed. A more sophisticated implementation might
examine other entries, and append a sequential value, or ensure that
the suffix was unique.
There remains the issue of whose bootloader has priority in firmware
memory, and on what occasions when OS maintenance activity has reason
to touch it. Efibootmgr is the utility for managing the NVRAM entries
while fully booted, while BIOS setup includes its own. My solution to
avoiding OS touching is to install any bootloader at all on a minimal
selection of installations, such as only one. On others that have a
bootloader installed, I omit the ESP from their fstabs, preventing
them from finding conditions prerequisite to touching.
Finally, I build /boot/grub2/custom.cfg from scratch that uses volume
LABELs and symlinks to kernels and initrds, and customize
/etc/grub.d/ to cause its entries to head Grub's menu.
I think this means that if you update any of the installed OSs, you
have to recreate the custom.cfg menu to incorporate the changes. And
that you have to have a custom utility you run in order to do that.
Would you be willing to share that utility, and your customizations of
/etc/grub.d?
This will work great, but I wouldn't consider it trivial for a new
user of Fedora.
Thanks for the information, filling out my sketchy understanding. I now
understand how to accomplish running multiple versions of an OS with a
single EFI partition using grub.
9:39 a.m.
On 10/30/22 07:23, stan via users wrote:
On Sat, 29 Oct 2022 18:38:53 -0400
Felix Miata <mrmazda(a)earthlink.net> wrote:
> stan via users composed on 2022-10-29 11:55 (UTC-0700):
>
>>> I hadn't even looked into creating a new partition under
>>> /boot/efi/EFI with a unique name, and what would be required for
>>> it to work. Is it really as simple as changing GRUB_DISTRIBUTOR=
>>> in /etc/default/grub, and everything else happens automatically?
>
>> How would dnf know about that changed name in order to install the
>> shim?
>
> DNF knows because it's a front-end to RPM, which operates according
> to the content of the grub2-efi rpm and /etc/default/grub, Grub's
> config file. Pretend it has .conf appended if necessary to
> understand. The value set for GRUB_DISTRIBUTOR= establishes the
> location on the ESP where the efi file(s) must be located.
This is good to know. I had assumed that the shim location was
hardcoded in the rpm, so this is more flexible.
The shim location *is* hardcoded in the rpm. I don't know what that
setting will affect.
11:11 a.m.
stan via users composed on 2022-10-30 07:23 (UTC-0700):
> Finally, I build /boot/grub2/custom.cfg from scratch that uses
volume
> LABELs and symlinks to kernels and initrds, and customize
> /etc/grub.d/ to cause its entries to head Grub's menu.
I think this means that if you update any of the installed OSs, you
have to recreate the custom.cfg menu to incorporate the changes. And
Depends on the nature of the update. Only major updates may require updates,
depending on specificity of labels used in building custom.cfg. If in upgrading a
release, and you change the LABEL of the / filesystem, and depend on LABELs in
boot stanzas, updating is required. Ordinary updates, such as new kernels, require
no updates, because the symlinks used in custom.cfg don't change, only the initrds
and kernels they point to. Distros I use other than Fedora create the required
symlinks automatically, e.g. all Debians & its derivatives, openSUSE, Mageia.
that you have to have a custom utility you run in order to do that.
Would you be willing to share that utility, and your customizations of
/etc/grub.d?
I have had no compulsion to create any such utility. All it would to would be to
automate symlink creation on Fedora when new kernels are installed that is done
automatically by other distros.
My method of /etc/grub.d/ customization only requires making a copy of 40_custom
named 06_custom, which puts custom.cfg's entries at the top of Grub's boot menu.
This will work great, but I wouldn't consider it trivial for a
new
user of Fedora.
That would depend on what makes a Fedora user a "new" Fedora user. New to
Fedora
but not new to Linux multibooting it ought to have already become trivial if
multiple versions of any same distro had been employed. New to multibooting,
whether or not new to Fedora, not so trivial, but it's newness to multibooting
and/or UEFI that would be the bigger part of making it non-trivial.
<https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UE...
has an example of the simplicity of custom.cfg.
<https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UE...
has an even simpler method, chainloading, which I don't use because I don't want
more than one distro messing with NVRAM's boot order.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
9:56 a.m.
On Sun, 30 Oct 2022 12:11:57 -0400
Felix Miata <mrmazda(a)earthlink.net> wrote:
Thank you.
> stan via users composed on 2022-10-30 07:23 (UTC-0700):
>
> >> Finally, I build /boot/grub2/custom.cfg from scratch that uses
> >> volume LABELs and symlinks to kernels and initrds, and customize
> >> /etc/grub.d/ to cause its entries to head Grub's menu.
>
> > I think this means that if you update any of the installed OSs, you
> > have to recreate the custom.cfg menu to incorporate the changes.
> > And
>
> Depends on the nature of the update. Only major updates may require
> updates, depending on specificity of labels used in building
> custom.cfg. If in upgrading a release, and you change the LABEL of
> the / filesystem, and depend on LABELs in boot stanzas, updating is
> required. Ordinary updates, such as new kernels, require no updates,
> because the symlinks used in custom.cfg don't change, only the
> initrds and kernels they point to. Distros I use other than Fedora
> create the required symlinks automatically, e.g. all Debians & its
> derivatives, openSUSE, Mageia.
>
> > that you have to have a custom utility you run in order to do that.
> > Would you be willing to share that utility, and your customizations
> > of /etc/grub.d?
>
> I have had no compulsion to create any such utility. All it would to
> would be to automate symlink creation on Fedora when new kernels are
> installed that is done automatically by other distros.
>
> My method of /etc/grub.d/ customization only requires making a copy
> of 40_custom named 06_custom, which puts custom.cfg's entries at the
> top of Grub's boot menu.
>
> > This will work great, but I wouldn't consider it trivial for a new
> > user of Fedora.
>
> That would depend on what makes a Fedora user a "new" Fedora user.
> New to Fedora but not new to Linux multibooting it ought to have
> already become trivial if multiple versions of any same distro had
> been employed. New to multibooting, whether or not new to Fedora, not
> so trivial, but it's newness to multibooting and/or UEFI that would
> be the bigger part of making it non-trivial.
>
>
<https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UE...
> has an example of the simplicity of custom.cfg.
>
>
<https://forums.opensuse.org/showthread.php/533087-How-to-have-a-custom-UE...
> has an even simpler method, chainloading, which I don't use because I
> don't want more than one distro messing with NVRAM's boot order.
9:41 a.m.
On Fri, 28 Oct 2022 18:31:41 -0000
"Jake D" <techsupport_accounts(a)riseup.net> wrote:
I have an internal drive that used to successfully dual boot windows
and a LUKS-encrypted F36 installation with BTRFS.
I also had some spare unpartitioned space, which I used to fully
install some other linux distros (including another F36 installation)
to troubleshoot other minor problems (a tri-boot, so to speak)
**What went wrong**
The new distros installed fine, but I discovered afterwards I could
no longer find/boot into my original LUKS F36 installation. In my
For
completeness:
The new installation of F36 overwrote the /boot/efi/EFI/fedora
partition, preventing the old F36 from booting. At this point you could
have booted into the new F36, mounted the old F36, chrooted to the old
F36, by performing the steps you did from the system recovery below,
I’ve managed to chroot (a very dumb word) thru a LiveUSB session,
with the following commands:
>>cryptsetup luksOpen /dev/nvme0n1p6 fedora_crypt
>>mount /dev/mapper/fedora_crypt /mnt/ -t btrfs -o subvol=root
>>mount /dev/mapper/fedora_crypt /mnt/home -t btrfs -o subvol=home
>>mount /dev/nvme0n1p5 /mnt/boot
>>mkdir /mnt/boot/efi
>>mount /dev/nvme0n1p1 /mnt/boot/efi
>>mount --bind /dev /mnt/dev
>>mount -t proc /proc /mnt/proc
>>mount -t sysfs /sys /mnt/sys
>>mount -t tmpfs tmpfs /mnt/run
>>mkdir -p /mnt/run/systemd/resolve/
>>nano /mnt/run/systemd/resolve/stub-resolv.conf (enter 'nameserver
>>1.1.1.1', save) chroot /mnt
>>dnf reinstall grub2-efi grub2-efi-modules shim
This would have fixed the problem, allowing you to boot the original
F36, and no longer boot the new F36.
The problem is that both F36 installations used the same directory on
the ESP, and so collided. There can only be one ESP (EFI partition)
per drive, I think that is a requirement of EFI. So, you would have
to use either sdboot, or the technique Felix described in a later post
in order to boot multiple version of F36 using grub. I don't think
either is trivial for a new user of Fedora, but your mileage might
differ.
6:13 a.m.
Well, an update.
When I left this discussion, it had taken what I would describe diplomatically as an
...unhelpful turn. People were either repeatedly insisting that I "just
reinstall" despite my explanations why this was not practical; lecturing me about
panic psychology and/or their opinions on Windows; engaged in inscrutable, arbitrary,
highly technical tangents seemingly for their own gratification; or outright attacking me
as a 'troll' for even having a problem in the first place.
Consequently, I gave up, and called the co-ordinator on Monday, resigned to probably
having to withdraw from the course.
Fortunately (or, unfortunately?) I was not alone. A number of other prospective students
had called in states of distress (apparently many also having been lured onto Fedora
...), and thus I was put in touch with one of the course tutors.
I copied my first post through to him, and in about 10 minutes and two emails of plain,
easy language, it was fixed. I didn't write down the exact commands as I was otherwise
focused, but I do recall that we had to open the 'crypt tab' on the encrypted
drive first, get the volumes name, then close it and re-open again with crypt setup but
using this name. this seemed to resolve the error message I was having, and everything
went smoothly from there, re-installing grub then initramfs.
The fact that this was so easy and close to my original steps, makes me suspicious that
people here knew all along, but were rather choosing to withhold information or present it
cryptically to prove some kindof of 'point', as if I deserve to be punished for
not knowing enough answer a question before I even ask it. The tutor himself alluded to
this in his email:
"They're very much like Arch in this way - a whole lot of ego tied up in
"their" software, and the tone of your thread is pretty typical of them. mailing
lists tend to be particularly bad, a lot of self-appointed 'senior' users who
gatekeep pretty hard.
There's been a pretty sus push lately on various socials etc about how 'Fedora is
the new Ubuntu' but honestly we want neither being used by students, for different
reasons (i pushed for distributing standardized environments but....).
Neither are really stable and are really just enterprises using the public for free beta
testing. fedora esp isn't well tested and is not fit at all for daily driving by
average/new users (as we're seeing!) but also the community is absolutely not one we
want students having to engage with. ever.
[Redacted] and I'll probably touch on this in the first tute - looks like the first
week is just going to be setting up environments anyway so we'll just work that into
the CLO's but either way we'll get you sorted "
So - in the end, I *did* go with a fresh installation - Debian! But to perhaps fix what is
clearly a much larger, different problem.
I'm fairly sure this won't go down well, but that itself is rather the issue here.
Nonetheless, I do certainly want to close this record in case anyone else comes looking
to solve a similar problem, but also making it clear the impact your collective conduct
has had, whether you can admit it or not.
I won't say 'thanks' but I will say: You've certainly all left an
impression.
7:55 a.m.
On Sun, Nov 6, 2022 at 8:13 AM Jake D <techsupport_accounts(a)riseup.net>
wrote:
Well, an update.
[...] I was put in touch with one of the course tutors.
I copied my first post through to him, and in about 10 minutes and two
emails of plain, easy language, it was fixed. I didn't write down the exact
commands as I was otherwise focused, but I do recall that we had to open
the 'crypt tab' on the encrypted drive first, get the volumes name, then
close it and re-open again with crypt setup but using this name. this
seemed to resolve the error message I was having, and everything went
smoothly from there, re-installing grub then initramfs.
From the list: "This is probably easier in a live discussion on IRC or
Matrix. There's just too much back and forth required."
The fact that this was so easy and close to my original steps, makes me
suspicious that people here knew all along,
They do know, but you failed to provide the level of detail needed to
understand your exact situation, which is why
the one-on-one communication is so important.
but were rather choosing to withhold information or present it
cryptically
to prove some kindof of 'point', as if I deserve to be punished for not
knowing enough answer a question before I even ask it. The tutor himself
alluded to this in his email:
"They're very much like Arch in this way - a whole lot of ego tied up in
"their" software, and the tone of your thread is pretty typical of them.
mailing lists tend to be particularly bad, a lot of self-appointed 'senior'
users who gatekeep pretty hard.
There's been a pretty sus push lately on various socials etc about how
'Fedora is the new Ubuntu' but honestly we want neither being used by
students, for different reasons (i pushed for distributing standardized
environments but....).
You should not put much stock in those socials. I work with many users
new to linux (because my field relies on
applications that are not fully functional on Windows) and recommend they
start by looking around their institution
to see what others are using so they can get that one-on-one help if they
get into difficulties.
Neither are really stable and are really just enterprises using the
public
for free beta testing. fedora esp isn't well tested and is not fit at all
for daily driving by average/new users (as we're seeing!) but also the
community is absolutely not one we want students having to engage with.
ever.
The tradeoff for the beta testing is that developers and integrators get an
early look at changes that may appear in long-term
support or "stable" releases.
[Redacted] and I'll probably touch on this in the first tute - looks like
the first week is just going to be setting up environments anyway so
we'll
just work that into the CLO's but either way we'll get you sorted "
I have taught practical sessions in workshops for select groups of PhD
researchers where some applications required
(Ubuntu) linux. Each student was provided a laptop, so we did not have to
deal with diverse hardware. We found it
important to spend the first two afternoons on some linux basics and then
have students install linux (vm or dual boot
depending on their individual requirements).
So - in the end, I *did* go with a fresh installation - Debian! But to
perhaps fix what is clearly a much larger, different problem.
Debian has stable and unstable releases. Debian unstable and Fedora both
introduce new stuff, but make different
choices.
I'm fairly sure this won't go down well, but that itself is
rather the
issue here. Nonetheless, I do certainly want to close this record in case
anyone else comes looking to solve a similar problem, but also making it
clear the impact your collective conduct has had, whether you can admit it
or not.
I won't say 'thanks' but I will say: You've certainly all left an
impression.
I'm glad you got your course requirement sorted out. Having seen the
stress felt by students when a course nelects to
support the transition to linux, I can understand your frustration. There
are students who do better when new stuff is
introduced gently, and the "move fast and break things" students who will
encounter setbacks. Education sould
encourage each type of student to learn when it is better to move fast and
when to avoid breaking things.
--
George N. White III
11:55 a.m.
On Sun, 06 Nov 2022 12:13:44 -0000
"Jake D" <techsupport_accounts(a)riseup.net> wrote:
[snip]
many also having been lured onto Fedora ...), and thus I was put in
touch with one of the course tutors.
I copied my first post through to him, and in about 10 minutes and
two emails of plain, easy language, it was fixed. I didn't write down
the exact commands as I was otherwise focused, but I do recall that
we had to open the 'crypt tab' on the encrypted drive first, get the
volumes name, then close it and re-open again with crypt setup but
using this name. this seemed to resolve the error message I was
having, and everything went smoothly from there, re-installing grub
then initramfs.
The fact that this was so easy and close to my original steps, makes
me suspicious that people here knew all along, but were rather
choosing to withhold information or present it cryptically to prove
some kindof of 'point', as if I deserve to be punished for not
knowing enough answer a question before I even ask it. The tutor
himself alluded to this in his email:
"They're very much like Arch in this way - a whole lot of ego tied up
in "their" software, and the tone of your thread is pretty typical of
them. mailing lists tend to be particularly bad, a lot of
self-appointed 'senior' users who gatekeep pretty hard.
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.o...
Could you have the course tutor post his fix for your situation as a
reply to the archive of the thread you started. It shouldn't take him
a whole lot of time, since the fix was so easy, and it will help anyone
with a similar problem who finds your thread with a search in the
future.
Imagine if someone had done this prior to your problem, and you had
searched and found it. Would you be thankful?
7:15 p.m.
If any new users come looking, my (and his) advice was/is: Don't use Fedora.
I think the reasons for that are abundantly clear already. I'm not going to waste his
time further.
I dont really even want to waste my time further, but I can't seem to delete my
hyperkitty account. That seems to be another case of Missing Fedora Functions. Which is
funny - I though Microsoft was the one that trapped people and data into systems....
8:27 p.m.
On Nov 6, 2022, at 20:16, Jake D <soaring-kettlecorn(a)fedoraproject.org> wrote:
If any new users come looking, my (and his) advice was/is: Don't use Fedora.
I think the reasons for that are abundantly clear already. I'm not going to waste his
time further.
I dont really even want to waste my time further, but I can't seem to delete my
hyperkitty account. That seems to be another case of Missing Fedora Functions. Which is
funny - I thought Microsoft was the one that trapped people and data into systems....
(I doubt the OP will read this, but in case other new users do…)
I think what you said is a bit unfair. No one is trying to waste your time. No one is
intentionally trying to prevent you from solving your issues (as you said in your last
mail). Several people tried to help, but were unable to due to not having all the details
and the nature of the forum.
I’m part of the Fedora community and while I’ve largely stayed in the periphery, I feel it
has been welcoming to new users. I hope there are others who agree.
However, it’s been several decades since I could consider myself a new Linux user, so I’m
not really a good judge of what is user friendly to novice users.
--
Jonathan Billings
9:23 p.m.
On Nov 6, 2022, at 20:16, Jake D
<soaring-kettlecorn(a)fedoraproject.org> wrote:
(I doubt the OP will read this, but in case other new users do…)
I dont really have a choice! For some reason every single reply is still being emailed
directly to me
I’m part of the Fedora community and while I’ve largely stayed in the
periphery, I feel it
has been welcoming to new users. I hope there are others who agree.
However, it’s been several decades since I could consider myself a new Linux user, so
I’m
not really a good judge of what is user friendly to novice users.
As a new user, I am telling you - it absolutely has not been.
If people want to ignore that feedback and tell themselves they think they are welcoming
and helpful, I can't do anything more than making it very clear you doing so in the
face of direct information to the contrary.
Now, can anyone tell me how to close a HyperKitty account? Or is that also too much to
ask?
1:02 a.m.
Joe Zeff composed on 2022-11-06 21:57 (UTC-0700)
Jake D wrote:
> Now, can anyone tell me how to close a HyperKitty account? Or is
that also too much to ask?
All you need to do is read the footer that the list puts at the
bottom
of every message and you will know how to unsubscribe from the list.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Anyone asking the question Jake asks isn't likely to be seeing any list footers.
HyperKitty, unlike its superior archive predecessor, reformats messages for web
display, excluding footers, and making a mess of columnar data with inappropriate
line wrapping.
Most using email for reading and responding rather than the HyperKitty web
interface to the list probably have no ideas about how to "close a HyperKitty
account". I have no idea whether I have any such account. My subscriptions to
Fedora mailing lists started long before HyperKitty existed.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
4:37 a.m.
On Mon, 2022-11-07 at 02:02 -0500, Felix Miata wrote:
Most using email for reading and responding rather than the
HyperKitty web
interface to the list probably have no ideas about how to "close a
HyperKitty
account". I have no idea whether I have any such account. My
subscriptions to
Fedora mailing lists started long before HyperKitty existed.
AFAIK there is no such thing as a "HyperKitty account". HyperKitty is a
lame (IMHO) web interface running off the Mailman list management
system. The OP needs to unsubscribe from the list, that's all.
As he already said he keeps getting mail, presumably he's also getting
the footers which indicate how to unsubscribe, but just in case, here
they are again:
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
poc
10:48 a.m.
On Mon, Nov 07, 2022 at 03:23:00AM -0000, Jake D wrote:
...snip...
Now, can anyone tell me how to close a HyperKitty account? Or is that also too much to
ask?
Theres no seperate HyperKitty account, it's just a Fedora account used
to login there.
I've gone ahead and unsubscribed you from this list, so you shouldn't
get any more emails from it.
If you want to close your account, file a request at:
https://pagure.io/fedora-pdr
kevin
6:59 p.m.
I am still getting emails. Unsure if you have actioned this yet.
I have had someone else tell me to use this Pagure website when I was trying to close my
Ask Fedora site too, and as I said there: despite repeated attempts my login details do
not work to log into that page, which appears to be an entirely different and rather
suspect sit, which doesn't seem at all associated with HyperKitty.
So I'm not sure how to proceed. It seems like Fedora community platforms are as broken
as the operating system itself.
7:23 p.m.
New subject: difficulty unsubscribing from mailing list (was: How do I rebuild
Grub/Boot/initramfs...)
Jake D composed on 2022-11-08 00:59 (UTC):
I am still getting emails. Unsure if you have actioned this yet.
If Kevin had succeeded to unsubscribe you I would expect it to have taken effect
within minutes, not several hours or more.
So I'm not sure how to proceed.
Have you read any list mail in a dedicated email program, rather than via webmail
(in a web browser or using a mobile phone) or the HyperKitty mailing list archive?
If not via an email program, and possibly even with some email programs, the list
footer of every email, which contains instructions for unsubscribing, are
*obfuscated* or *absent*. If you are able to read a full email, such as via an
email program or selecting "message source" to see the entire email unedited in
its original non-formatted format, then the instruction is obviously placed within
the last few lines of the message.
The welcome message you received when you originally subscribed also contained
instructions for unsubscribing.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
11:15 a.m.
On Tue, Nov 08, 2022 at 12:59:52AM -0000, Jake D wrote:
I am still getting emails. Unsure if you have actioned this yet.
I have, I can confirm you are not subscribed anymore.
So, you should likely not get this (or any other emails from the list).
If you still do, can you forward directly to me one of the emails you
got with all the headers and I can track down where it's coming from.
kevin
10:18 a.m.
On Sun, Nov 6, 2022, at 5:15 PM, Jake D wrote:
If any new users come looking, my (and his) advice was/is: Don't
use Fedora.
I think this is a very good thread to have in the archive. I don't think it shows that
you should not use Fedora. I think it clearly shows that the community is ready and
willing to help and that you need to actually participate in that process.
It also demonstrates how a bad attitude will lead to poor outcomes.
6:56 p.m.
Astounding that in the face of someone telling you "You are not helping", your
conclusion is to decide you are helpful, pat yourself on the back for it, and declare
they have an 'attitude problem'. The lack of anything resembling self-awareness is
almost comical, and I'm starting to understand now why Linux consistently fails to
attract a meaningful market share.
I have no objections to this being archived, certainly. Frankly I wish there'd been a
warning on the Fedora download page.
534
days inactive
545
days old
54 comments
15 participants
participants (15)
-
Chris Murphy -
Doug Herr -
Felix Miata -
George N. White III -
Go Canes -
Jake D -
Jake D -
Joe Zeff -
Jonathan Billings -
Kevin Fenzi -
Patrick O'Callaghan -
Samuel Sieb -
Slade Watkins -
stan -
Tim