debian installer does not detect already installed Fedora system [solved]

[kau-92]

[EDIT : the fedora system was not available for boot, because I had separated the /usr and /root into two partitions when I installed that system. when I installed just to /root as one whole partition, the new fedora installation was available for booting from the grub menu]

Hello,

I actually had a dual booting Debian and Fedora system just a few days ago. I have a primary Debian partition set, and a secondary Fedora partition set.
I then wanted to separate the fedora installation into /boot, /, /home, /usr, /var, /tmp partitions instead of /boot, /root. I tried to make this change and things went wrong. Now I've deleted all the partitions I have and first installed Fedora again into extended partition as I wanted, leaving partitions for Debian to be installed later. I managed to log into that newly made Fedora.

Then I went to install Debian and it was successfully installed. But I had to change and remake the 2nd and 3rd primary partitions because otherwise system installation will fail with error (I had to change the partition structure, and I also formatted the debian /boot, /, /usr partitions).

Debian was successfully installed but it now does not detect the fedora system! it also said that if an existing system was not detected, its possible for me to configure grub ( to get the dual booting working).

I've tried to put on a 'menu entry' for Fedora in a grub.conf file somewhere. but I still don't get what to do properly. I'd like grub options to boot to the existing fedora installation, and a fedora recovery boot option.


Debian boots from the first partition: /sda1

Fedora /boot is installed in the 4th extended partition : in /sda12
sda13/14/15/16/17/18 are all fedora partitions.

[Aki]

Hello,
Which version of Debian and Fedora are installed ?
Does the computer boot using MBR or UEFI ?
Can you send a log about your computer’s partition (see sfdisk command) ?
Have you shared some partitions between the two operating systems ?
You could use the command (as root) to let Debian try to detect other operating systems with a MBR boot:

Code: Select all

update-grub

[FreewheelinFrank]

Which version of Grub? This is default behaviour in 2.06.

grub2 (2.06-1) UNRELEASED; urgency=medium

* Boot menu entries for other operating systems are no longer generated by
default. To re-enable this, set GRUB_DISABLE_OS_PROBER=false in
/etc/default/grub.

https://metadata.ftp-master.debian.org/ ... .06-3_NEWS

[p.H]

Fedora /boot is installed in the 4th extended partition : in /sda12

Logical partitions start at 5, so the 4th logical partition is sda8, not sda12.
Note that with so many partitions, you should consider using GPT or LVM instead of DOS/MBR with logical partitions. The linked-list extended+logical partition structure is fragile.

Does running os-prober detect Fedora ? I know two possible issues with your setup.
1) Fedora generates grub.cfg in way that Debian's os-prober/linux-boot-prober cannot parse properly, using "linuxefi" or "linux16" commands instead of the usual "linux" command to load the kernel image (patch available). But that should not prevent os-prober from detecting Fedora, only preventing it to retrieve the proper boot parameters.
2) Debian's os-prober detects a Linux system by the presence of /lib*/ld*.so* or /usr/lib*/ld*.so* in the root filesystem. However with combined /usr-merge and separate /usr, no such file is present in the root filesystem. A workaround is to create a dummy /usr/lib/ld.so file in the root filesystem while /usr is not mounted. IMO there is no point in setting up a separate /usr, unless you intend to mount it read only.

An alternative to os-prober is to manually create a boot entry pointing to Fedora's grub.cfg.in /etc/grub.d/40_custom

Code: Select all

menuentry 'Fedora' {
set root=hd0,msdos12
search --fs-uuid xxxx-xxxx # (replace with Fedora's /boot partition UUID)
configfile /grub2/grub.cfg # (adjust with actual pathname if needed)
}

and run update-grub.

[sunrat]

Which version of Grub? This is default behaviour in 2.06.

grub2 (2.06-1) UNRELEASED; urgency=medium

* Boot menu entries for other operating systems are no longer generated by
default. To re-enable this, set GRUB_DISABLE_OS_PROBER=false in
/etc/default/grub.

https://metadata.ftp-master.debian.org/ ... .06-3_NEWS

grub2 in Bullseye is v 2.04 so should still run os-prober during update-grub. (I always assume Bullseye if not advised otherwise. Poster needs to supply accurate details).

A burning question I have is - why so many partitions? As this is posted in Beginners Questions it seems unnecessarily complicated. I have about 6 Linux distros on one drive, each tidily residing in one single partition each.

[FreewheelinFrank]

Which version of Grub? This is default behaviour in 2.06.

grub2 (2.06-1) UNRELEASED; urgency=medium

* Boot menu entries for other operating systems are no longer generated by
default. To re-enable this, set GRUB_DISABLE_OS_PROBER=false in
/etc/default/grub.

https://metadata.ftp-master.debian.org/ ... .06-3_NEWS

grub2 in Bullseye is v 2.04 so should still run os-prober during update-grub. (I always assume Bullseye if not advised otherwise. Poster needs to supply accurate details).

Absolutely. But I have seen posts related to Testing installs, so some people do do it. Especially as a second OS perhaps - I installed Testing on this computer to play with* alongside Bullseye so the family can always use the computer even if I break Testing. Aki wisely advised OP to state version.

EDIT: *Which is how I became aware of this issue, because my Bullseye installation disappeared.

[p.H]

Which is how I became aware of this issue, because my Bullseye installation disappeared.

It means you let testing handle the boot instead of stable. Not a great idea IMO, because breaking testing may break the whole boot.

[FreewheelinFrank]

Which is how I became aware of this issue, because my Bullseye installation disappeared.

It means you let testing handle the boot instead of stable. Not a great idea IMO, because breaking testing may break the whole boot.

A very valued opinion. Is there any way to avoid that possibility? Not that it concerns me overly as I've been using Testing on my laptop for ages without breaking it, and nobody but me has actually logged into this computer for months 'cos they all have phones, tablets or laptops, but if there's a safer way of doing it a pointer would be appreciated.

[kau-92]

POST A
=======

Debian GNU/Linux 11 (bullseye) is installed
I installed fedora from Fedora Workstation Live 36 usb stick,
but I cant get into Fedora to find out the version.

Grub is : 2.04-20
I set GRUB_DISABLE_OS_PROBER=false in /etc/default/grub , but
it didn't do anything.


--------

"why so many partitions?"
=============================

no one actually instructed me on proper scheme for partitioning.

I was using the default schemes that come up, a good while ago, but,

I keep having the linux system break down evenctually. I don't remember
the exact errors now, but it was something like having to use fsck(?)
having the fix the file structure. then there was some nasty breakdowns
in the recent past twice. I couldnt boot due to a corruption or breakdown
in grub(I think it was). I was supposed to fix it myself, but have no enough technical
understanding to go into the small cogs and fix these things easily.

the solution I found was to separate the / folder from /home. Then I could replace the
/ folder and it sometimes allows me to get the system going again with old data.
Then I thought that if there was some corruption in the boot files, I could try to target
that partition and try to fix it with a diagnostic live usb, or reinstall the bootloader.

Then I heard that /usr folder contains most of the user applications installations, so I
thought that I could separate that from root also, and maybe retain the downloaded
software in case of a root or boot partition reformat/reinstallation.

I heard that tmp and var files build up over time and take up too much unnecessary space.
So I thought Ill have those in small partitions, and once they start filling, Ill just
empty them.

Sooo, I currently am blindly going on a scheme of
/boot - replace or repair boot files
/ - replace with new system installation if necessary
/home - separate own data so I could at least use a live usb to transfer user data to
a different device. or keep data untouched while replaceing system files.
/usr - hoping to retain installed software in case of a system replacement
/tmp /var - just empty these when they get full.

is that dumb? maybe. I know it's a bugger to specify this in the live usb system installer,
when the mount points also have to be specified.

All I want is to recover from the nasty system break downs, which I can't always manage
to fix by fiddling with system inner internals. Not when I don't know what Im doing.

question ??? the previously remaining /home data can be used by a new system installation,
right? i think that worked before. But I don't know if /usr data can be fixed onto
new installation. I don't quite know how to replace only /boot, or only /root. I thought
I'd say : don't format anything else, just format the partitions I specify (boot or root or both). Just mount the rest of partitions onto /home, /usr etc. does that actually wok?

? Is it right to have small /tmp /var partitions and just delete the lot once it's full?

? I don't know clearly how to just replace /boot , or /

--------


menuentry 'Fedora' {
set root=hd0,msdos12
search --fs-uuid xxxx-xxxx # (replace with Fedora's /boot partition UUID)
configfile /grub2/grub.cfg # (adjust with actual pathname if needed)
}

I could try that. But if the partitioning scheme Im using is no going I'll try to
reinstall both again. but if debian doesnt detect fedora again. Idk. maybe that /usr
separation is the problem. but Idk. x_x

haha. I've actually gone through a bit of pain upto this point...doing complicated partition
installations over and over again. and screwing up over and over again.

[kau-92]

--------

update-grub outputs this. there isn't even a 'detected debian'

root@oldred:/home/kaushan# sudo update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-5.10.0-13-amd64
Found initrd image: /boot/initrd.img-5.10.0-13-amd64
done


-------

os-prober doesnt output anything.

root@oldred:/home/kaushan# sudo os-prober
root@oldred:/home/kaushan#
root@oldred:/home/kaushan# sudo os-prober /dev/sda1
root@oldred:/home/kaushan# sudo os-prober /dev/sda12
root@oldred:/home/kaushan#

--------

sfdisk:

root@oldred:/home/kaushan# sudo sfdisk -l /dev/sda

Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Hitachi HTS72505
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: dos
Disk identifier: 0x2eb302a7

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 1175551 1173504 573M 83 Linux (d boot) 1 (disk diagram order)
/dev/sda2 1175552 40239103 39063552 18.6G 83 Linux (d tmp) 2
/dev/sda3 40239104 167192575 126953472 60.5G 83 Linux (d root) 3
/dev/sda4 167196670 976773119 809576450 386G 5 Extended
/dev/sda5 167196672 382042111 214845440 102.4G 83 Linux (d usr) 5
/dev/sda6 382044160 421107711 39063552 18.6G 83 Linux (a data partition) 6
/dev/sda7 421109760 694548479 273438720 130.4G 83 Linux (d home) 7
/dev/sda8 694550528 714082303 19531776 9.3G 83 Linux (a data partition) 8
/dev/sda9 877375488 908625919 31250432 14.9G 83 Linux (a data partition) 16
/dev/sda10 908627968 947691519 39063552 18.6G 83 Linux (d var) 17
/dev/sda11 947693568 976773119 29079552 13.9G 82 Linux swap / Solaris 18
/dev/sda12 714084352 715255807 1171456 572M 83 Linux (f boot) 9
/dev/sda13 715257856 757200895 41943040 20G 83 Linux (f root) 10
/dev/sda14 757202944 797048831 39845888 19G 83 Linux (f home) 11
/dev/sda15 797050880 814229503 17178624 8.2G 82 Linux swap / Solaris 12
/dev/sda16 814231552 827901951 13670400 6.5G 83 Linux (f var) 13
/dev/sda17 827904000 839622655 11718656 5.6G 83 Linux (f tmp) 14
/dev/sda18 839624704 877373439 37748736 18G 83 Linux (f usr) 15

Partition table entries are not in disk order.

( sda4 is the whole extended partition, the rest are nested inside of it)
(the partition diagram when I open 'disk', I remember that sda12/13/14/15/16/17/18 are
where I installed fedoda. I've got two swap partitions by error this time.)

(I've actually mounted the sda12/13/14/15/16/17/18 in debian. e.g. sda12 is in
/share/FD/boot, sda13 is in /share/FD/root )

------------

[p.H]

@FreewheelinFrank: Unfortunately it is not so easy to prevent the Debian installer from overwriting some part of the existing boot setup.

* EFI boot: if using the same EFI partition, testing will overwrite GRUB. If using a different EFI partition, it may still overwrite the "debian" EFI boot variable pointing to GRUB (depending on the UEFI firmware, some will create a second debian variable).

* BIOS/legacy boot: if testing is installed on the same drive and installs GRUB in the MBR, it will overwrite GRUB. Installing GRUB in another location (e.g. a partition boot sector) to avoid it is not always possible.

You can select expert install and skip installing GRUB, but this prevents os-prober from detecting the correct root= and other parameters.

It is probably simpler to let testing install its boot loader and reinstate the stable boot loader later if needed. Also uninstall the grub-$platform package (but keep at least grub2-common) in testing to prevent boot overwriting after a package upgrade.

[kau-92]

can someone advise me on this partition scheme thing. Is there a better way to do it.

[NorthEast]

kau-92 wrote:

can someone advise me on this partition scheme thing. Is there a better way to do it.

Perhaps consider the last sentence in sunrat's post #5 above.

[p.H]

I heard that /usr folder contains most of the user applications installations

Note: /usr is a directory, not a folder.
Actually /usr contains most system files installed by the package manager, not only user applications. "usr" stands for "Unix system resources", not "user".

I
thought that I could separate that from root also, and maybe retain the downloaded
software in case of a root or boot partition reformat/reinstallation.

No, you cannot reformat / and keep /usr. They are a whole.

I heard that tmp and var files build up over time and take up too much unnecessary space.
So I thought Ill have those in small partitions, and once they start filling, Ill just
empty them.

You cannot blindly delete all files in /var. All of /var contents is not disposable. For example /var/lib contains essential state information for installed applications, including the package manager itself. Even /var/cache should not be emptied unless you know what you are doing.

IMO:
There is not much benefit in separating /usr, unless you want to mount /usr read only.
There is not much benefit in separating /boot either, unless the root of the "main" system (the one which contains the active boot loader) is in a logical partition, because logical partition numbers are not reliable, so it is better to have /boot in a primary partition.
You can separate /home and keep it while formatting an reinstalling the rest of the system.
There is some benfit in separating /var and /tmp, such as avoid frequent write and space exhaustion in the root filesystem.
However creating so many partitions increases the risk of oversizing some partitions and undersizing others, and it will be hard to resize partitions in order to extend an undersized partition. LVM should be used instead, as it is much easier to extend logical volumes than partitions as long as you have free space in the volume group. Also LVM requires only one partition for any number of logical volumes, so you do not need logical partitions.

[sunrat]

can someone advise me on this partition scheme thing. Is there a better way to do it.

I already did. Put everything in one partition including /home. Create another partition and call it something like /data and mount that inside /home (or anywhere you want). That way if you have to reinstall, your data is safe from /home being overwritten. All you need then is a swap partition. KISS!
Also your Fedora install may be broken if os-prober doesn't see it.

If you are worried about breaking stuff, make full system backups. Also separate data backups. You should be doing backups anyway; drives will always fail eventually, usually just before you do your next backup so you lose the most (they are bastards like that ). See my signature. I use fsarchiver for system and rsync for data backups, both CLI programs but there are good GUI alternatives.

I was going to reply to a number of other points but there are too many for the time I have. One really glaring error you are doing is running commands with sudo even though you are already root. Pointless.

[kau-92]

I see. makes sense. I'll simplify the system partitions to a few, but will keep a separate data / home partition.

I hope the Fedora issue is, like one person above said, because I separated /usr from /root. hopefully having just root partition might
fix it.

Thanks.

[p.H]

It's easy to check. Create the dummy ld.so file and run os-prober.