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.