26.06.2020 08:42, Per Jessen пишет:

cagsm wrote:

...

On Fri, Jun 26, 2020 at 12:40 AM cagsm wrote:

...

simple 15.1 zypper dup-ed to 15.2. reboot. grub_file_filters not found error message. going nowhere. ...

I guess parts of this process were not sufficiently tested - good that you were able to fix it so quickly. Would probably be worth opening a bugreport for.

No, this is local configuration issue, there is nothing that can really be done (actually there was at least one bug report about it). Boot device used by BIOS does not match boot device configured in openSUSE. During grub package update it replaces core.img on boot device as configured in openSUSE, but actual boot device still holds old copy that no more matches content of /boot/grub. There is no (generic) way to determine real boot device set in BIOS from within OS. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 26/06/2020 à 07:47, Andrei Borzenkov a écrit :

Boot device used by BIOS does not match boot device configured in openSUSE.

can you give an example, please, I don't understand thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 26/06/2020 à 09:38, Per Jessen a écrit :

jdd@dodin.org wrote:

...

Le 26/06/2020 à 07:47, Andrei Borzenkov a écrit :

...

Boot device used by BIOS does not match boot device configured in openSUSE.

can you give an example, please, I don't understand

The way I read it - a machine boots from sda (BIOS order), but the installation has sdb configured as boot drive.

I only remember this when yast or lilo are instructed to switch disks (not used this since ages). using uuid should prevent this? I'm trying to spot good practice to prevent such dup problem thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

27.06.2020 06:40, David C. Rankin пишет:

On 06/26/2020 02:38 AM, Per Jessen wrote:

...

jdd@dodin.org wrote:

...

Le 26/06/2020 à 07:47, Andrei Borzenkov a écrit :

...

Boot device used by BIOS does not match boot device configured in openSUSE. can you give an example, please, I don't understand

The way I read it - a machine boots from sda (BIOS order), but the installation has sdb configured as boot drive.

I ran into that exact problem one (I have openSUSE on /dev/sdb) and the update/install overwrite the Win10 bootloader on /dev/sda)

Which is entirety different issue from what was described in original post.

which was evidently os-prober gone nuts...

And new town legend was born ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* cagsm [06-26-20 10:06]:

On Fri, Jun 26, 2020 at 2:08 AM cagsm wrote:

...

...

https://forums.opensuse.org/showthread.php/538159-grub-not-booting-anymore-o... https://bugzilla.opensuse.org/show_bug.cgi?id=1156073 https://bugzilla.opensuse.org/show_bug.cgi?id=1156351

I am really trying to understand the situation here. What am I doing wrong or was some bootloader or grub2 package not properly tested for zypper dup usage? Why would previous kernel updates, grub2 updates etc on leap 15.1 and leap 15 and before work fine on this machine? what is the difference with leap 15.2 coming in via zypper dup?

So at present there is an /etc/default/grub_installdevice file, probably altered or fixed with its settings currently displaying: /dev/sda /dev/disk/by-uuid/1111111-uuid-of-sda1-here activate generic_mbr

This is the current content of this file after I chrooted into 15.2 net/iso image and booted up its rescue mode and ran yast2 bootloader screen from the installed 15.2 system.

is this a proper file? I guess so as it boots now.

Nothing inside bios settings of the machine/board was altered from 15.1 to 15.2 state.

Why would a zypper dup with its perlbootloader, grub2, kernel and other boot-affecting packages not simply apply and install the current packages/grub2 stuff into all the places that it exists/existed before on 15.1 level? I fail to understand that? why would a 15.2 suddenly become nonbooting as some people explain that the newer grub2 2.04 or something works differently and some part got missed during update of the grub2 package?

this is not something I can do anything about as end-user, or is it? can I?

I have other systems. what would be the minimal lines in grub_installdevice for not rendering other 15.1 to 15.2 systems nonbooting? this situation forced me to drive across states and fix machine hands on :(

I still do not really understand why this bug needs to happen in the first place? is this something the user deliberately or accidentally messes up maybe sometime in the past when initially installing a former opensuse release?

so anyway, it didnt become corrupted with past leap upgrades. it did become corrupted now, so again the question, can the grub2 and related packages not be tested and made sure they use all the same places and install themselves to all the same places again over and over again where the previous (then still running) system comes from? I fail to understand the explanation that somhow it can not be possibly detected how the system actually boots in contrast to how the grub settings of bootconfig are set? there is something missing here in the explanation.

there are too many of these problems that completely disable remote machines. I have experienced a lot of trouble in the past with open/suse, that is what I use. When i directly compare this to old and dated machines with windows, I dont have these essential and low level borkage and mess with such basic things as bringing up a machine into showtime state. windows has its own set of serious illnesses of course.

as I said, nothing in these old, but robust bios style machines have changed in the past years. not tinkering with stuff. simple systems. single disk, sda, with two or threee partitions, swap, root and home and thats it. and then, there comes june of 2020 and a new upgrade of opensuse breaks down everything.

one would think this is pretty decent and very simple setup. bios. machine. single disk, simple partitions, mbr, no uefi, no gpt no nothing.

still the pain though. serious pain. :( thanks for helping to sort these kind of things out for the future.

Remome all but one drive, the boot drive, and all your above problems will vanish. iiuc, the problem is your computer does not always assign the same order to the attached drives, sda, sdb, sdc, ... ??timind?? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Jun 26, 2020 at 5:53 PM Andrei Borzenkov wrote:

...

Why would a zypper dup with its perlbootloader, grub2, kernel and other boot-affecting packages not simply apply and install the current packages/grub2 stuff into all the places that it exists/existed before on 15.1 level? Show /etc/default/grub_installdevice as it was before on 15.1 level.

o.k.having the very same problem, on a second leap 15.1 to 15.2 zypper dup-ed machine. I took very careful steps of collecting information before. the 15.1 level grub_installdevices file is: /dev/disk/by-uuid/0000-11111-22222-333333 generic_mbr and thats all. it has again a swap, root and home partition, and another dmraid or mdraid or whatever it is called disks but that play no role here I guess. it again stalls during the initial reboot into 15.2 with the grub error message grub_file_filters not found error. and again I will need to repair this machine via rescue mode and chroot I guess. any more questions before I take these steps? i could also provide some pbllog or something from /var/log/ from that machine from yesterday, or from this machine today I guess I found that kind of file and it looked non suspicious to me with the log entries from yesterdays timestamp on that first machine. i simply can not understand how a grub2 and bootloader updates can mess up machines this badly. somethings very untested here. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Jun 26, 2020 at 7:16 PM jdd@dodin.org wrote:

Le 26/06/2020 à 18:49, cagsm a écrit :

...

the 15.1 level grub_installdevices file is: /dev/disk/by-uuid/0000-11111-22222-333333 generic_mbr here # cat /etc/default/grub_installdevice /dev/disk/by-uuid/80e0ec44-8c74-4487-b28b-2a285791faaa activate generic_mbr so only "activate" more than you (no idea what it does)

if I am not mistaken that "activate" line was being shown as set boot flag on the bootable partition within yast2 bootloader config on some machine. dunno why this machine does not have it. it booted very fine on 15.1. maybe a zypper dup to 15.2 and then the grub2 and related packages when not finding that activate line, remove such a previously set active flag bit from a partition again? wondering though how this machine booted so far. again this machine is very plain and simple and bios. i am still at the messed up state with this machine. i can fire up an usb rescue stick and also check the current mbr partition table with fdisk -l I guess and I probably will find the asterisk/star on that second /dev/sda2 partition as thats the / (root) partition and thats where it booted from so far. but again, this files contents was what I posted, before I even fired up the zypper dup command. so it is the unaltered state of that file. thats how leap 15.1 and 15.0 before worked so far for quite a number of years now if I am not mistaken. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 26/06/2020 19.22, cagsm wrote:

On Fri, Jun 26, 2020 at 7:16 PM jdd@dodin.org wrote:

...

Le 26/06/2020 à 18:49, cagsm a écrit :

...

the 15.1 level grub_installdevices file is: /dev/disk/by-uuid/0000-11111-22222-333333 generic_mbr here # cat /etc/default/grub_installdevice /dev/disk/by-uuid/80e0ec44-8c74-4487-b28b-2a285791faaa activate generic_mbr so only "activate" more than you (no idea what it does)

if I am not mistaken that "activate" line was being shown as set boot flag on the bootable partition within yast2 bootloader config on some machine.

dunno why this machine does not have it. it booted very fine on 15.1. maybe a zypper dup to 15.2 and then the grub2 and related packages when not finding that activate line, remove such a previously set active flag bit from a partition again?

Just give Andrei the information he asks for. He can figure this out. Please do not try to repair the machine yet. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Andrei Borzenkov composed on 2020-06-26 21:17 (UTC+0300):

Boot any live image, run https://github.com/arvidjaar/bootinfoscript...

# pinxi -INSxx System: Host: gx320 Kernel: 3.12.67-64-desktop x86_64 bits: 64 compiler: gcc v: 4.8.1 Desktop: KDE 3.5.10 tk: Qt 3.3.8c wm: kwin dm: xinit Distro: openSUSE 13.1 (Bottle) Network: Device-1: Broadcom BCM4401-B0 100Base-TX vendor: Dell driver: b44 v: 2.0 port: dcf0 bus ID: 02:09.0 chip ID: 14e4:170c Info: Processes: 188 Uptime: N/A Memory: 1.93 GiB used: 396.1 MiB (20.1%) Init: systemd v: 210 runlevel: 3 target: runlevel5.target Compilers: gcc: N/A Packages: rpm: 1271 Shell: Bash v: 4.2.53 running in: konsole pinxi: 3.1.03-64 # wget https://github.com/arvidjaar/bootinfoscript --2020-06-26 19:28:34-- https://github.com/arvidjaar/bootinfoscript Resolving github.com (github.com)... 140.82.114.4 Connecting to github.com (github.com)|140.82.114.4|:443... connected. OpenSSL: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version Unable to establish SSL connection. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. composed on 2020-06-27 02:22 (UTC+0200):

Felix Miata wrote: ...

...

# wget https://github.com/arvidjaar/bootinfoscript --2020-06-26 19:28:34-- https://github.com/arvidjaar/bootinfoscript Resolving github.com (github.com)... 140.82.114.4 Connecting to github.com (github.com)|140.82.114.4|:443... connected. OpenSSL: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version Unable to establish SSL connection.

It is your end side problem, works fine here (do not use 13.1).

Andrei wrote "any". 13.1 is my goto backup OS for repairing unbootables on systems old enough to ever have had 13.1 current.

But it is a web page,

I chose to follow Andrei's suggestion, attempting to use the latest version. When it didn't work, I went with what worked, but if Google points someone to his archived email, I'd expect the same failing result.

and you are attempting to downloading the html page, not the script (see it in FF). The direct download link is:

https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript

Same error with that URL, and similar if I try http://... instead. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Felix Miata wrote:

# wget https://github.com/arvidjaar/bootinfoscript --2020-06-26 19:28:34-- https://github.com/arvidjaar/bootinfoscript Resolving github.com (github.com)... 140.82.114.4 Connecting to github.com (github.com)|140.82.114.4|:443... connected. OpenSSL: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version Unable to establish SSL connection.

Your wget / your system is too old, does not support the encryption algorithm used by github. -- Per Jessen, Zürich (22.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27/06/2020 16.37, cagsm wrote:

On Fri, Jun 26, 2020 at 8:17 PM Andrei Borzenkov wrote:

...

...

/dev/disk/by-uuid/0000-11111-22222-333333 You intentionally make it more difficult? What exactly are you hiding here?

I am hiding my UUIDs, obviously.

Obviously, but that information is not security or privacy important, and impedes checking of files that should point to that partition.

as I fixed that second system already as well, is it still of any use to run that script on the now 15.2 normally booting system any more?

When you posted yesterday you were in the middle of the process with a second machine that failed. I asked you to halt and wait, and produce the information that was asked. I don't know if the information is of use now or not.

maybe I find some more systems that go bust. I will run that script on all the machines I come across to be able to later provide some information?

what more is there to do?

When you hit the problem in one, just stop, do not repair. Just produce the information with bootinfoscript and post here or upload to susepaste.org and paste the link here.

for example just to make sure to not be stuck with a remote machine not booting, can I do something after the zypper dup finished inside ssh, at the very end, for example then run yast2 bootloader module there and fixing it before even running into a mess?

I am not Andrei, I don't have his knowledge. The idea is to find out what is the problem, with the information requested, then you can locate it yourself and correct before running the zypper dup. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 27/06/2020 22.52, cagsm wrote:

On Sat, Jun 27, 2020 at 8:28 PM Carlos E. R. wrote:

...

When you hit the problem in one, just stop, do not repair. Just produce the information with bootinfoscript and post here or upload to susepaste.org and paste the link here.

as soon as I have another machine that features this buggy behavior and I can spare it to be offline, i can certainly provide the scripts output. i will run the script on all the machines i move over from 15.1 to 15.2 via zypper dup. so we will see, thanks for the support and the help with the script.

You could run the script before running the dup and save the result, which is the default. Then if it fails, post it. This way you do not have the hassle of downloading it to a rescue system. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Carlos E. R. composed on 2020-06-27 02:31 (UTC+0200):

Felix Miata wrote:

...

I have a bunch of 15.2 installations that zypper dup has worked flawlessly for, until now. This one was last upgaded 24 Feb. Today's upgrade when selecting the 15.2 installation to boot produced nothing but GRUB, from which CAD fails to reboot: http://fm.no-ip.com/Tmp/SUSE/Leap/bootinfoscriptresults-gx320-s152upgradeFeb...

That is a non standard system.

It *is* standard. /Standard/ is legacy/DOS/Windows/OS2 MBR code, from which Grub can be loaded when installed to a partition: https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u...

There is nothing "known" in the MBR of sda, but partition 2 (marked bootable) has "OS/2 Boot Manager". Sorry, I can not decode how that system is supposed to boot.

IBM BM is (among other things) a chainloader. It chainloads to Grub installed on the 15.2 partition, which dup'ing 15.2 broke. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov composed on 2020-06-27 07:24 (UTC+0300):

Felix Miata composed:

...

I have a bunch of 15.2 installations that zypper dup has worked flawlessly for, until now. This one was last upgaded 24 Feb. Today's upgrade when selecting the 15.2 installation to boot produced nothing but GRUB, from which CAD fails to reboot: http://fm.no-ip.com/Tmp/SUSE/Leap/bootinfoscriptresults-gx320-s152upgradeFeb...

Which of 37 partitions was updated?

sda24, the only one in that report that the script identified as 15.2. All my other 15.2s are on other PCs. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrei Borzenkov composed on 2020-06-27 10:04 (UTC+0300):

You seriously expected me to study your long file trying to guess your problem? You are mistaken, it does not work this way. If you are not willing to spend your time to explain your problem why do you expect me to waste my time trying to guess it?

What I thought I was doing was providing data in support of OP's contention that there is a bug in the update process involving bootloader setup. As soon as I submitted my response, I went ahead and corrected the failure using the grub shell.

Anyway, you are using legacy grub. What is the content of /etc/sysconfig/bootloader and /etc/grub.conf?

Oops, gross error! /etc/grub.conf points to sda11, an HPFS partition, instead of sda24, the 15.2 partition. Why this only just now manifested is its own puzzle. Grub.conf on my 15.1 installation on this host is similarly erroneous, pointing to sda13, another HPFS partition, instead of the correct sda23, on which /etc/sysconfig/bootloader does contain LOADER_TYPE="grub", same as in the host's 15.2. Both the 15.1 and the 15.2 were zypper dups of cloned partitions on which I obviously forgot all about editing /etc/grub.conf at the original dup time. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 27/06/2020 07.16, Felix Miata wrote:

Andrei Borzenkov composed on 2020-06-27 07:24 (UTC+0300):

...

Felix Miata composed:

...

...

I have a bunch of 15.2 installations that zypper dup has worked flawlessly for, until now. This one was last upgaded 24 Feb. Today's upgrade when selecting the 15.2 installation to boot produced nothing but GRUB, from which CAD fails to reboot: http://fm.no-ip.com/Tmp/SUSE/Leap/bootinfoscriptresults-gx320-s152upgradeFeb...

...

Which of 37 partitions was updated?

sda24, the only one in that report that the script identified as 15.2. All my other 15.2s are on other PCs.

That is something we can not guess from here. You know, but we don't. And obviously bootinfoscript does not understand your os/2 boot legacy system, nor do I. sda24: _________________________________________________________________________ File system: ext4 Boot sector type: Grub Legacy Boot sector info: Grub Legacy (v) is installed in the boot sector of sda24 and looks at sector 134721887 of the same hard drive for the stage2 file, but no stage2 files can be found at this location. Operating System: openSUSE Leap 15.2 Boot files: /boot/grub/menu.lst /etc/fstab Partition Boot Start Sector End Sector # of Sectors Id System /dev/sda24 125,917,533 137,387,879 11,470,347 83 Linux "blkid" output: ________________________________________________________________ /dev/sda24 1d0972d8-f12a-4865-9d27-dfccd56e83b9 ext4 sbyd24s152 ========================= "ls -l /dev/disk/by-id" output: ====================== lrwxrwxrwx 1 root root 11 Jun 26 19:14 ata-ST3160815AS_9RX44BYD-part24 -> ../../sda24 lrwxrwxrwx 1 root root 11 Jun 26 19:14 scsi-1ATA_ST3160815AS_9RX44BYD-part24 -> ../../sda24 lrwxrwxrwx 1 root root 11 Jun 26 19:14 scsi-SATA_ST3160815AS_9RX44BYD-part24 -> ../../sda24 ================================ Mount points: ================================= /dev/sda24 /disks/s152 ext4 (rw,noatime,data=ordered) ========================== sda24/boot/grub/menu.lst: =========================== -------------------------------------------------------------------------------- color cyan/blue white/blue default 0 fallback 1 timeout 33 gfxmenu (hd0,23)/boot/message title Memtest 4.20 root (hd0,2) kernel /memtest.420 title openSUSE 15.2 defkernel on sda24 root (hd0,23) kernel /boot/vmlinuz showopts root=LABEL=sbyd24s152 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 vga=791 video=1024x768@60 video=1440x900@60 3 initrd /boot/initrd title openSUSE 15.2 prvkernel on sda24 root (hd0,23) kernel /boot/vmlinuz-prv showopts root=LABEL=sbyd24s152 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 vga=791 video=1024x768@60 video=1440x900@60 3 initrd /boot/initrd-prv title openSUSE 15.2 prv2kernel on sda24 root (hd0,23) kernel /boot/vmlinuz-prv2 showopts root=LABEL=sbyd24s152 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 vga=791 video=1024x768@60 video=1440x900@60 3 initrd /boot/initrd-prv2 -------------------------------------------------------------------------------- =============================== sda24/etc/fstab: =============================== -------------------------------------------------------------------------------- /dev/sda3 /disks/C msdos users,gid=users,dmask=0000,fmask=0111 0 0 /dev/sda6 /disks/E msdos users,gid=users,dmask=0000,fmask=0111 0 0 LABEL=sbyd07boot /disks/boot ext2 noatime,noacl 1 2 LABEL=sbyd08swap swap swap defaults 0 0 LABEL=sbyd09s131 /disks/s131 ext3 noatime,acl 1 2 LABEL=sbyd14home /home ext3 noatime,acl 1 2 LABEL=sbyd15knoppix /disks/knoppix ext3 noatime,noauto,noacl 0 0 LABEL=sbyd16s423 /disks/s423 ext4 noatime 1 2 LABEL=sbyd17pub /pub ext3 noatime,noacl 1 2 LABEL=sbyd18srv /srv ext3 noatime,noacl 1 2 LABEL=sbyd19usrlcl /usr/local ext3 noatime,noacl 1 2 LABEL=sbyd20usrsrc /usr/src ext3 noatime,acl 1 2 LABEL=sbyd21stw /disks/stw ext4 nofail,noatime 0 0 LABEL=sbyd22s150 /disks/s150 ext4 nofail,noatime 0 0 LABEL=sbyd23s151 /disks/s151 ext4 nofail,noatime 0 0 LABEL=sbyd24s152 / ext4 noatime 1 1 LABEL=sbyd-s114 /disks/s114 ext3 noatime,acl 1 2 #/dev/sdb1 /disks/D msdos noauto,users,gid=users,dmask=0000,fmask=0111 0 0 /dev/sda10 /hpfs/F hpfs noexec,case=asis,umask=0,ro,noauto 0 0 /dev/sda11 /hpfs/G hpfs noexec,case=asis,umask=0,ro 0 0 /dev/sda12 /hpfs/H hpfs noexec,case=asis,umask=0,ro,noauto 0 0 /dev/sda13 /hpfs/I hpfs noexec,case=asis,umask=0,ro,noauto 0 0 #/dev/sdb5 /hpfs/J hpfs noexec,case=asis,umask=0,ro,noauto 0 0 00srv:/home /nfs/00srv/home nfs ro,noauto,nosuid,soft,rsize=8192,wsize=8192 0 0 ... vizio:/tmp /nfs/vizio/tmp nfs ro,noauto,nosuid,soft,rsize=8192,wsize=8192 0 0 //m7ncd/G /smbmnt/m7ncd/G cifs ro,credentials=/etc/samba/mazda.cred,sec=lanman,vers=1.0,servern=MAZDA,domain=IBMPEERS,port=139,dir_mode=0555,file_mode=0444,noauto 0 0 ... -------------------------------------------------------------------------------- =================== sda24: Location of files loaded by Grub: =================== GiB - GB File Fragment(s) 60.042158604 = 64.469776896 boot/grub/menu.lst 1 64.957668781 = 69.747765760 boot/grub/stage2 1 62.940596104 = 67.581950464 boot/vmlinuz 5 64.081137180 = 68.806597120 boot/vmlinuz-4.4.143-65-default 1 60.042158604 = 64.469776896 boot/vmlinuz-5.3.18-lp152.19-default 5 62.593581676 = 67.209346560 boot/vmlinuz-5.3.18-lp152.4-default 3 60.042158604 = 64.469776896 boot/vmlinuz-cur 5 60.042158604 = 64.469776896 boot/vmlinuz-prv 3 64.081137180 = 68.806597120 boot/vmlinuz-prv2 1 61.248075008 = 65.764619776 boot/initrd 5 65.203279972 = 70.011488768 boot/initrd-4.4.143-65-default 2 60.042158604 = 64.469776896 boot/initrd-5.3.18-lp152.19-default 5 64.130671024 = 68.859783680 boot/initrd-5.3.18-lp152.4-default 4 60.042158604 = 64.469776896 boot/initrd-cur 5 60.042158604 = 64.469776896 boot/initrd-prv 4 60.042158604 = 64.469776896 boot/initrd-prv2 2 /etc/sysconfig/bootloader and /etc/grub.conf are not in the listing. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)