No fdisk in LEAP 15.1 Rescue

English Install/Boot/Login
1

See title. Nor cfdisk, sfdisk, gdisk parted, gparted, or kparted. There is kpartx, but that’s different, right?

Seems strange that the rescue system doesn’t have a partitioning tool. I need one to debug some hardware problems. Lots of other utilities in /sbin, /usr/sbin, /usr/bin and /bin so doesn’t seem like a size problem with squashfs.

Also, how is this even possible? Isn’t install basically the same thing as the rescue system, just running an install script or executable? How does install do its partitioning?

Thanks for any help. I’ve run out of names of partitioning utilities to look for.

2

I just tested 15.1 Net image in rescue boot (More … Rescue System) and all tools are there - fdisk & Co, gdisk, parted. So you need to start with description what exactly are you doing and what you call “LEAP 15.1 Rescue”.

3

What, exactly, do you mean by “LEAP 15.1 Rescue”?

I have booted the install DVD to the rescue system, and “fdisk” is there. I’ll grant that “gdisk” and “cfdisk” are probably not there. But “parted” is there.

I have just booted the install DVD to the rescue system (in a KVM virtual machine). And I can see that “fdisk” is in “/sbin” and “parted” is in “/usr/sbin”. It turns out that “cfdisk” is also there (in “/sbin”) and “gdisk” is there (in “/usr/sbin”)

There is also the live rescue CD. Perhaps you mean that. I have not checked lately, but I would expect “fdisk” to be there. I would also expect “parted” to be there, because that is used by Yast Partitioner. I don’t have a copy of that iso handy, so I cannot check without first downloading.

4

Thanks, arvidjaar and nrickert for checking this out for me. I couldn’t believe fdisk and/or parted were missing.

Something strange is happening with the laptop I’m trying to install Leap 15.1 on. It’s an old Dell Precision M6500. I’m booting from an 8GB USB flash created with dd – many more excessive details on its creation below if you’re interested.

Booting from the flash drive works fine. I get the openSUSE lightbulb and the main graphical menu. From there things seem to work but go slightly wrong. I’ve tried various things like “More … → Rescue System”, “More … → Check Installation Media”, and plain “Installation”.

All produce similar results, but my main path is “More … → Rescue System”. This goes a standard Linux boot (text console with large font with long pause at “Starting udev…”, then more text console boot messages in a small font, then a green screen with progress bar.

This gets me to an old-school YaST blue text-with-graphics-characters menu with:

Please make sure your installation medium is available.
Choose the URL to retry
hd:///
cd:/
hd:/
Enter another URL

This is wrong, correct? It should know what it booted from. (Note also “Installation” and “Check Installation Media” also get to this menu.) None of the options work – choosing one or just doing “Back” gets to the standard “Select the language” and “Choose a keyboard map” menus. Then:

Main Menu
Start Installation
Settings
Expert
Exit or Reboot

And from “Expert”

Expert -- Time 08:58
System Informatin
Kernel Modules (Hardware Drivers)
Eject CD
Show config
Change config
Start shell

Doing “Start shell” gives a “console:install:/#” prompt and everything seems fine … except no fdisk in /sbin or parted in /usr/sbin. I just explicitly re-checked (thanks, nrickert, for the exact information on where they should be). As I said, lots of other binaries in those directories.

Bizarre, huh? If I have a bad image on the USB flash drive (see below) how could it get this far with the only visible problem being missing files in the running system’s directories? Same argument if there’s something tricky about the Dell BIOS (any hints appreciated) – the “Please make sure your installation medium is available” points to this.

I tried booting the laptop (which is old enough to have a DVD drive) with an old openSUSE-Leap-42.1 DVD and everything seemed fine. Certainly had fdisk in the rescue system. I’ll burn a 15.1 DVD and boot from that, but again, how could the USB flash drive be “semi-bad” like this?

Thanks again. Excessive details on how the flash drive was created follow:

$ cat openSUSE-Leap-15.1-DVD-x86_64.iso.sha256 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

c6d3ed19fe5cc25c4667bf0b46cc86aebcfbca3b0073aed0a288834600cb8b97  openSUSE-Leap-15.1-DVD-x86_64.iso
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iQEVAwUBXNwZzbiLL9Q9vcKEAQiXAggAsmtTRD1HausbkO0M5vEVBfeoefCowntG
jz8/kbmPFxDvHuRv/IUYx98NjCdOc/5svOs1PMXXaRtmBMc3/kQkr21BIn6rZye2
B4RsRAqvAJmNjSxrlA78VyX+F+oN+CsYg63xx87sO7dORoNX2VCLappXVIFxz586
8cQZNP9Rqpk5+eySpCyLJOgT5onxZbUjN3Q8uEPMyT+nzm8iqzx5EI75gJuKYWvh
nGLmKDLlH9S4MXM6Z1cinmSxMW5HCvTScmTgsRTnYLtuOblVj1RZbK+sws+Fnf8T
45WAYUYq23fv/kP4qfwvWwJma9SZWo7voLHtRiNlQFX4p6zi9C5apA==
=Cng2
-----END PGP SIGNATURE-----

$ sha256sum -c openSUSE-Leap-15.1-DVD-x86_64.iso.sha256
openSUSE-Leap-15.1-DVD-x86_64.iso: OK
sha256sum: WARNING: 14 lines are improperly formatted

$ dd if=/mnt/photos/tmp/openSUSE-Leap-15.1-DVD-x86_64.iso of=/dev/sdd bs=4M

$ cmp openSUSE-Leap-15.1-DVD-x86_64.iso /dev/sdd
cmp: EOF on openSUSE-Leap-15.1-DVD-x86_64.iso

$ /sbin/fdisk -l /dev/sdd

Disk /dev/sdd: 7.6 GiB, 8103395328 bytes, 15826944 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: dos
Disk identifier: 0x26ce2674

Device     Boot Start     End Sectors  Size Id Type
/dev/sdd1        2760   10571    7812  3.8M ef EFI (FAT-12/16/32)
/dev/sdd2  *    10572 7923711 7913140  3.8G 17 Hidden HPFS/NTFS

$ mount /media/sdd1  

$ ls -alRF /media/sdd1
/media/sdd1:
total 21K
drwxrwxr-x  3 mark users  16K Dec 31  1969 ./
drwxr-xr-x 15 root root  4.0K Feb 28  2018 ../
-rwxrwxr-x  1 mark users  118 May 14 18:04 .packages.grub2-efi*
drwxrwxr-x  3 mark users  512 May 14 18:04 EFI/

/media/sdd1/EFI:
total 17K
drwxrwxr-x 3 mark users 512 May 14 18:04 ./
drwxrwxr-x 3 mark users 16K Dec 31  1969 ../
drwxrwxr-x 3 mark users 512 May 14 18:04 BOOT/

/media/sdd1/EFI/BOOT:
total 3.3M
drwxrwxr-x 3 mark users  512 May 14 18:04 ./
drwxrwxr-x 3 mark users  512 May 14 18:04 ../
-rwxrwxr-x 1 mark users 1.2M May 14 18:04 MokManager.efi*
-rwxrwxr-x 1 mark users 1.2M May 14 18:04 bootx64.efi*
-rwxrwxr-x 1 mark users 2.6K May 14 18:04 grub.cfg*
-rwxrwxr-x 1 mark users 1.1M May 14 18:04 grub.efi*
drwxrwxr-x 2 mark users  512 May 14 18:04 locale/

/media/sdd1/EFI/BOOT/locale:
total 1.5K
drwxrwxr-x 2 mark users 512 May 14 18:04 ./
drwxrwxr-x 3 mark users 512 May 14 18:04 ../
-rwxrwxr-x 1 mark users  96 May 14 18:04 en.mo*


$ mount /media/sdd2 
mount: /dev/sdd2 is write-protected, mounting read-only

$ ls /media/sdd2       
CHECKSUMS      control.xml
CHECKSUMS.asc  docu/
EFI/           glump
GPLv2.txt      gpg-pubkey-307e3d54-5aaa90a5.asc
GPLv3.txt      gpg-pubkey-39db7c82-5847eb1f.asc
README         gpg-pubkey-3dbdc284-53674dd4.asc
SUSEgo.ico     media.1/
SUSEgo.png     noarch/
SUSEgo.svg     repodata/
boot/          x86_64/

$ find /media/sdd2 | wc -l
4377
5

I’m partly guessing here.

The kernel has been loaded. The “initrd” has been loaded. You would not get very far without those.

It looks as if the kernel is not recognizing or finding the USB that you booted. So your system is running on the ram disk from the “initrd”. And that has available only a limited set of commands.

That’s why it isn’t finding “fdisk” or “parted” – It is unable to access the disk that they are on.

This does not solve your problem. But it gives a different perspective that you might find useful.

6

It absolutely is useful. As always, thanks for your support.

Your explanation seemed plausible to me, and experimenting using it as a guide seems to confirm it. Greatly relieved: I didn’t see how a corrupt USB flash drive could be fine except missing some binaries. As usual, my lack of expertise tripped me up (I only vaguely understand the initrd process). Had the flash drive not booted at all I would have understood, but the fact that it brought up some kind of working system fooled me because I didn’t recognize the differences indicating it wasn’t the real Rescue system.

There’s something very wonky about this laptop and how it (fails to) recognize drives. I’ve switched the BIOS back and forth among AHCI, RAID, and ATA. Sometimes it recognizes its internal HDD by name (manufacturer and model number), sometimes it doesn’t (BIOS just lists “Internal HDD”). And I guess it never really saw the USB flash drive.

I burned a Leap 15.1 DVD and booted from that, and everything worked as it should. Did “Rescue System” and got the secondary boot after initrd, ending with:

...
 OK ] Started Update UTMP about System Level changes

openSUSE Leap 15.1 Rescue System

rescue login: root
Have a lot of fun...

tty1:rescue:~ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
tmpfs          tmpfs     7.8G  138M  7.6G   2% /
/dev/loop0     squashfs   71M   71M    0  100% /parts/mp_0000
/dev/loop1     squashfs   14M   14M    0  100% /parts/mp_0001
devtmpfs       devtmpfs  3.9G     0  3.9G   0% /dev
/dev/loop2     squashfs   50M   50M    0  100% /mounts/mp_0000
/dev/loop3     squashfs   46M   46M    0  100% /mounts/mp_0001
/dev/loop4     squashfs  4.2M  4.2M    0  100% /mounts/mp_0002
tmpfs          tmpfs     7.8G  206M  7.6G   3% /
tmpfs          tmpfs     3.9G     0  3.9G   0% /dev/shm
tmpfs          tmpfs     3.9G  9.1M  3.9G   1% /run
tmpfs          tmpfs     3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs          tmpfs     790M     0  790M   0% /run/user/0
tty1:rescue:~ find {,/usr}/{,s}bin | wc -l
1540
tty1:rescue:~ fdisk -l
...
</dev/loop0 through loop4>
...
Disk: /dev/sda ]: 465.8GiB 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/optimimum): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00065951

As compared to initrd’s login-less:

console:install:/# df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
tmpfs          tmpfs     7.8G  138M  7.6G   2% /
/dev/loop0     squashfs   71M   71M    0  100% /parts/mp_0000
/dev/loop1     squashfs   14M   14M    0  100% /parts/mp_0001
devtmpfs       devtmpfs  3.9G     0  3.9G   0% /dev
console:install:/# find {,/usr}/{,s}bin | cat -n
...
296 /usr/sbin

Note the many utilities in the “*bin” dirs, like ifconfig, the whole sg_* suite, and many others, but not fdisk or parted. Also no wc so I had to use cat -n. :wink:

Now onto figuring out what’s wrong with the laptop, and/or if installing from DVD will be sufficient. Thanks again for the help.

7

Thanks for confirming.

Apparently the BIOS can read the USB drive, but the kernel cannot read it. Or maybe the kernel cannot read it with only the modules loaded into that “initrd”. So, yes, there’s something strange about that laptop.

Stick with the DVD for now. Installing from there should be fine.

8

A final denouement to this, in case it’s of help to anyone else …

The problem definitely was that the kernel couldn’t read the USB drive. Reason: It was plugged into a USB 3.0 port for which there was no driver (or the driver wasn’t automatically found and loaded).

I wasn’t aware that the laptop had both USB 2.0 and 3.0 ports, but when I found out and booted with the USB drive in a 2.0 port everything worked perfectly – Check Installation Media, Rescue System, Installation.

When inserting a USB drive into a 3.0 port with the installed Leap 15.1 running, nothing showed up in dmesg/journalctl. Online searches seem to say that this is an NEC/Renesas uPD720200 USB controller which is known to have problems. Remember, it’s a 10 year old laptop. Suggestions were to update the controller firmware (with all the dangers that always involves, plus the need to make a DOS-bootable drive, etc).

Instead, I found an option in the BIOS to disable USB 3.0. I’d ignored that previously because I didn’t want to lose use of two of the laptop’s four physical USB ports. No explanation in the BIOS help text, but it didn’t disable them. It turned them into USB 2.0 (I believe using the CPU/bridge/whatever built-in Intel controller) and they now work fine on Leap 15.1. At some point I might restore them to 3.0 and look into finding a working kernel module for the NEC controller, but for now 2.0 is sufficient.

Thanks again for all the help.

9

Thanks for the update. It’s always good to understand what was going wrong.

10

Same problem. Made usb boot stick. Placed in hub and selected (F12) it to boot. Kernel loads, drivers load, start menu displays. Any selection that needs the install files pops a curl dialog asking to find the data; none of the options listed in the dialog help.

This behavior can occur when the usb stick cannot be configured by the kernel because it can’t draw enough power from the hub. I found the answer looking at the end of dmesg after running the old system and inserting the boot stick in the usb2 port (usb3 connections don’t appear in the F12 boot menu for most of the machines I currently work on). In the slew of usb log lines, there is one that says the drive has not been configured due to not having enough power from the hub. I created the usb boot stick in a usb3 hub with power because that was easy to reach compared to the usb2 hub; so it built just fine. But the driver could not configure the stick when inserted into the unpowered usb2 hub.

Well, well. This can be easy to miss because small usb sticks (say 8GB) draw less power than larger ones and small sticks I have work fine in the (unpowered) usb2 hub. My boot stick that fails is a 64GB stick. It’s actually difficult to find the smaller ones these days. Jeeze Louise. The gawds are laughing!

FWIW

Cheers,
Rufus

11

Being an enthusiast (speed doesn’t matter anymore) and a retired engineer (since 2 decades) I always use a low cost (5€) and known good stick (many .isos already written without a single failure) for installation:

**erlangen:~ #** lsusb -s 002:002 
Bus 002 Device 002: ID 090c:2000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Intenso Ultra Line 
**erlangen:~ #** fdisk -l /dev/sdc 
**Disk /dev/sdc: 29.82 GiB, 32023511040 bytes, 62545920 sectors**
Disk model: Ultra Line       
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: 0x7587f7c1 

**Device    ****Boot****Start****    End****Sectors**** Size****Id****Type**
/dev/sdc1        2660    9715    7056  3.4M ef EFI (FAT-12/16/32) 
/dev/sdc2  *     9716 7974911 7965196  3.8G 17 Hidden HPFS/NTFS 
**erlangen:~ #** lsblk -f /dev/sdc 
NAME   FSTYPE  FSVER            LABEL                            UUID                                 FSAVAIL FSUSE% MOUNTPOINTS 
sdc    iso9660 Joliet Extension openSUSE-Leap-15.4-DVD-x86_64243 2022-05-28-00-52-28-55                               
├─sdc1 vfat    FAT16            openSUSE-Leap-15.4-DVD-x86_64243 8287-3151                                            
└─sdc2 iso9660 Joliet Extension openSUSE-Leap-15.4-DVD-x86_64243 2022-05-28-00-52-21-74                     0   100% /media/openSUSE-Leap-15.4-DVD-x86_64243 
**erlangen:~ #**
12

Please do not assume that many people will find your contribution in such an old thread about such an old and no longer supported openSUSE version. Better start a new thread. Whn nyou think it is useful, you can include a link to this old thread to avoid having to explain again what is here.