Mageia forum

I have not been on here for a while. The old Dell up and died on me. Built a new box and have been setting it up and learning to use something quite a bit newer than the 2008 Dell. Specs in sig.

As this is a new MB it runs on uefi. Has legacy bios boot support and that is what is going on with my internals as I just put the old drives in to see if it would work and it did.

But I have an external formated to GPT. This is where I am attempting to install Mageia 5. Install seemed to go well. Installed from the DVD image. Image was put on a usb stick using dd. md5sum was correct. I disabled the onboard sata support before installing so that the internal drives would not be a factor.

Doesn't boot. In my boot menu I get 3 entries for Mageia.

The first seems to be the one is the default. Uefi "bios" set to boot from usb device first, this is the option it picks. Selecting it causes the screen to go black, then the Asus logo reappears with nothing else on the screen. That is permenant and only the power button will cause it to reboot.

Second option is really strange. Boots to a menu. For the install media. Can find no trace of the install media on the drive. Have not tried booting from this menu.

Third option tells me I need to mount the kernel first and lands me in grub rescue mode. This I am not expert at and have had no luck with.

This was true with on board sata support disabled and enabled.

But opening the file system for the new install it all looks like it is there. The fat partition for efi boot is there. Populated even;

Code: Select all

sam@lounge:~$ ls /mnt/EFI/EFI
BOOT  mageia


Code: Select all

sam@lounge:~$ ls /mnt/EFI/EFI/BOOT
bootx64.efi  fonts  grub.cfg  themes


Code: Select all

grubx64.efi


/etc/fstab has this entry;

Code: Select all

# Entry for /dev/sda1 :
UUID=F693-0385                            /boot/EFI     vfat umask=0,iocharset=utf8  0 0


/boot/EFI is unpopulated. This seems to me to be the problem but can't for the life of me figure out what to do about it.

The drive was set up using gparted to create the GPT on the old Dell. This could be a problem. I was, at that time, simply interested in trying GPT. Love it.

Only thing on the drive currently, besides the the new install (efi, /, /home /Shared (data), /swap) is the Shared data partition. This contains some stuff, way out of date, from the data partitions on the 4 internal drives. Linux files I have written/collected as notes on administration and so forth, music, movies. Nothing I can't simply delete with no problem.

One solution I am thinking about is simply wiping the drive, let Mageia reformat the thing from scratch and add the same partitons leaving about half the drive empty for future installs.

This might work. But I would rather wait and see if someone has an idea about fixing this problem. Seems like it should be curable. This is my first attempt to actually boot uefi and would like to actually learn something rather than simply reinstall and hope for the best.

Could be I simply did something wrong during the install process. I am much more familiar with the Debian installer and most Debian branch installers are very similar to it. So I feel this is a very possible cause.

Will be happy to provide more info. May be on here in a rather spotty manner until the weekend. Work is so inconvenient when you have an interesting problem.

Hello widget,

As it is an Asus m/b if you press "F8" while the Asus splash is up, you should get a list of bootable devices.
see if the external device is listed, maybe 2 times, one as UEFI, the other not.
this is mine, but all drives are internal
I have a UEFI 64dvd + usb connected.
the first in the above list : Mageia (P1: St316.... is the UEFI boot for Mageia )
check also to see if you have boot options: uefi or legacy or both enabled.
if you do, disable uefi, you should be able to choose the non-UEFI Mageia and it should boot.
if that works, enable the boot uefi option, choose the correct image from your F8 boot list and see if that works

best regards

Thanks for the reply.

First I need to explain that while I did say I may be slow in replying I certainly didn't mean this long.

About an hour after posting that our power, entire county, went down. Microburst knocked out 12 (at least) transmission line poles. Just got line power back late yesterday and we have all been scrampling to switch back from generators running just refrigeration devices.

Much better than the 10 days we lost the same transmission line in 2012 to a huge wild fire though.

That P1 entry looks like the one that is chosen by default here although it isn't P1.

The internal sata connection was disabled when I installed as I am using the legacy MSDos bios type boot internally. I am trying to learn to use the native uefi boot with this install.

I will definitely recheck the settings in the uefi bios. I am pretty sure, however, that I got that right. The Mageia documentation says that if the system is running bios or in bios boot legacy support it should boot to the mbr installer boot screen. It did the first time I booted the image. Fixed that and the correct boot screen for uefi install came up.

Also everything except for /boot/EFI looks correct to my admittedly ignorant eye.

Could be there is a problem due to the bugger on a usb external. May have to simply physically unplug my internals and plug a drive in there to get this to work.

Don't know. So thought I would give this a a whirl and see is someone had some idea where I screwed up which I think is pretty possible.

So I will be running through the settings with the manual for the MB open once again. Chapter 3 is getting a lot of use.

Been reading on efi/uefi too for some time now. Too bad they couldn't just use efi straight up. Sounds like it works really slick. But MS is the big dog on the block and really does need that rediculus vfat partition so its antiquated file system can read it.

So I better learn how to do this.

I am a multi booter, need a 12 step program probably, and usually run Debian. Debian doesn't have the documentation or, as far as I can tell, the quality of implimentation of uefi that Mageia has. So seeing how I really like Mageia and have it on my loaner drive so people can try it and some other distros out I figured this was the best bet to learn on.

Intend to redo all the internals to run on the uefi boot when I get it figured out. Didn't from the start because slapping my sda drive into an external drive booted right up using the legacy MBR boot. This meant I could just use the drives from the old box as they were. Needed to do that anyway to make sure they actually were usable anyway after having the cpu fry in the old box.

The Dell was nice but the cpu cooling system was about impossible to clean out and Dell doesn't believe in sensors so you have little warning. Won't be getting another one.

This box has a cooling system that works, can be cleaned, and sensors. Also a good bit more robust.

Case doesn't look as cool though. Just an ugly black box with a lot of fan capacity and great air flow. Hardware all selected for Gnu/Linux friendliness.

I did salvage the card reader out of the Dell. Won't mount right in any case not from Dell correctly of course. Plug to the MB had to have a tpb cut off it that was there only to prevent use on a MB not from Dell. Mounted it in one of the bay in this box and put the bay cover back on over it and have to pull that out to use the card reader. But only need it about once a month for my camera card. That works fine. Put a couple of cup hooks into that front panel plug for ease removal. Hang my usb sticks on the hooks.

First off, don't worry about /boot/EFI being empty - this is normal when the system isn't live. /boot/EFI is just the mount point - a placeholder in the root filesystem where the ESP can be mounted when the system boots.

I know at least one person in the QA team tested installing onto an external drive, so in theory this should be possible.

Can you post the contents of /mnt/EFI/EFI/Boot/grub.cfg. That might give us some clues.

The other thing to look at is /root/drakx/ddebug.log on the installed root filesystem. This is the log file from the installer. You should find some messages about installing the bootloader near the end of the file.

Very sorry for the long delay. Been working some 11 hour days and it is very hot here and that just drags a feller down.

/boot/EFI is empty. This is what my concern about this install is. That obviously should have something in it but I haven't any real idea what it should be.

Is it just a copy of what is in the ESP?

The /boot/grub2/grub.cfg file seems to be good. Calls for root on 'hd0,gpt2' and the guid or whatever uuid is called in GPT is correct.

It is apparent looking at that file that the drive is being treated as the only drive on the system. I am accessing the files from my internal drives so it is mounted now as sdi.

But sda1 is the ESP, sda2 is /, sda3 is /home, sda4 is /swap and then there is a populated data partition, /Shared on sda10. That last number is left over from when there were more partitions on this drive.

Have been thinking about this and hope to mess with it yet tonight.

Not sure that the GPT is really clean. So may simply let the installer work its automagical install on the whole drive. I don't like doing that because I tend to have a lot of installs and, frankly don't trust scripts to partition drives in the first place. So I am a control freak.

But I would like to attempt to put something in /boot/EFI first. Something has to go in there.

I guess from your post that simply copying the /boot/grub2/grub.cfg file to /boot/EFI/EFI/Boot would be a good guess. I am assuming that the /mnt in your post was meant to be /boot here. /mnt in the Mageia install is empty.

But, and this looks like a large but, looking at /root/drakx/ddebug.log, a file I have no real idea what purpose it has but gather it has to do with installation, is pretty much a wash for me to try to understand. I have run Mandrake and Mageia but am a Debian user. This file, while certainly interesting and, even to me, somewhat informative about the installation process, is unlikely to help me here.

I use pluma as standard text editor and using the find function with efi as the search I can filter it down a bit though. I am starting to wonder if what I have is simply a copy of the install image or, perhaps a combination of the install image and an attempted install.

I have only one out of 3 boot choices that actually puts up a menu and that is the efi install image menu. So that is strange to no end to begin with.

In the /root/drakx/ddebug.log at line 5263 we have
* setSelectedFromCompssList:

That goes on and looks similar to a Debian dpkg set-sellection list of packages. Appears to be a KDE install while Xfce was selected and KDE carefully unselected in the installer. But just speed scanning it gives the impression that KDE should work.

At 6282 we have another;
* setSelectedFromCompssList:

Which appears to deal with sound and video. And networking. Again simply scanning it looks like it should work. Calls for the proprietary radeon blob which I normally do not use but decided to OK in this install just to see how it does.

At 10835 we have another;
* setSelectedFromCompssList:

Which seems to install Xfce.

Way down at the end it looks like the installer was convinced it had worked. Exited with no errors.

Only off note is just before all that at 17251 through 17269 which reads like;

Code: Select all

* running: losetup /dev/loop1 /mnt/root/drakx/replay_install.img
* mounting /dev/loop1 on /mnt/root/aif-mount as type ext2, options
* running: fsck.ext2 -a /dev/loop1
fsck.ext2: Bad magic number in super-block while trying to open /dev/loop1
/dev/loop1:
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

* mounting /dev/loop1 on /mnt/root/aif-mount as type vfat, options
* running: mount -t vfat /dev/loop1 /mnt/root/aif-mount -o check=relaxed
* calling umount(/mnt/root/aif-mount)
* running: umount /mnt/root/aif-mount
* running: losetup -d /dev/loop1
* pid 3504 returned 0


But that doesn't tell me a thing. For all I know pid 3504 should return 0. Or could be the indication of a real wreak.

/root/drakx/replay_install.img means nothing to me at all but is 196.6kB. Have no idea if this is something important or simply harmless ditritus of the install process.

After looking at that /root/drakx/ddebug.log file I am not sure what I should do. Being still tired maybe I will simply wait to see what other interesting gems this thread comes up with.

Only thing that I have really seen is that I appear to have attempted to install KDE with Xfce and so will, even if this can be resolved to the point of booting up, have to reinstall and see if I can get it right. I started out as a KDE hating Gnome user. Can't say I like KDE any better now but prefer it to Gnome 3. I really like Xfce.

Have heard people say that the plethora of DEs in Gnu/Linux is a fault and discourages people from using it. I don't buy that a bit. I think that anyone should be able to pick a DE, from the existing stock, and find something that works for them better than any other base OS can offer. And there are new ones occasionally that may appeal too.

I always have OpenBox, KDE, Gnome 3 (GS), Mate and Xfce on my loaner drive and should probably add Cinnamon. People can try them out and see what they like. I try to set them up so they are more than default ready to go but not much so people can tinker with them on their own. Put a Notes document on the desktop with some pointers as to where to find menues and config tools.

Mageia does a nice job on the defaut KDE that I can live with. Usually, on the loaner drive, Mageia has both KDE and Gnome 3 on it. As an ex Gnome user I find it really irritating that I prefer to log into the KDE session.

The install I am working on now is on a drive to be dedicated to distros that I want to use about once a week or so, maybe more, to get to know them as I would want to use them if using them all the time. So I really want to get Xfce all by it self on this one. Liked Mageia 3 a lot with Xfce on it. Needed a bit of work to get it as I like it but nothing hard to do.

When I simply can't stand not using them more often then they get migrated to my internal drives. Was just about to do that on my old box when it up and fried on me.

As I want to move to uefi boot on the internals I need to get it working, if I can, on the external. Then I will have at least one distro that I know how to deal with this new system on. So Mageia 5 is in for an extended asault until I get this through my thick head.

I will pop over to the external, with the internals disabled and try all the boot options again. Will, for sure, be attempting to use that weird install boot menu to see what happens.

hello Widget,

widget wrote:Been working some 11 hour days and it is very hot here and that just drags a feller down.

I understand that work can get in the way of the really good stuff in life.

For the many UEFI installs that I did before Mga5 was released, I only ever used the "custom disk partitioning" option during installing as I had my main system on one internal HDD and a second internal HDD for test installs and I didn't want to screw up my main system booting.
Try enabling the legacy boot option again and see if you can indeed boot from the external, use "F8?'' to choose.
It wont be UEFI but at least you will know that the external HDD is booting.

So, if you are prepared to install yet again, use the custom partitioning and set the /boot/EFI onto the external.
Once installd, reboot and then "F8?" to choose the boot device : mageia [external device identity]

widget wrote:/boot/EFI is empty. This is what my concern about this install is. That obviously should have something in it but I haven't any real idea what it should be.

Is it just a copy of what is in the ESP?

No, it's a mount point - a way to access the ESP from the root filesystem. What happens is that when you boot the system, the OS reads /etc/fstab and for each entry "mounts" the specified drive/partition on the specified mount point. So the fstab entry you quoted in you first post:

Code: Select all

# Entry for /dev/sda1 :
UUID=F693-0385                            /boot/EFI     vfat umask=0,iocharset=utf8  0 0


means mount the partition with a UUID of F693-0385 at /boot/EFI.

A mount point is just a convenient (normally empty) directory in your root file system. Once something is mounted there, the OS transparently redirects any reference to that directory to the mounted filesystem.

At the moment you are looking at the external drive from your old installed system. That, of course, has only mounted the entries in its own /etc/fstab (and in its own root partition). That's why you would expect to see /boot/EFI empty on your external drive.

widget wrote:I guess from your post that simply copying the /boot/grub2/grub.cfg file to /boot/EFI/EFI/Boot would be a good guess. I am assuming that the /mnt in your post was meant to be /boot here. /mnt in the Mageia install is empty.

Yes to the second part, I was referring to your original post where you had the external drive ESP mounted on /mnt/EFI. But for the first part no, I was interested in what was already in /EFI/Boot, as, AFAIK, the Mageia installer doesn't put anything there. I've just tried an install onto an empty USB stick, and the only thing it created in the ESP was /EFI/mageia/grubx64.efi. FWIW, my install worked and booted without any problem. I used custom partitioning with separate partitions for /boot/EFI, /, and /home, which resulted in this:

Code: Select all

# fdisk -l /dev/sdf

Disk /dev/sdf: 14.8 GiB, 15854469120 bytes, 30965760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A8B11DB2-5597-4F23-8B2E-26C0AC4CE215

Device        Start      End  Sectors  Size Type
/dev/sdf1      2048   524288   522241  255M EFI System
/dev/sdf2    526336 16908288 16381953  7.8G Linux filesystem
/dev/sdf3  16910336 25100288  8189953  3.9G Linux filesystem


Looking at the USB stick ESP from my normal installed system, I see:

Code: Select all

# mount /dev/sdf1 /mnt
# tree /mnt
/mnt
└── EFI
    └── mageia
        └── grubx64.efi


All the other grub2 files are on sdf2 in /boot/grub2.

UPDATE:

Having written this, I've just tried to boot from the USB stick in my other machine (with an ASUS motherboard), and it fails, going straight back to the BIOS. So maybe this is a bug in (or limitation of) the ASUS BIOS. I normally use the rEFInd boot manager, and going via that, I can boot from the USB stick and get to the grub2 menu.

Thank you very much.

Had no time last night to actually get over to my Mageia install. Don't really tonight but am going to anyway. This is just too interesting.

What is the content of /boot/EFI/mageia/grubx64.efi?

More and more I think the problem is, at least partially, a picnic problem. Last night I had no problem mounting the external drive. Tonight I can't.

Code: Select all

root@lounge:/home/sam# mount /dev/sdi /mnt/Mageia1R
mount: wrong fs type, bad option, bad superblock on /dev/sdi,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.


running dmesg | tail gives;

Code: Select all

root@lounge:/home/sam# dmesg | tail
[182034.075756] scsi 11:0:0:0: Direct-Access     WDC WD50 00AAKS-75A7B0         PQ: 0 ANSI: 2 CCS
[182034.076549] sd 11:0:0:0: Attached scsi generic sg8 type 0
[182034.077518] sd 11:0:0:0: [sdi] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[182034.078368] sd 11:0:0:0: [sdi] Write Protect is off
[182034.078371] sd 11:0:0:0: [sdi] Mode Sense: 00 38 00 00
[182034.079249] sd 11:0:0:0: [sdi] Asking for cache data failed
[182034.079253] sd 11:0:0:0: [sdi] Assuming drive cache: write through
[182034.153241]  sdi: sdi1 sdi2 sdi3 sdi4 sdi10
[182034.156975] sd 11:0:0:0: [sdi] Attached SCSI disk
[182091.555803]  sdi: sdi1 sdi2 sdi3 sdi4 sdi10


/dev/sdi1 is a 500MB partition and formated to fat16 and I think that fat 16 is incorrect. I think it should be vfat.

I hvae both fdisk and gdisk installed.

Output from gdisk;

Code: Select all

root@lounge:/home/sam# gdisk -l /dev/sdi
GPT fdisk (gdisk) version 1.0.0

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdi: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D5217F8A-81A8-4519-A038-D76321DE1F74
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 2048-sector boundaries
Total free space is 376655850 sectors (179.6 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1024000   499.0 MiB   EF00 
   2         1026048        31744000   14.6 GiB    8300 
   3        31746048        83263488   24.6 GiB    8300 
   4       973111296       976773119   1.7 GiB     8200 
  10       459913216       973111295   244.7 GiB   8300  Shared


output from fdisk;

Code: Select all

root@lounge:/home/sam# fdisk -l /dev/sdi
Disk /dev/sdi: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D5217F8A-81A8-4519-A038-D76321DE1F74

Device         Start       End   Sectors   Size Type
/dev/sdi1       2048   1024000   1021953   499M EFI System
/dev/sdi2    1026048  31744000  30717953  14.7G Linux filesystem
/dev/sdi3   31746048  83263488  51517441  24.6G Linux filesystem
/dev/sdi4  973111296 976773119   3661824   1.8G Linux swap
/dev/sdi10 459913216 973111295 513198080 244.7G Linux filesystem

Partition table entries are not in disk order.


I am sorry to admit that creating partitions with either fdisk or gdisk is beyond me. I prefer to use cfdisk to create MSDos partitions. Am using cgdisk for this last install attempt.

Opening cgdisk and checking the code for sdi1 I see it is listed there and in gdisk as EF00

If you hit Type in cgdisk you don't get a list of types. You get the opportunity to enter a type or the command "L" to see a list of codes for types. This exits cgdisk and puts you back in normal terminal with said list output there.

There are 3 EF0* possible codes. And they, unfortunately do NOT indicate that the fat format is bad.

Code: Select all

ef00 EFI System           
ef01 MBR partition scheme 
ef02 BIOS boot partition


The fat16 designation is what gparted is reporting. While I admire gparted a lot, particularly its ability to copy/paste partitions with great success, I don't really like the slightly sloppy way it creates ever so slightly overlapping partitions.

This is why the original format of the external was done on gparted on my old box. gdisk was not available at the time with full function, in my case meaning cgdisk. When I did this install I used cgdisk on the drive to get rid of all partition other than the data partition (sdi10) and /swap. The starting partitions; sdi1, sdi2, and sdi3 were created with cgdisk.

This was interesting because it left slightly more than 1MB free space between the start of the drive and sdi1 (1007KiB) and then 1023.5KiB between 1 and 2 and between 2 and 3. I had read that some GPT partitioning agents did this for "future possible maintanence needs". Gparted is not equipted to see these gaps apparently as they do not show up.

That last reinforces my thinking that while gparted is a great way to look, in a graphic way, at your partitons it is not the tool to actually create the things.

Just thought I would answer this tonight. Tomorrow promises to be a very long day and I may just collapse when I get home. This was written while actually following my ideas about looking into the Mageia install and GPT of that drive, I hope it is coherent enouugh to follow.

If not I will try to make it more clear when I am on here again, hopefully, tomorrow but that is very questionable.

One final thing. I did do an install using the "Install from USB" as opposed to "Install from DVD" options on the boot EFI install menu. This gave me an install on the external but had the ESP on the stick wiping out the install image. This did not boot either. Unfortunately I knew even less then than now and simply redid my dd of the stick to put the install image back on it and use the "install from DVD" option for this install. I think the results are much better but rather strange none the less.

I certainly hope this is not a bug in the Asus uefi bios.

On the other hand it would make future installations easier because I actually know how to do MSDos mbr installs, using GPT which is sooo much better than the MSDos PT. But I will not be in any hurry to change my internal drives if continuing with the mbr boot installs.

I really want an external that will boot uefi. Most boxes in this very small rural community are mbr booting. So it is not a real problem. But I would like to have a loaner drive that would boot uefi straight up.

Actually I would like to have my drives all boot that way. But if it is not to be that will be fine too. Do want to build, when I can afford it, another box. Will go with an Intel using MB. They should support true uefi boot if any will.

This board is a AMD 6 core (FX6300). I am in love.

But I really like my old quad core Intel too.

widget wrote:root@lounge:/home/sam# mount /dev/sdi /mnt/Mageia1R

Try to mount the first partition, not the whole disk:
mount /dev/sdi1 /mnt/Mageia1R

lula wrote:

widget wrote:root@lounge:/home/sam# mount /dev/sdi /mnt/Mageia1R

Try to mount the first partition, not the whole disk:
mount /dev/sdi1 /mnt/Mageia1R

Let that be a lesson to all sleep deprived people. Don't mess with your box when more stupid than usual. Thank you for that. I can now stop thinking about that "error" which turns out to be a picnic error.

For those not familiar with that term it is Problem In Chair Not In Computer (PICNIC). Many more problems are exactly that than any of us wants to admit.

Usually they are from ignorance and so nothing to be ashamed of.

This one is embarrassing to me. I am the guy that is supposed to point out such simple things to people.

Humble Pie, by the way, is not all that great but it is good for you so thanks again.

Issue is now moot anyway. Reinstalled last night keeping in mind some things learned since the last attempt. Report to follow.

Tried booting to the external last night. Didn't work well. No surprise there.

Default chosen by the uefi bios gave me the menu screen from the uefi boot install menu. Selecting the "Install from DVD" (however that is correctly stated) gave me the result that the image could not be found. This was a relief as it shouldn't have been found because it is on a usb stick that, at the time, was hanging on its hook. Only question is where in the sam hill (favorite saying of my father) the menu screen comes from.

Only had one, instead of the two, other boot options for the external and it couldn't find the kernel so all I got was the grub cli with the statement that the kernel needed to be mounted first.

Rather than play with that, which I had done in a poor fashion before (not real familiar with the grub cli), I booted to the stick with the Mageia 5 image on it.

This time I didn't fool around and simple let it format the drive completely. I didn't let it create the partitions like it wanted as it appalled me with the size and placement there of. All installers do this. It is just a thing with me not the installer. But I got a ESP, /, /home and /swap on the bugger and the installer was happy with them.

Went through the install and attempted to boot to the install. Once again I get nothing but that error that the kernel needs mounted first.

So what we have now is an ESP with /EFI/mageia/grubx64efi.

/boot/EFI, which I was instructed was required for a mount point for the ESP, is completely unpopulated.

Having nothing to do with booting directly but maybe to do with the quality of the image (md5sum correct) is this question.

Mounting sdi3 (home) I find a /home/man (Manny Moore - bad humor but it makes me chuckle) that only consistes of /man/tmp. Is this normal for a Mageia install of Xfce? There are the expected ~/.foo files. Yes I looked and this matches the /etc/skel file in my file browser.

It doesn't match the output of;

Code: Select all

root@lounge:/home/sam# ls -a /mnt/MageiaR/etc/skel
.  ..  .bash_completion  .bash_logout  .bash_profile  .bashrc  .screenrc  tmp


which includes the ". .." entries. These in my Debian /etc/skel are what is responcible for the default folders that are common in most installs across most distros and were certainly the default in Mageia 3 with Xfce, and the loaner drive install of Mageia 3 with KDE/Gnome. So I thought I better ask about that to see if anyone thinks this indicates a problem with the installer.

Frankly I thought it worked pretty slick and wrote all this off as not being KDE or Gnome and therefore not fully supported. I don't use all those default directories anyway so really am relieved to not have to delete most of them. I am worried that, not being familiar with the installer I may have screwed up something but the only real likely place was the format and mount point for the ESP and I did do that wrong and the installer refused to go on until I had corrected it to the satisfaction of the installer. I thought it was pretty clear and precise in its responce and directions.

Am going to try adding somethnig to the /boot/EFI directory to see if that does anything. May try a couple different things. Can't say for sure, at this point, what they may be exactly. Will report on this later though with all the, probably, rather silly details.

Always had difficulty with EFI handover boot in BIOS.

I only ever got this working using a Boot manager (rEFInd).

There seams to be a lot of inconsistency with BIOS and where the ******.efi goes along with the naming convention, ASUS BIOS and EFI are the only ones I have had luck with. I have had /efi/EFI/boot.efi... /EFI/EFI//grubx64efi

As I said before, I bypass all that and use a bootmanager all the time. Grub I just got 1 headache trying to get an EFI boot.

Try rEFInd (Rod's Book's) he also has a great help section.

Just a suggestion...

Been down the long EFI boot install raod and always went back to a bootmanager EFI specific.

BUT anyway.. Search Rod's Books for pointers on the /EFI as a system partition.

I will let you know my install results soon EFI dual boot Mageia, W7, W10 and Ubuntu.

ALSO I only use gdisk for partitioning EFI systems now.. Nice powerful little tool.

Tried my bookmark for rodsbooks and it wouldn't work. Finally found a new link.

Sourceforge is not a site I am fond of but after reading for a couple hours I thought it may be worth a try.

Only package there doesn't include install.sh and is a debian binary. Have no idea what to do with it.

There is the "see all files" button. Sends me to a list of files going back years. Looked at one other and closed the site. I haven't trusted a thing from them for years. You just have no idea what you are going to get from them. Is is something the aledged author even knows about.

They have been scamming people for a long time that download Gimp for Win from there. I am not installing any binary from that site at all.

Well, embarrassing but true, I am able to boot to Mageia.

But had to install a netboot image with just the very basic stuff of Debian 8 (Jessie). Tried this when it was released and it didn't work at all.

I think that installing Mageia and having that installer set up the ESP is what caused this to work.

Will have to set up the rest of the Jessie install sometime but need to get Mageia 5 set up first. Looks very good so far. Have one problem when booting. Will start another thread on that.

Thanks for all the suggestions and support. I think I have learned a lot about this although I am still pretty confused about it. Need to do some more studying but think that I at least know enough to be able to find good sources of info.

widget wrote:Well, embarrassing but true, I am able to boot to Mageia.

Thats great news. UEFi is different for every mobo manufacturer, so its great you have persevered and nutted it out.

widget wrote:I think that installing Mageia and having that installer set up the ESP is what caused this to work.

Mageia installer creates /boot/EFI as per the UEFI manual, some other distro installers create /boot/efi and this can cause difficulties.

If only flash could be fixed and/or neutered, Mageia would be perfect, IMHO