Fixed it till it broke - GrubF*ckup?

Lots of info on configuring DK, no cheetsheet on keybinds.
Not in the thread in the forum, not in the man page.

Edit:
ArchBang has a Conky with KB shortcuts
BunsenLabs does.
Mabox Linux
Snail Linux

1 Like

No because dk doesn’t actually handle binds outside the mouse, just takes in commands, but it does say you’ll need something like sxhkd and where the config would be copied in a “default” install. I’m not even gonna try and cover it up, I hate doing documentation, if someone were to come along with a cheat sheet or w/e I’d be much more inclined to include it :wink:

1 Like

LOL, dk already has pretty good docs.

1 Like

And they only took me a year :smiley:

1 Like

Not easy. Tech Writer is a paid position in most tech companies. :grinning:

1 Like

So, the WM on the ISO is for? Looking at?
It’s not for the user to test DK?
Just stick with the CLI installer prompt.
Confused.

2 Likes

I agree with you here, I think something more user friendly like OB would be a better option for a live session. We’re stuck in between not wanting to appeal to (pardon the language) newbs but offering a simple-r install process, as far as it goes I think it’s a good way of weeding out people not really wanting to use it. My first jump into the linux world wasn’t exactly easy and I think it was a good thing, not that I try to make things difficult. There’s certainly less welcoming isos out there but I don’t think we’re that bad, there’s always the option to switch to a different tty. I think dropping the live session would be best, it serves no real purpose.

2 Likes

I disagree. The live session demonstrates how light & easy to use DK WM really is. Users who have interest in AL(and DK) will certainly dive in a little bit more.

2 Likes

A neutered WM does this? Now I’m really confused.

confusion abounds

The Dude abides

2 Likes

@eight_bit_al made a valid argument. In theory, defaulting to dk makes sense @natemaia because it showcases your personal project. However, in order to try it … you have to install it. Once it’s installed, there’s no way to utilize a “live” session for hints & tips because it doesn’t exist. It’s somewhat of a catch-22 because of that exclusive nature.

Defaulting to openbox obviously solves navigation, but at the expense of the showcase of dk.

2 Likes

Why not have dk live session that starts with a terminal open with the same text as before?
I cant remember exactly but it was something basic like ‘type ‘installer’ to install’
you could add ‘dk wm is here for your perusal’ or summat similar as well, if you liked?

Then you have both trains of thought covered - dk is there to explore if you want to, direct installation if you want to?

tbh all I had to know was super+T for terminal then type ‘installer’

Perhaps simple sentence instruction to this in the release post would be another even simpler solution?

I am way behind most people, still using openbox (its what lead me here - I wanted crashbang - actually for me it was bunsenlabs - but based on arch (it ran far quicker than Debian based on my old stuff). I loved archbang but there was less support (because MR Green is on his own, not because he was unhelpful at all) and that was critical for me. But I intend to move to i3 as I like it and mostly use keybinds not menus in OB as I get more comfortable. dk is on my list :smiley:

I have no strong views on this - I am all right jack - I know how to do it now LOL

2 Likes

I bet you are, my friend, after your lengthy explorations :wink:

Just my two cents: the excellent TUI installer has always been what AL made stand out for me and I thus, at the time, did exactly the same as @leigh . Booting straight into the command prompt and taking it from there is what I’d prefer. But hey, I’m a DOS guy, I love that blinking cursor. Either way the distro remains solid.

3 Likes

It was very simple in the end tho.

2 Likes

The story of my life…

4 Likes

Mostly since I often use my threads to remember what I did, and also since this is kind of related to the key issues (now solved) I had above:

I just booted up my old laptop (1st time for a while) that also has AL on it and ran yay to update
but it gave an error: archlabs-skel-openbox: signature from Nathanial Maia is unknown trust

I uninstalled archlabs-skel-openbox and it updated fine

OK,
all working great!

But, …

if I boot into Windows on reboot it has thieved boot and I go directly back into windows instead of to GRUB

This is not the end of the world as I can just go into BIOS and change the order back, but I am trying to sort it out.

I am making progress, working with the following links, for example:
9.6 & 4.3.1 in this
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface
This:
https://wiki.archlinux.org/title/Dual_boot_with_Windows

https://forums.linuxmint.com/viewtopic.php?t=357602

etc

so my plan is to use efibootmgr if I can or if not, EasyUEFI to sort this but I would like to clarify a few things first before I go into the china shop

I am not 100% sure why I have two EFI partitions.
The one on my ‘Windows disk’ (sda) was already there from the windows installation which I ‘cleaned up’ and left there.
I put a new ‘Linux’ EFI on my ‘Linux disk’ (sdb), so now I have two.

  • However, my (limited) understanding is that I only need one, and that the Linux EFI would be enough and it boots GRUB which gives the choice of Linux or Windows?
  • Is the original EFI left there on sda as a backup, in case my linux disk sdb goes tits up?
  • should I be booting from my Linux disk efi on sdb, as it appears I am doing?
leigh@archlabs ~ % findmnt /boot
TARGET SOURCE    FSTYPE OPTIONS
/boot  /dev/sdb1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset
  • why do I have two windows boot managers in my BIOS? If I delete one, it comes back to give two again. the output from efibootmgr seems to show they are on the same disk? Can I just delete one of those files?

  • In simple terms, how does this EFI boot process work, schematically? I have tried to read the various Arch pages on UEFI etc but there is far far too much info for me. What are you selecting with the boot options in BIOS? Is this a boot manager in a given EFI, or is this the EFI partition? etc. confused :smiley: I’m looking for a simple boot steps in terms of, say, BIOS selects X then X does this, etc

Thanks
Other info:

leigh@archlabs ~ % ls /boot/EFI
archlabs/
BOOT/
leigh@archlabs ~ % ls /boot/EFI/archlabs 
grubx64.efi*
leigh@archlabs ~ % ls /boot/EFI/BOOT    
BOOTX64.EFI*
leigh@archlabs ~ % efibootmgr 
BootCurrent: 0005
Timeout: 0 seconds
BootOrder: 0005,0000,0004
Boot0000* Windows Boot Manager	HD(1,GPT,180766cb-06f8-44d9-9d90-cdf2139729c2,0x800,0x12c800)/File(\efi\microsoft\boot\bootmgfw.efi)57494e444f5753000100000088000000780000004200430044004f0042004a004500430054003d007b00390064006500610038003600320063002d0035006300640064002d0034006500370030002d0061006300630031002d006600330032006200330034003400640034003700390035007d00000065000100000010000000040000007fff0400
Boot0004* Windows Boot Manager	HD(1,GPT,180766cb-06f8-44d9-9d90-cdf2139729c2,0x800,0x12c800)/File(\EFI\Microsoft\Boot\bootmgfw.efi)
Boot0005* UEFI OS	HD(1,GPT,f735b7d2-08e5-4112-ba64-a63dffe016e2,0x800,0x200000)/File(\EFI\BOOT\BOOTX64.EFI)

HD(1,GPT,180766cb-06f8-44d9-9d90-cdf2139729c2,0x800,0x12c800)
In the above, what do the entries in parenthesis mean?
1 is partition number? makes sense my EFI’s are in sda1 and sdb1
GPT I get
180766cb-06f8-44d9-9d90-cdf2139729c2?
0x800?
0x12c800?

OK, I have done it!

For anyone who gets into similar difficulties in the future (all the below is in my Joplin ArchLabs note),
this is how I got into the mess and then did it:

Windows Boot manager was ‘stealing’ first BIOS boot position after booting into Windows via GRUB so after exiting Windows, in order to boot into ArchLabs I would have to go into BIOS and manually change the boot order back

So, using EasyUEFI windows app (free trial, seems to be 15 days) I could see that my windows disk (sda) EFI partition had loads of Manjaro & other Linux OS entries in it (from previous installs), and two Windows boot managers - it was a mess.

So, again Using EasyUEFI windows app, I deleted some (‘fuck it’ I thought :rofl: )

But then windows would not boot (DOH!)

So I decided to format the Windows disk (sda) EFI partition and repopulate it (What I should have done from the beginning)

I cobbled together something from the two guides in the following links:

This is how I did it:

  • Boot PC with Windows 11/10/8/7 installation media
  • Press SHIFT + F10 on the first screen to bring up Command Prompt.
  • Go into diskpart:
  • diskpart
  • List the disks:
  • list disk
  • The first disk (sda) was Nº 0, so select it:
  • select disk 0
  • List partitions on disk 0:
  • list partition
  • The EFI partition was Nº 1, so select it:
  • select part 1
  • For more info on what is currently selected:
  • detail partition
  • detail volume
  • Check the correct partition is selected
  • Then, to format the partition to fat32 as it was before
  • format quick fs=fat32
  • Exit diskpart:
  • exit
  • Copy the boot files from the Windows partition to the EFI system partition and create the BCD store in it:
  • bcdboot X:\windows
  • Reboot computer by exiting Windows media

And … It booted into Windows! WooHoo!

and now my Windows disk (sda) EFI was nice and clean and only had one windows boot manager on it :smiley:

I then rebooted into BIOS and set UEFI OS (P1 …) as first boot

Then I was able to boot into ArchLabs via GRUB

Then I did:

leigh@archlabs ~ % sudo update-grub
[sudo] password for leigh: 
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-linux-lts
Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux-lts.img
Found fallback initrd image(s) in /boot:  intel-ucode.img initramfs-linux-lts-fallback.img
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/intel-ucode.img /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot:  intel-ucode.img initramfs-linux-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/sda1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

I rebooted into ArchLabs a couple of times for good measure, then rebooted into Windows.

Then when I rebooted Windows I was taken back to GRUB - Windows boot manager did not ‘steal’ first boot position in BIOS as it was doing before!

Now I have a much cleaner, nicer system than ever before!
Windows on the ‘main’ SSD, with a shiny clean EFI
ArchLabs on the DVD drive caddy SSD with the Linux EFI

Thanks all!

4 Likes

Thanks for sharing Leigh

1 Like