I have problems at the time of the update-grub in ubuntu, I get the error message "/ usr / sbin / grub-probe: error: can not find a GRUB drive for / dev / sda4. Check your device.map." / Dev / sda4 a / boot partition my lfs. help me sir ..

You need to provide more information about your drive setup. What is not evident here ts why GRUB is suddenly focused on /dev/sda4.

Grup has a problem in that it does not automatically delete obsolete boot entries. To get around this, just use this command: sudo rm /boot/grub/grub.cfg. This will force grub to create this file from scratch from your present configuration. See if that helps.

Just a note, I never install grub on my LFS partition.

I just do an update-grub from my host system that maintains grub for both
my debian host and my windows 7 install.

More info at:
man update-grub
man grub-mkconfig

It then adds the LFS partition as another boot option.
Then I have options to boot debian, LFS, or Windows7.
I find that much more simple.

So maybe uninstall grub2 on your LFS and try on your host system an update-grub as root or use sudo update-grub if you must.
Just insure your kernel is in the /boot directory of your LFS partition and your /etc/fstab is set correctly.

*** Before you do, backup your /boot/grub/grub.cfg on your host system in case you need to revert.

Hope that helps,
Tim

I actually have LFS on a separate drive.

Best way to get grub going is as follows:

I highly recommend you have LVM2 and other optional dependencies installed and Google how to setup the file /etc/default/grub for best results.

If needed, I also recommend using os-prober. If you need help installing it, I can get you a quick guide drafted.

yeap,
I also have my LFS on a separate actual hard drive and my host system boots from GRUB on an SSD.
I did have to manually adjust grub to boot the non initrd/initrmfs LFS system and edit /etc/fstab
In any case, so far so good using the host systems grub on a SSD setup as MBR.

Maybe this helps the OP:
https://www.gnu.org/software/grub/ma...b.html#Booting

A problem with grub is that every time it runs, the boot processes previously identified must all be present before it will boot any of them. That makes it necessary to scrub /boot/grub/grub.cfg of any boot entries that you don't want identified before attempting a boot. Call this a correction, and doing a correction before booting up to do the correction means thinking ahead.

You can always do the correction from a LiveCD, as the LiveCD just loads itself into RAM and is not concerned with the HDDs or removable drives and what is or what is not bootable initially.

You can do it before running sudo update-grub by keeping it from recognizing unwanted boot partitions. Say you had 3 bootable partitions on devices /dev/sda1, /dev/sda2, and /dev/sda3. and yo wanted to install UBUNTU 16.04 LTS onto a thunb drive at /dev/sdb with partition /dev/sdb1.

What would temporarily make /dev/sda1, /dev/sda2, and /dev/sda3 no longer appear bootable? Well, that depends on what operating system is set up on each of those partitions, and what does grub look for when it classifies a specific partition as bootable?

Maybe if you renamed a folder or file to be something else temporarily, grub could be fooled while sudo update-grub is running.. Then name it back as it was when update-grub is done.

But a simpler way is just to let sudo update-grub do its thing, then remove or comment out (put a # at the front of each line) any boot entries you don't want there from the /boot/grub/grub.cfg file. Not recommended, as this is where you can clobber your boot capabilities, but you are clobbered anyway if grub can't match up entries to what it actually finds present at boot time.

Worse thing that can happen in all likelihood is having to delete /boot/grub/grub.cfg and make it over again by running sudo update-grub from somewhere and then copying this file to each partition that has a grub boot process on it.

But I am speaking off the top of my head in terms of what might work. What I did for setting up an install on a removable drive is pick a laptop that had just had Win 7 wiped off it, and did the first install to a thumb drive. It was the the only bootable partition present, so its MBR and /boot/grub/grub.cfg reflected that fact.

Then i removed the thumb drive and did a second install to the reformatted internal drive on the laptop, and again update-grup only saw one boot partition available, but this time it was on the internal drive.

That gave me two installs initially, one on a removable drive, the other on an internal partition, and neither had a record of the other. Each gave me a master /boot/grub/grub.cfg file that I put under that name.

If update-grub runs, I just needed to use "sudo cp -f master /boot/grub/grub.cfg" and replace the new /boot/grub/grub.cfg with the old one. This works, because the active part just loads vmlinuz into RAM, and vmlinuz is always the latest Linux kernel once compiled. Any additions related to other boot partitions just get blown away by the overwrite.

If you want multiple boot options under any one partition, then you have to work that out a different way.

@Ned_Radd

You really shouldn't be manually editing /boot/grub/grub.cfg.

There is a template file used by grub to build the above mentioned file and that is where
your persistent changes should be made. On my debian system it is actually multiple files
located in /etc/grub.d

See the man pages and the README in that directory for more info.

IF you make your changes there, they will persist over grub updates and reboots.

Hope that helps,
Tim

Edit /etc/default/grub only. Nothing else.

This may be true on other distros's but not on debian.
Only edit or add files to /etc/grub.d/

If your host system is not debian, the name and location may be different.

It is not recommended, as I mentioned above to Ned Radd, to directly modify /boot/grub/grub.cfg


Thanks ReaperX7 for pointing out the differences between distros.

Edit: Just to note my /etc/default/grub file you mentioned has almost everything commented out.

Also, Editing these host files only applies when you use the host systems grub to boot LFS, not any grub installed on your LFS if for some reason you decide to go that way.

All the best,
Tim

Interesting the OP has not responded since the original post.

Got lots going on. I don't folow posts on a day by day basis, but just get back here if there ia indication of other activity.

I just replaced the hard drive in a Toshiba Satellite L355 laptop. The drive was unformatted, and I formatted it with great care. Do ir right the first time, and avoid later problems. But finding the right way was a challenge. I had it reasoned out as to how to try it, and so far the resulrs look good, according to testdisk. But I don't fully understand the use and options of teskdisk, and am trying to do specific extracts of the log produced as part of the process. From ther I either work out what was done on its end, and drom that i hopw to plan a recovery wffor od corrupted drives rhat nothing fixes now.

The bid geal is learning to use dd or other disk writing tool to write and read specific sectors on the hard drive. I'm told it can be done but not how. I also read I can do it in C, but I'm not a C programmer. Python or bash is more my speed. Also PureBasic.

As to /booy/grub/grub.cfg, I left that for now as to just to back it up and deal with that whole matter later. On the L355, I have nor yet committed to an install od any OS, but have used it to create 2 separate stick boot drives. I did this easily enough by only having one plugged in at a time.

The automatic upgrade-grub and grub-install process only find that one device to be bootable with an OS available, so they remain independent of each other and only reflect the hardware installed on. I've read that Linux can adjust to different hardware as it boots up, so I will be texting that deature going forward.

Like I said, lots going on.

Ned Radd,

You are not the OP of this thread.
Please consider opening your own thread for such discussions on topics per your previous post
that are not apparently related to the Original Posters concerns.

Thanks and all the best,
Tim