New SSD, what partition scheme for dual boot, no Windows

First time using Gparted. I'm not seeing the option for assigning flags. Perhaps I should use the Calamares installer, in manual mode, to do the install and define the partitions along with the flags?

***I see the column for Flags, but not how to define. Would that come after I create the partitions?

As you are pre-partitioning its fine .. you can set them up now, no flags, and do it during install.
But Just to show you (and you should check after install anyways..just to be safe) :
image
(you can kinda see in the background of this system some silly windoze OEM partitions .. but just the one linux, them both sharing EFI .. and no swap)

1 Like

Got it. Thank you.

I see it.

Thanks for your help. Here goes!

:smile:

1 Like

Alright. I applied the partition table to the SSD, installed Manjaro to it and installed the new SSD into the computer, replacing the old HDD.

I'm having a really long boot time that shows a blank screen. But, once it boots, everything so far seems to be working. I'll see what I need to do to fix that. Here is my drive layout now:

GpartedSSPartitionTable

I did notice that the GRUB menu still lists Windows as an option so I suspect I'll need to fix that. That may be a contributing factor to the lengthy boot time.

Spencer

You can check a few things. First:
efibootmgr
ls /boot/efi/EFI/
systemd-analyze blame

What do you see there?
[note - text is usually preferable to images. And remember to use the </> button so it is readable :wink:]

2 Likes

for any help to link /data in each /home

Really not sure if I did this right. Let's see.

[spencer@spencer-pc ~]$ efibootmanager
bash: efibootmanager: command not found
[spencer@spencer-pc ~]$ ls /boot/efi/EFI/
boot  Manjaro
[spencer@spencer-pc ~]$ systemd-analyze blame
           695ms systemd-backlight@backlight:intel_backlight.service
           498ms lvm2-monitor.service
           391ms dev-sda2.device
           333ms upower.service
           293ms tlp.service
           270ms udisks2.service
           205ms ModemManager.service
           120ms ldconfig.service
           116ms NetworkManager.service
           112ms polkit.service
            94ms boot-efi.mount
            76ms systemd-logind.service
            76ms systemd-udevd.service
            73ms user@1000.service
            70ms systemd-udev-trigger.service
            63ms avahi-daemon.service
            63ms systemd-journal-flush.service
            57ms systemd-journald.service
            29ms systemd-fsck@dev-disk-by\x2duuid-0621\x2dEE3E.service
            25ms org.cups.cupsd.service
            24ms systemd-tmpfiles-clean.service
            24ms systemd-tmpfiles-setup.service
            19ms systemd-journal-catalog-update.service
            17ms systemd-binfmt.service
            17ms dev-hugepages.mount

A general question; might be of interest/relevance to the OP specifically, but anyway might have relevance for the general proposition of multi-boot Linux distros with common /Data partition.

How do you manage third-party programs with critical reliance on their accumulated user-data? Two suitable examples might be Firefox & Thunderbird, which you intend to use regardless of if today you booted into Linux1, Linux2, Linux3 etc. I'm also making the rash assumption here that irrespective of your boot choice today, you still intend being You, not a different user, ergo you want all your Bookmarks, Tab Sessions, UI layout, emails, calendar events yada yada in FF & TB no matter which boot is currently active.

However, Linux1 might use a different version of FF &/or TB to Linux2, or Linux3, which might have adverse implications for your common /Data/.mozilla/firefox/tjy1xo7l.default &/or /Data/.thunderbird/u7japldr.default.

So what do you do, how do you manage such scenarios, how do you have your cake & eat it?

check the 'spelling' of the first command
efibootmgr

Doh!

Here you go!

[spencer@spencer-pc ~]$ efibootmgr
BootCurrent: 0012
Timeout: 2 seconds
BootOrder: 0012,0000,0001,0002,0003,000A,0011,0007,0008,0009,000B,000C,000D,000E
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash Screen
Boot0003  Lenovo Diagnostics
Boot0004  Startup Interrupt Menu
Boot0005  ME Configuration Menu
Boot0006  Rescue and Recovery
Boot0007* USB CD
Boot0008* USB FDD
Boot0009* ATAPI CD0
Boot000A* ATA HDD0
Boot000B* ATA HDD1
Boot000C* ATA HDD2
Boot000D* USB HDD
Boot000E* PCI LAN
Boot000F* IDER BOOT CDROM
Boot0010* IDER BOOT Floppy
Boot0011* Windows Boot Manager
Boot0012* Manjaro

Oh, hah .. we are talking about grub.. Whats
ls /boot/efi/EFI/boot/
sudo update-grub
[nvm I shouldnt need the first 2]

[spencer@spencer-pc ~]$ ls /boot/efi/EFI/boot/
bootx64.efi
[spencer@spencer-pc ~]$ sudo update-grub

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for spencer: 
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-4.19-x86_64
Found initrd image: /boot/intel-ucode.img /boot/initramfs-4.19-x86_64.img
Found initrd fallback image: /boot/initramfs-4.19-x86_64-fallback.img
Found memtest86+ image: /boot/memtest86+/memtest.bin
done

Well.. looks like that windows image should be gone .. reboot and let us know.

Also, set some things the way you like it and reboot a few times, do your updates, etc ...

Then if the 'slow boot' issue persists start a new thread with your inxi, maybe a link here, etc .. as that would now be a different issue than OP.

Alright. I reinstalled Manjaro via Calamares and chose the wipe disk option. I got to where Manjaro would boot within about 45 sec, which was much better than the 2-3 minutes it was taking before. I still think this should be better. I then rebooted to a live environment to resize the /boot/efi partition to 512mb (Calamares set it at 300mb which was probably sufficient), resize /dev/sda2 (Manjaro) to 100GB, and added /dev/sda3 (30GB) and /dev/sda4 (the remainder). Rebooted to Manjaro and it was the same, about 45 sec to boot. I then booted to a live ArcoLinux USB and installed it to /dev/sda3 using Calamares.

Reboot to Manjaro broke. I checked my boot order in BIOS and Arcolinux had superceded Manjaro so I moved Manjaro back to spot one and was able to boot to Manjaro. The Manjaro bootloader/grub screen was finally showing up, and showing up with all expected options. Boot still takes about 45 sec.

I then rebooted to ArcoLinux to test and it was fast! Maybe 10 seconds. This is what I was hoping for when I replaced the SSD.

When I run sudo update-grub in Manjaro I get some strange output regarding nested partitions and so forth. I'll start another post on this issue and link it back here.

Thank you for your guidance!

Spencer

This is definitely of interest to me. I learned last night after I got things somewhat operational that when I installed LibreCad (for example) in ArcoLinux I could not access it when I was booted to Manjaro. Additionally, the appearance of LibreCad was different in each distro. I did not have time to explore this because it was time to put my boys to bed. None of this is really surprising to me and I haven't had the chance to delve into either symlink or what @stephane offered. I'll continue to look into it but if it appears to be more than I can manage at this time, I may drop back to one distro for the time being.

Spencer

see if any specific service is holding it up, disable some that you likely wont use like ModemManager
systemd-analyze blame

check if entropy is under 1000
cat /proc/sys/kernel/random/entropy_avail

if its under then:
sudo systemctl enable haveged

reboot and see how it goes

Thanks dglt, I'll check that out.

I just posted a new topic on this and have my systemd-analyze blame in there.

Here is the link:

Spencer

Entropy is 3628.

No services listed as taking more than 1 second of time.

It's an interesting case and .. very common. I also have multiple installations and users, though I prefer the simple solutions, like "don't mix user home folders between different DEs and installations".
There are plenty tools to adjust a workable scenario for this kind of undeciding users :laughing:.
I have in my ToDo list to experiment on this scenario, in time..
If you get into the mood to try, I can give you a summarized list and troubleshoot on a new topic:

  • On each different installation
    • Create a group for the "same-real-user" accounts with a unique name and GID, like spencerswith GID 1010
    • On your main user folder, set default GID and full access permissions to GID 1010
    • Set relevant defaults in ACL for having new user(s) to default GID 1010

Then, ..mmaybe.. you can use the same user folder for your user on different installations. It needs a lot of RTFM on ACL, setfacl, getfacl and adequate experimentation to make it "safe" for everyday usage.
Of course, there is already a users group, but is not used by default on Manjaro installations ACL setup. And correctly IMHO, as it is safer to have a "clean multi-user" system. Anyway, there is no (technical) sense on using more than one user account on a system, or more than one installation for a workstation. It's just human passions.. :sweat:

1 Like

In the past i have done that when dabbling with dual/multi-boot experiments. Whilst it does let the one user access her data files from the different boots, it by itself does NOT assist with the question i posed above, which is not a matter of permissions, but of version mismatches:

Summary

Forum kindly sponsored by