I mentioned this a while ago, I'm currently in Berlin visiting my family. With this usually comes PC repair, house repair, car repair, and similar stuff.
My dad has a somewhat older Xeon workstation of mine which is still in pretty good shape except for the Radeon HD6870 which is a Northern Island BARTS ATI graphics card. Funny enough it's older than my Southern Island CAPE VERDE card that I use in Mexico yet more stable...
Well anyways, when I left my family I handed this machine over to my dad and put KDE Neon on it (yeah I know,...) because I didn't have the time back then to update the Hackintosh it was before and I needed something that wasn't too intimidating.

Fast forward I deleted all that crap and chose to give FreeBSD a chance but man, really? Major nuisance to mount devices in general. Seriously, major nuisance. Makes me sad. Gave Funtoo a chance but the live ISO was horrible for me (sorry). It had several bugs right on the live image, not good. I would ideally have this be a fixed release cycle distro but then again most of those are just not acceptable for me anymore for different reasons. So I came back to Eric's Ferrari solution and I just happened to notice:

(Actually the installer got an update pushed yesterday, so I'm not sure what got changed. These observations are from Monday)
  1. The new installer is awesome, it's visually a new touch to an old software and I literally got from a used FreeBSD disk to a fresh Obarun in a few minutes (kinda, see below)
  2. Having not seen the installer for a few months this was a good opportunity to experience it as a user from scratch
  3. It's pretty intuitive even though I have to go through everything myself instead of being guided step by step. I actually prefer this very much over the older curses installers like Debian or FreeBSD
  4. Something that immediately had my attention in the FreeBSD installer was a wpa_tui prompt to establish a wireless connection right from the installer. That was great user experience to be honest, something that has always bothered me in the Linux world: networking while installing
  5. First hiccup: The guided partitioning is awesome! BUT: There was no mentioning of whether or not the disk was mounted after the formatting. Since I didn't recall the development phase on this I thought I'd rather exit the script to make sure I have the disk mounted in any case and to my surprise it got mounted by the script. This is really great but it needs a short informational message that this happened
  6. First bug: Apparently I chose to EFISTUB install, as always, and, again to my surprise, I got asked if I wanted to install microcode. I chose to do so but then there was no further choice to be made. This led me to believe that the script had some logic to find my CPU manufacturer. Something along the lines of lspci | grep "Host bridge" or whatever. Well it turns out the script does nothing at all. It neither downloaded any microcode package nor did it add an initramfs entry to the EFI entry. So I had to rewrite the entry manually afterwards and also chroot to install the microcode package
  7. Second hiccup: While in chroot I decided to add labels to the partitions, as I always do. This is non-destructive for regular partitions, but as far as my practice goes, Swap space can not get labelled without being recreated. This led to it getting a new UUID and my fresh install not boot after finishing the script. Had to become aware of this and manually edit fstab. This was not at all the fault of the script, just posting this users experience here
  8. Side note on EFISTUB: resume=UUID=SWAP-UUID could/should(?) be automatically written when Swap was chosen before as one does not consider this a "custom kernel parameter" I'd think. Also the microcode part of initramfs=\amd-ucode.img could/should(?) be put before initramfs=\initramfs-linux.img by the script if microcode was chosen as this also would not be considered a "custom" kernel parameter by most. In both cases maybe another line needs to explain this when prompting for custom parameters: "Do you want to add custom kernel parameters? We already included RESUME and microcode INITRAMFS parameters according to your choices." I hope I explain myself here
  9. Great work overall. I'm still kinda buffled over how bad most Linux installation experiences still are in reality today. Obarun is not one of them. Way to go!
I think this may be hardware related, but in some systems I've worked on the swap volume label is retained on others it is erased after the session. The uuid doesn't change though, it is just that the label gets removed.
One more note on the installed (dev-eric, I don't know whether this is the same behavior on master) when installing grub it asks if a /boot partition exists and if there isn't you should choose root
Now root may be /mnt but it may be other things the user named the mount point, and this can be used from inside a a machine with many other partitions. In my case /mnt was /dev/sdb2 way down the list. But where grub.cfg exists and where grub goes to an mbr are two different things and this can be confusing and dangerous for people using the installer first time.
grub.cfg can be within the root target partition or at a /boot partition in cases of efi, but grub is installed at /dev/sdb in my case not / or /boot
I think that part of the script should be clearer especially for bios installing.
Thanks for your feedbacks guys
Something that immediately had my attention in the FreeBSD installer was a wpa_tui prompt to establish a wireless connection right from the installer. That was great user experience to be honest, something that has always bothered me in the Linux world: networking while installing
Adelie has a good result with bcnm program, i will see if i can get the same result for Obarun.
First hiccup: The guided partitioning is awesome! BUT: There was no mentioning of whether or not the disk was mounted after the formatting. Since I didn't recall the development phase on this I thought I'd rather exit the script to make sure I have the disk mounted in any case and to my surprise it got mounted by the script. This is really great but it needs a short informational message that this happened
maybe a recap of what it did can be good
First bug: Apparently I chose to EFISTUB install, as always, and, again to my surprise, I got asked if I wanted to install microcode. I chose to do so but then there was no further choice to be made. This led me to believe that the script had some logic to find my CPU manufacturer. Something along the lines of lspci | grep "Host bridge" or whatever. Well it turns out the script does nothing at all. It neither downloaded any microcode package nor did it add an initramfs entry to the EFI entry. So I had to rewrite the entry manually afterwards and also chroot to install the microcode package
i need to investigate this
Second hiccup: While in chroot I decided to add labels to the partitions, as I always do. This is non-destructive for regular partitions, but as far as my practice goes, Swap space can not get labelled without being recreated. This led to it getting a new UUID and my fresh install not boot after finishing the script. Had to become aware of this and manually edit fstab. This was not at all the fault of the script, just posting this users experience here
this is a very case and you go over the script installation. I don't see what i can do for that.
Side note on EFISTUB: resume=UUID=SWAP-UUID could/should(?) be automatically written when Swap was chosen before as one does not consider this a "custom kernel parameter" I'd think. Also the microcode part of initramfs=\amd-ucode.img could/should(?) be put before initramfs=\initramfs-linux.img by the script if microcode was chosen as this also would not be considered a "custom" kernel parameter by most. In both cases maybe another line needs to explain this when prompting for custom parameters: "Do you want to add custom kernel parameters? We already included RESUME and microcode INITRAMFS parameters according to your choices." I hope I explain myself here
you're right, again i need to investigate this.

People complain about this installer:"So much complex", so "Stop to ask me to incorporate features" :p.
I'm kidding here
fungalnet wroteOne more note on the installed (dev-eric, I don't know whether this is the same behavior on master) when installing grub it asks if a /boot partition exists and if there isn't you should choose root
Now root may be /mnt but it may be other things the user named the mount point, and this can be used from inside a a machine with many other partitions. In my case /mnt was /dev/sdb2 way down the list. But where grub.cfg exists and where grub goes to an mbr are two different things and this can be confusing and dangerous for people using the installer first time.
grub.cfg can be within the root target partition or at a /boot partition in cases of efi, but grub is installed at /dev/sdb in my case not / or /boot
I think that part of the script should be clearer especially for bios installing.
Did you not see the message about the grub installation?
This will erase an already existing MBR.
If you don't want this behavior, answer no and install your bootloader manually
I can't handle every case for the bootloader even with os-prober which is not working for me
Yes forget os-prober, it is more trouble than it is worth (except for detecting and writing a windows boot entry - but we don't care I think, whoever cares needs to read wiki.arch ).

Yes, but when you choose to install grub it opens a list of partitions, one of them is the one for /mnt (if that is chosen for the installation) and the menu says choose root ... some people will be confused by this, they may think of root as the host of the installer not the target of the installation. The disk itself on whose mbr grub img goes to is not really listed, 2nd confusion.
Let's say you run the installer from /dev/sdc1 which is / target is /dev/sdb3 but on a bios installation grub really installs in /dev/sdb /boot/grub will be either on /dev/sdb3 or maybe /dev/sdb2 which is /boot ... I think the list is meant for choosing an alternative /boot partition, but it says if there is none choose root. So what is root :) If it $(/mnt) it shouldn't ask for specification, if there is another variable $(/boot) it should have already been known to the installer, so don't ask for it either. /boot should be specified in the beginning of the installation I think.

Sorry if I am confusing you more since I am not proposing specifically how it should be like, I just think it may confuse other people. It didn't confuse me because I am familiar with the procedure. I think you should run a debian image, remove grub and then reinstall it and see the menu you get. I think it has such accuracy that gives confidence to the user.

[ ] /dev/sda
[ ] /dev/sda1
[ ] /dev/sda2
[ ] /dev/sdb
[ ] /dev/sdb1
[ ] /dev/sdb3

check the boxes of where you want grub installed to. The 2 options are for mbr, the other 4 are for /boot or / partitions and more than one boxes can be checked. I don't know whether the blkid output can be drawn into this and whether checking multiple boxes is possible through the dialog programming.

Powered by Obarun