Good afternoon,
This is an f24 system. I just (about 1pm US mountain time) completed my weekly "dnf upgrade", and I saw no hint of failure or trouble. But when I shut down the system, and then powered back up, the boot failed. The grub menu looked ok. The blue-and-white bar at the bottom of the boot screen did go most of the way normally. But it never got to the log in screen. There was some text being displayed, but I have no way of capturing it, and I don't remember what it said.
I'm no sys. admin. I have no idea what to do. Please help. (I'm using a windows 7 system for this e-mail.)
Thank-you in advance. Bill.
On 05/11/2017 01:21 PM, Bill Mattison wrote:
This is an f24 system. I just (about 1pm US mountain time) completed my weekly "dnf upgrade", and I saw no hint of failure or trouble. But when I shut down the system, and then powered back up, the boot failed. The grub menu looked ok. The blue-and-white bar at the bottom of the boot screen did go most of the way normally. But it never got to the log in screen. There was some text being displayed, but I have no way of capturing it, and I don't remember what it said.
Try choosing one of the other kernel versions from the boot menu and see if that makes a difference. Try pressing the ESC key as soon as you see the logo filling up, that will give you some more information about the booting process. If you edit the boot entry, you could remove the "rhgb" and "quiet" options from the kernel command line. That will give you even more info about the boot process. Let us know what you find out from these steps.
If there is text on the screen that you don't understand, you could try taking a picture of it and posting it somewhere.
All three fedora versions in the grub menu appear to yield the same results. So whatever the "dnf upgrade" did, it affected all three. The windows-7 boot still works (this is a dual boot system, a desktop).
My camera died over a year ago, and I have no portable devices. Having been unemployed for over 2.5 years now, I cannot afford to replace the camera or buy any portable devices.
I copied the failure messages the old fashioned way (paper and pencil); I'm manually typing in what I got.... ----- Generating "/run/initramfs/rdsosreport.txt" Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
:/# ----- After I type "exit", I get this: ----- Failed to start default.target: Transaction is destructive. See system logs and 'systemctl status default.target' for details. ----- After that, I must manually reset the system.
I tried looking at "/run/initramfs/rdsosreport.txt". The file's lines are too long to fit across the screen, and the file is over 1000 lines long. I did not really understand what I was seeing. What should I be looking for?
I tried entering "journalctl". The output's lines are too long to fit across the screen, and the file is almost 900 lines long. I did not really understand what I was seeing. What should I be looking for?
I tried "systemctl status default.target". I got this 6-line output: ----- [a white square] initrd.target - Initrd Default Target Loaded: loaded (/usr/lib/systemd/system/initrd.target; static; vendor preset: Active: inactive (dead) Docs: man: systemd.special(7)
May 11 15:11:43 coyote systemd[1]: Stopped target Initrd Default Target. ----- Removing the rhgb and quiet options from the kernel command line resulted in lines of output flying by far too fast.
This system has worked well for about 4 years now. What was in the dnf upgrade today?
On 05/11/2017 01:34 PM, Samuel Sieb wrote:
On 05/11/2017 01:21 PM, Bill Mattison wrote:
This is an f24 system. I just (about 1pm US mountain time) completed my weekly "dnf upgrade", and I saw no hint of failure or trouble. But when I shut down the system, and then powered back up, the boot failed. The grub menu looked ok. The blue-and-white bar at the bottom of the boot screen did go most of the way normally. But it never got to the log in screen. There was some text being displayed, but I have no way of capturing it, and I don't remember what it said.
Try choosing one of the other kernel versions from the boot menu and see if that makes a difference. Try pressing the ESC key as soon as you see the logo filling up, that will give you some more information about the booting process. If you edit the boot entry, you could remove the "rhgb" and "quiet" options from the kernel command line. That will give you even more info about the boot process. Let us know what you find out from these steps.
If there is text on the screen that you don't understand, you could try taking a picture of it and posting it somewhere.
If you just did a big upgrade (particularly kernels and you use some akmod stuff), there may be a delay towards the end of the "blue line" finishing filling or the bubble filling up all the way. There may be even more of a delay between those completing and the actual login prompt.
If you have a disk activity LED, watch it...it may be on solid or flickering really fast. That's indicative of the akmods being built and loaded. I notice this a lot if I use a nVidia blobs for my video cards and/or having the system build rescue initrds.
If the LED is off and you still don't get a login prompt, try "CTRL-ALT-F1" (or "CTRL-ALT-<F3 through F6>"--try them all) to get a raw console and see if you can log in there. If you can, have a look at the "/var/log/boot.log" file. You should get an indication as to what the issue is. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Memory is the second thing to go, but I can't remember the first! - ----------------------------------------------------------------------
On Thu, 11 May 2017 15:36:07 -0700 Rick Stevens ricks@alldigital.com wrote:
On 05/11/2017 01:34 PM, Samuel Sieb wrote:
On 05/11/2017 01:21 PM, Bill Mattison wrote:
This is an f24 system. I just (about 1pm US mountain time) completed my weekly "dnf upgrade", and I saw no hint of failure or trouble. But when I shut down the system, and then powered back up, the boot failed. The grub menu looked ok. The blue-and-white bar at the bottom of the boot screen did go most of the way normally. But it never got to the log in screen. There was some text being displayed, but I have no way of capturing it, and I don't remember what it said.
Try choosing one of the other kernel versions from the boot menu and see if that makes a difference. Try pressing the ESC key as soon as you see the logo filling up, that will give you some more information about the booting process. If you edit the boot entry, you could remove the "rhgb" and "quiet" options from the kernel command line. That will give you even more info about the boot process. Let us know what you find out from these steps.
If there is text on the screen that you don't understand, you could try taking a picture of it and posting it somewhere.
If you just did a big upgrade (particularly kernels and you use some akmod stuff), there may be a delay towards the end of the "blue line" finishing filling or the bubble filling up all the way. There may be even more of a delay between those completing and the actual login prompt.
If you have a disk activity LED, watch it...it may be on solid or flickering really fast. That's indicative of the akmods being built and loaded. I notice this a lot if I use a nVidia blobs for my video cards and/or having the system build rescue initrds.
If the LED is off and you still don't get a login prompt, try "CTRL-ALT-F1" (or "CTRL-ALT-<F3 through F6>"--try them all) to get a raw console and see if you can log in there. If you can, have a look at the "/var/log/boot.log" file. You should get an indication as to what the issue is.
If using "Ctrl-Alt-F[3-6] doesn't get you a text console, you could try appending a 3 to the kernel boot line to boot directly to multiuser (text console) instead of the gui.
It is surprising that an update would cause this problem in F24, since it is in maintenance mode, and should be receiving only security updates. If you can get to a console, either by Rick's method or mine, you could also look at /var/cache/dnf.rpm.log* to see which updates occurred. Also look at journalctl -b, to see the boot messages from the unsuccessful boots (probably the same as /var/log/boot.log).
When you get the prompt at the failed boot, you are in a dracut shell. I think if you type ls /usr/bin/ you can see the commands available to you in that shell. You might be able to examine the files from that shell. It's been a long time since I experienced that, so I can't remember the commands. If less is there, you can look at files with that. I think vi is there, but unless you are used to modal editors, it is confusing to use.
On 05/11/2017 04:29 PM, stan wrote:
It is surprising that an update would cause this problem in F24, since it is in maintenance mode, and should be receiving only security updates. If you can get to a console, either by Rick's method or mine, you could also look at /var/cache/dnf.rpm.log* to see which updates occurred. Also look at journalctl -b, to see the boot messages from the unsuccessful boots (probably the same as /var/log/boot.log).
If I'm not mistaken, F24 has passed its End of Life, and receives no official updates, even for security, although third parties such as Adobe may ignore this. It might be possible to back out by using this command as root:
dnf history undo last
After this is finished, reboot and see if it works.
On Thu, 2017-05-11 at 16:50 -0700, Joe Zeff wrote:
On 05/11/2017 04:29 PM, stan wrote:
It is surprising that an update would cause this problem in F24, since it is in maintenance mode, and should be receiving only security updates. If you can get to a console, either by Rick's method or mine, you could also look at /var/cache/dnf.rpm.log* to see which updates occurred. Also look at journalctl -b, to see the boot messages from the unsuccessful boots (probably the same as /var/log/boot.log).
If I'm not mistaken, F24 has passed its End of Life, and receives no official updates, even for security, although third parties such as Adobe may ignore this.
Not so. Unless I'm living in a time warp, F24 and F25 are the currently maintained versions. F23 is EOLed and F26 is in development (not to mention Rawhide, which will eventually be F27).
poc
On 05/11/2017 04:29 PM, stan wrote:
I think vi is there, but unless you are used to modal editors, it is confusing to use.
You may find it easier to use nano if you aren't comfortable with vi. One if the nice things about it is that the most important commands are listed at the bottom of the page, including the one to get help, ^G. The only thing you have to remember is that nano uses the old convention, going back at least to CP/M, that prefixing a character with a caret, as I did above, means what many people would type as CTRL+G.
On 05/11/2017 03:36 PM, Rick Stevens wrote:
If you have a disk activity LED, watch it...it may be on solid or flickering really fast. That's indicative of the akmods being built and loaded. I notice this a lot if I use a nVidia blobs for my video cards and/or having the system build rescue initrds.
If the OP is using either akmod-nvidia or the binary blob, he'll get the blue/white progress bar, not the bubble, and I presume he is, as he's the one that mentioned the "blue line."
If the LED is off and you still don't get a login prompt, try "CTRL-ALT-F1" (or "CTRL-ALT-<F3 through F6>"--try them all) to get a raw console and see if you can log in there. If you can, have a look at the "/var/log/boot.log" file. You should get an indication as to what the issue is.
You can always log into two of these consoles, once as root and once as yourself, or if you do everything with sudo, once for admin work, and once for any stuff that doesn't need root/sudo. This lets you run top in one of them, so that you can see what's working and what's using the most resources, while studying the logs in the other CLI.
Good evening,
Based on what y'all said, I'd say I'm in a "dracut shell". I cannot reach any login whatsoever, using any of the techniques y'all suggested.
The "/var/log/" directory is empty.
There is no "/var/cache/" directory.
The directory "/usr/bin/" does not have many things in it. It does have "less" and "vi" and "cp" and "mount" and "umount" and others, but no "more, no "man". Fortunately, "vi" (and "vim", "gvim", and "view") are the editors I'm most comfortable with. There is no "nano". I saw no browser or e-mail, but I did see "ping".
I did not see any "/home/" directory! (This has me seriously concerned!)
"sudo" and "dnf" are not available.
If you can give me good complete answers to a few questions, it will help me to help you to help me: 1. I do have USB ports on the front of my tower. How can I find out their device IDs? 2. How can I get this dracut shell to recognize and talk to a USB stick inserted into one of those USB ports? Since I don't have the "man" command, but I do have "mount" and "umount" commands, maybe I can use them to help me get information to you. 3. I know how to use "cp" to copy files around various directories, but I don't know how to use "cp" to copy files to a USB stick. With these, I hope that I can put the desired logs onto the USB stick, and then use the windows system to put log file lines-of-interest here in the fedora users forum.
Thank-you for your help. Bill.
Hi, Bill,
I am not sure what causes your problem, but it does sound like your system cannot identify the root system so it cannot boot. I happened to have similar problem as you do after dnf update a few weeks ago, although slightly differently. I did have to fsck my partition before my system booted successfully. I found one of the posts you may want to check out.
https://unix.stackexchange.com/questions/278385/boot-problem-in-linux
It is when dracut cannot identify root file system. Please let me know if you have this problem.
From what I've seen in the website you referenced, and what I posted here earlier today, it seems similar to what you experienced, but not identical. It seems fsck says something is wrong with one of the partitions. Take a look. Feel free to chime in along with the others.
Thank-you.
On Fri, 12 May 2017 02:42:56 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
Good evening,
Based on what y'all said, I'd say I'm in a "dracut shell". I cannot reach any login whatsoever, using any of the techniques y'all suggested.
Sure sounds like it.
The directory "/usr/bin/" does not have many things in it. It does have "less" and "vi" and "cp" and "mount" and "umount" and others, but no "more, no "man". Fortunately, "vi" (and "vim", "gvim", and "view") are the editors I'm most comfortable with. There is no "nano". I saw no browser or e-mail, but I did see "ping".
The system is limited at this point.
I did not see any "/home/" directory! (This has me seriously concerned!)
It's just not mounted yet (I think).
"sudo" and "dnf" are not available.
Too high level for this stage of boot.
If you can give me good complete answers to a few questions, it will help me to help you to help me: 1. I do have USB ports on the front of my tower. How can I find out their device IDs? 2. How can I get this dracut shell to recognize and talk to a USB stick inserted into one of those USB ports? Since I don't have the "man" command, but I do have "mount" and "umount" commands, maybe I can use them to help me get information to you. 3. I know how to use "cp" to copy files around various directories, but I don't know how to use "cp" to copy files to a USB stick. With these, I hope that I can put the desired logs onto the USB stick, and then use the windows system to put log file lines-of-interest here in the fedora users forum.
I can't really help with those questions. If you insert the USB stick into the port, the kernel should recognize it, so it will have a link in /dev. You can then mount that at a directory of your choosing. The stick will need a file system on it in order to cp data to it. If you are going to use windows to read it, you should probably use something like vfat. I would look at the stuff below before I went to this trouble, as it might be something simple and obvious, or you might get the boot working with the symlink technique.
Here is some online information about the dracut shell that might help you to get to a booted system, from the fedora wiki.
Identifying your problem area
Remove rhgb and quiet from the kernel command line Add rd.shell to the kernel command line. This will present a shell should dracut be unable to locate your root device Add rd.shell rd.debug log_buf_len=1M to the kernel command line so that dracut shell commands are printed as they are executed Inspect the system logs:
# less /run/initramfs/rdsosreport.txt # journalctl -a # dmesg # less /run/initramfs/init.log
Accessing the root volume from the dracut shell
From the dracut debug shell, you can manually perform the task of locating and preparing your root volume for boot. The required steps will depend on how your root volume is configured. Common scenarios include:
A block device (e.g. /dev/sda7) A LVM logical volume (e.g. /dev/VolGroup00/LogVol00) An encrypted device (e.g. /dev/mapper/luks-4d5972ea-901c-4584-bd75-1da802417d83) A network attached device (e.g. netroot=iscsi:@192.168.0.4::3260::iqn.2009-02.org.fedoraproject:for.all)
The exact method for locating and preparing will vary. However, to continue with a successful boot, the objective is to locate your root volume and create a symlink /dev/root which points to the file system. For example, the following example demonstrates accessing and booting a root volume that is an encrypted LVM Logical volume.
Inspect your partitions using parted
# parted /dev/sda -s p Model: ATA HTS541060G9AT00 (scsi) Disk /dev/sda: 60.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos
Number Start End Size Type File system Flags 1 32.3kB 10.8GB 107MB primary ext4 boot 2 10.8GB 55.6GB 44.7GB logical lvm
You recall that your root volume was a LVM logical volume. Scan and activate any logical volumes
# lvm vgscan # lvm vgchange -ay
You should see any logical volumes now using the command blkid:
# blkid /dev/sda1: UUID="3de247f3-5de4-4a44-afc5-1fe179750cf7" TYPE="ext4" /dev/sda2: UUID="Ek4dQw-cOtq-5MJu-OGRF-xz5k-O2l8-wdDj0I" TYPE="LVM2_member" /dev/mapper/linux-root: UUID="def0269e-424b-4752-acf3-1077bf96ad2c" TYPE="crypto_LUKS" /dev/mapper/linux-home: UUID="c69127c1-f153-4ea2-b58e-4cbfa9257c5e" TYPE="ext3" /dev/mapper/linux-swap: UUID="47b4d329-975c-4c08-b218-f9c9bf3635f1" TYPE="swap"
From the output above, you recall that your root volume exists on an encrypted block device. Following the guidance disk encryption guidance from the Fedora 25 Installation Guide, you unlock your encrypted root volume.
UUID=$(cryptsetup luksUUID /dev/mapper/linux-root) cryptsetup luksOpen /dev/mapper/linux-root luks-$UUID Enter passphrase for /dev/mapper/linux-root: Key slot 0 unlocked.
Next, make a symbolic link to the unlocked root volume
ln -s /dev/mapper/luks-$UUID /dev/root
With the root volume available, you may continue booting the system by exiting the dracut shell
exit
Good afternoon,
This is an f24 system. I just (about 1pm US mountain time) completed my weekly "dnf upgrade", and I saw no hint of failure or trouble. But when I shut down the system, and then powered back up, the boot failed. The grub menu looked ok. The blue-and-white bar at the bottom of the boot screen did go most of the way normally. But it never got to the log in screen. There was some text being displayed, but I have no way of capturing it, and I don't remember what it said.
I'm no sys. admin. I have no idea what to do. Please help. (I'm using a windows 7 system for this e-mail.)
Hello, check your BIOS settings, maybe your need ON or OFF acpi mode in SATA options.
Конфиденциально: Информация, содержащаяся в этом документе и приложениях к нему, может быть использована только получателем. Отправитель не несет юридической ответственности за содержание данного сообщения. Если это письмо попало к Вам случайно, пожалуйста, срочно удалите данный документ. Не посвящайте в содержание этого документа кого либо еще и не делайте копий. Совершение данных действий является противозаконным.
Good afternoon.
I've wrestled with this for some 3(?) days now. I'm still stuck.
I did find a "rescue" mode, and I was able to get in to it. But it didn't really help. Two IT grad students came and tried to help, but couldn't.
In the rescue mode, I tried to use "fdisk" to get the device ID for the USB stick. (The stick has files on it from both my Fedora system and my windows-7 box.) No hint of a device ID for the stick. The "lsusb" command gives me "Bus 001 Device 003: ID 05dc:a786 Lexar Media, Inc. JumpDrive Retrax". Still nothing that I can use for the first parameter of the "mount" command, right? From within the dracut shell or rescue mode, how can I get the correct device ID to use as the first parameter of the "mount" command"?
In the rescue mode, I could not find "/run/initramfs/rdsosreport.txt". I did find the long (>1000 lines) log from the last "rpm upgrade". It showed no problems.
I installed Fedora on this dual-boot workstation about 4 years ago. It took a few days, mostly wrestling with the first few steps. I still don't know what I finally did different so that it worked. I do not recall what kind of file system this Fedora system has. I am a home user, not a sys. admin. How can I find out from within the dracut shell or the rescue mode? This seems to be essential to following ShenEn's or Stan's advice.
Thank-you in advance. Bill.
On 05/15/2017 02:44 PM, William Mattison wrote:
I installed Fedora on this dual-boot workstation about 4 years ago. It took a few days, mostly wrestling with the first few steps. I still don't know what I finally did different so that it worked. I do not recall what kind of file system this Fedora system has. I am a home user, not a sys. admin. How can I find out from within the dracut shell or the rescue mode? This seems to be essential to following ShenEn's or Stan's advice.
If I were in your situation, I'd boot from a LiveUSB and use GParted to examine the partitions, find out how each one of them is formatted, and use what you learned to do the repairs. (It might even be possible to fix things that way, but I'd not count on it.)
I don't have a LiveUSB, and I get the impression it would take hours to make one. This incident teaches me that once I get the system back on its feet, and I've upgraded to f25, I'll want to make one. About how long should it take?
Allegedly, on or about 17 May 2017, William Mattison sent:
I don't have a LiveUSB, and I get the impression it would take hours to make one.
That all depends...
If you kept an install ISO file somewhere (it doesn't have to be the most recent), you can probably use that to make a live USB from. Otherwise you'd have to download one on some computer, any computer. Depending on what you need to do, there may be smaller ISOs that can have enough tools to do what you need to do.
Writing one of these files to a USB flashdrive can take several minutes. I've had success using the "dd" tool to write the ISO file onto the flashdrive, but there are tools for doing this for you. Some ISOs can't simply be dumped onto the flashdrive, as-is, because they need a different bootblock so the computer will boot from them.
On Mon, 15 May 2017 21:44:53 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
I've wrestled with this for some 3(?) days now. I'm still stuck.
Trials and tribulations are good for the soul. ;-) Except when they happen to me. :-D
I did find a "rescue" mode, and I was able to get in to it. But it didn't really help. Two IT grad students came and tried to help, but couldn't.
I keep more that one active version of Fedora around, so don't really use rescue mode. When I have a problem, I just boot another version of Fedora to do any maintenance required. Because of that, I don't really have any familiarity with rescue mode, but I think that if you are in rescue mode, you have to mount the original root system my using mount /dev/sda? /mnt/Sysimage where /dev/sda? is the root device of the system you are trying to rescue. You then have access to that file system. It might not be Sysimage, so you could do an ls /mnt to find what it actually is, or create a directory under mnt, and mount there.
In the rescue mode, I tried to use "fdisk" to get the device ID for the USB stick. (The stick has files on it from both my Fedora system and my windows-7 box.) No hint of a device ID for the stick. The "lsusb" command gives me "Bus 001 Device 003: ID 05dc:a786 Lexar Media, Inc. JumpDrive Retrax". Still nothing that I can use for the first parameter of the "mount" command, right? From within the dracut shell or rescue mode, how can I get the correct device ID to use as the first parameter of the "mount" command"?
If the kernel recognizes the device, then lsblk -f should show the file system type in the output. From the man page for lsblk, """ Note that lsblk might be executed in time when udev does not have all information about recently added or modified devices yet. In this case it is recommended to use udevadm settle before lsblk to synchronize with udev. """ A recently mounted usb device might meet those criteria, and be missed unless you run udevadm settle.
In the rescue mode, I could not find "/run/initramfs/rdsosreport.txt". I did find the long (>1000 lines) log from the last "rpm upgrade". It showed no problems.
I think that is only available from the dracut shell. It's my understanding that rescue mode != dracut shell.
I installed Fedora on this dual-boot workstation about 4 years ago. It took a few days, mostly wrestling with the first few steps. I still don't know what I finally did different so that it worked. I do not recall what kind of file system this Fedora system has. I am a home user, not a sys. admin. How can I find out from within the dracut shell or the rescue mode? This seems to be essential to following ShenEn's or Stan's advice.
I think the lsblk command above will do that.
I have three active versions of f24 - the 3 most recent weekly patches. All three fail the same way and drop me into the dracut mode. I didn't know I had a rescue mode until some long-time IT friend suggested it to me last Friday. It wasn't obvious in the grub menu. It actually proved helpful yesterday and today for getting log files out to where I can show them to people trying to help me. The point of accessing /home is to get those log files out to where I can really use them, to where people trying to help me (like you) can fill in the blanks in the commands needed to actually fix the system. I'll also need them logs if, once the system is fixed, a bugzilla should be submitted.
The rdsosreport.txt file does seem to be available only available in the dracut shell; it seems to go away once the dracut shell is exited. I agree: the dracut shell is something different from the rescue mode.
Another PhD student in IT is coming this evening to work with me on this. We'll look at the commands lsblk and "udevadm settle" you've suggested. I hope to post results tomorrow.
Finally, I hope, a few useful clues. Rescue mode gave me enough information to make a lucky guess as to how to mount "/home" from within the dracut shell. With that, I could try the boot again (which of course failed and dropped me into the dracut shell), and then mount "/home", and then copy logs to a good place within "/home". I further did a "cat -n [file].txt > [file]_catn.txt" on each log file to make navigation and discussion easier. I then booted into the windows box, and used some tool that lets me look at some of the Fedora directories, including "/home". Using that, I got the files into a windows folder. I have the following files: * "dmesg" output; * dnf.log; * dnf.rpm.log; * "fdisk -l" output (from rescue mode); * "journalctl" output; * "journalctl -x" output; * "mount" output; and * rdsosreport.txt. I also, from grub, copied (the old fashioned way - paper and pencil) the script that is running when I try to boot. I then typed that script into a text file within rescue mode. So if someone wants to see any of these, please sent me the e-mail address, and I'll send the full file. They're too long to put here.
From the rdsosreport.txt, I've extracted 2 sets of lines that look to me to be likely causes. Here is the first (with line numbers): ----- 862 [ 1.218683] coyote kernel: ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300) 863 [ 1.218927] coyote kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359) 864 [ 1.219196] coyote kernel: ACPI Error: Method parse/execution failed [_SB.PCI0.SAT0.SPT1._GTF] (Node ffff92ef8e0db488), AE_NOT_FOUND (20160930/psparse-543) 865 [ 1.219856] coyote kernel: ata2.00: ATA-8: ST2000DM001-1CH164, CC24, max UDMA/133 866 [ 1.220017] coyote kernel: ata2.00: 3907029168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA 867 [ 1.220812] coyote kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359) 868 [ 1.221100] coyote kernel: ACPI Error: Method parse/execution failed [_SB.PCI0.SAT0.SPT1._GTF] (Node ffff92ef8e0db488), AE_NOT_FOUND (20160930/psparse-543) 869 [ 1.221620] coyote kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359) 870 [ 1.221909] coyote kernel: ACPI Error: Method parse/execution failed [_SB.PCI0.SAT0.SPT5._GTF] (Node ffff92ef8e0dbac8), AE_NOT_FOUND (20160930/psparse-543) 871 [ 1.222200] coyote kernel: ata6.00: ATAPI: HL-DT-ST BD-RE BH14NS40, 1.00, max UDMA/100 872 [ 1.222374] coyote kernel: ata2.00: configured for UDMA/133 873 [ 1.222582] coyote kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359) 874 [ 1.222908] coyote kernel: ACPI Error: Method parse/execution failed [_SB.PCI0.SAT0.SPT3._GTF] (Node ffff92ef8e0db348), AE_NOT_FOUND (20160930/psparse-543) 875 [ 1.222919] coyote kernel: scsi 1:0:0:0: Direct-Access ATA ST2000DM001-1CH1 CC24 PQ: 0 ANSI: 5 876 [ 1.223466] coyote kernel: ata4.00: ATAPI: PIONEER BD-RW BDR-208M, 1.10, max UDMA/100 877 [ 1.226360] coyote kernel: ata7: SATA link down (SStatus 0 SControl 300) 878 [ 1.226407] coyote kernel: ata9: SATA link down (SStatus 0 SControl 300) 879 [ 1.226501] coyote kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359) 880 [ 1.226507] coyote kernel: ACPI Error: Method parse/execution failed [_SB.PCI0.SAT0.SPT5._GTF] (Node ffff92ef8e0dbac8), AE_NOT_FOUND (20160930/psparse-543) 881 [ 1.226519] coyote kernel: ata6.00: configured for UDMA/100 882 [ 1.227197] coyote kernel: ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160930/psargs-359) 883 [ 1.227204] coyote kernel: ACPI Error: Method parse/execution failed [_SB.PCI0.SAT0.SPT3._GTF] (Node ffff92ef8e0db348), AE_NOT_FOUND (20160930/psparse-543) 884 [ 1.227217] coyote kernel: ata4.00: configured for UDMA/100 ----- and here is the bottom of the file (with line numbers): ----- 1530 [ 2.651202] coyote systemd[1]: Reached target Basic System. 1531 [ 2.933094] coyote kernel: clocksource: Switched to clocksource tsc 1532 [ 2.968658] coyote kernel: random: crng init done 1533 [ 4.022605] coyote systemd-fsck[428]: /dev/sda6: Superblock last mount time is in the future. 1534 [ 4.022745] coyote systemd-fsck[428]: (by less than a day, probably due to the hardware clock being incorrectly set) 1535 [ 4.022878] coyote systemd-fsck[428]: /dev/sda6 contains a file system with errors, check forced. 1536 [ 6.881352] coyote systemd-fsck[428]: /dev/sda6: Deleted inode 1704549 has zero dtime. FIXED. 1537 [ 13.814145] coyote systemd-fsck[428]: /dev/sda6: Duplicate or bad block in use! 1538 [ 13.855820] coyote systemd-fsck[428]: /dev/sda6: Multiply-claimed block(s) in inode 674527: 2703102 2703103 1539 [ 13.855918] coyote systemd-fsck[428]: /dev/sda6: Multiply-claimed block(s) in inode 674586: 2703102 2703103 1540 [ 15.075286] coyote systemd-fsck[428]: /dev/sda6: (There are 2 inodes containing multiply-claimed blocks.) 1541 [ 15.100918] coyote systemd-fsck[428]: /dev/sda6: File /usr/share/javadoc/java-1.8.0-openjdk-1.8.0.131-1.b12.fc24/api/java/util/class-use/IllegalFormatCodePointException.html (inode #674527, mod time Sat Apr 22 17:29:37 2017) 1542 [ 15.101045] coyote systemd-fsck[428]: has 2 multiply-claimed block(s), shared with 1 file(s): 1543 [ 15.101262] coyote systemd-fsck[428]: /dev/sda6: /usr/share/javadoc/java-1.8.0-openjdk-1.8.0.131-1.b12.fc24/api/java/util/class-use/SortedMap.html (inode #674586, mod time Sat Apr 22 17:29:19 2017) 1544 [ 15.101388] coyote systemd-fsck[428]: /dev/sda6: 1545 [ 15.101510] coyote systemd-fsck[428]: /dev/sda6: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. 1546 [ 15.101693] coyote systemd-fsck[428]: (i.e., without -a or -p options) 1547 [ 15.177238] coyote systemd-fsck[428]: fsck failed with error code 4. 1548 [ 15.177386] coyote systemd-fsck[428]: Running request emergency.target/start/replace 1549 [ 15.179277] coyote systemd[1]: systemd-fsck-root.service: Main process exited, code=exited, status=1/FAILURE 1550 [ 15.179508] coyote systemd[1]: Failed to start File System Check on /dev/disk/by-uuid/45e553d2-fa0c-4eae-95f6-7bf9086ab74c. 1551 [ 15.179725] coyote systemd[1]: Dependency failed for /sysroot. 1552 [ 15.179937] coyote systemd[1]: Dependency failed for Initrd Root File System. 1553 [ 15.180040] coyote audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-fsck-root comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' 1554 [ 15.180292] coyote systemd[1]: Dependency failed for Reload Configuration from the Real Root. 1555 [ 15.180482] coyote systemd[1]: initrd-parse-etc.service: Job initrd-parse-etc.service/start failed with result 'dependency'. 1556 [ 15.180636] coyote systemd[1]: initrd-parse-etc.service: Triggering OnFailure= dependencies. 1557 [ 15.180776] coyote systemd[1]: initrd-root-fs.target: Job initrd-root-fs.target/start failed with result 'dependency'. 1558 [ 15.180915] coyote systemd[1]: initrd-root-fs.target: Triggering OnFailure= dependencies. 1559 [ 15.181066] coyote systemd[1]: sysroot.mount: Job sysroot.mount/start failed with result 'dependency'. 1560 [ 15.264980] coyote kernel: kauditd_printk_skb: 2 callbacks suppressed 1561 [ 15.264982] coyote kernel: audit: type=1130 audit(1495014556.700:13): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-fsck-root comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' 1562 [ 15.181237] coyote systemd[1]: systemd-fsck-root.service: Unit entered failed state. 1563 [ 15.181367] coyote systemd[1]: systemd-fsck-root.service: Failed with result 'exit-code'. 1564 [ 15.181481] coyote systemd[1]: Stopped dracut pre-pivot and cleanup hook. 1565 [ 15.181596] coyote systemd[1]: Stopped target Initrd Default Target. 1566 [ 15.181704] coyote systemd[1]: Reached target Initrd File Systems. 1567 [ 15.181815] coyote systemd[1]: Stopped dracut mount hook. 1568 [ 15.181927] coyote systemd[1]: Stopped target Basic System. 1569 [ 15.182049] coyote systemd[1]: Stopped target System Initialization. 1570 [ 15.182166] coyote systemd[1]: Starting Emergency Shell... 1571 [ 15.203226] coyote systemd[1]: Received SIGRTMIN+21 from PID 395 (plymouthd). 1572 [ 15.213983] coyote audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' 1573 [ 15.299101] coyote kernel: audit: type=1131 audit(1495014556.734:14): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' ----- If it helps, here is the "fdisk -l" output from within the rescue shell: ----- Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xfde8da65
Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT /dev/sda3 1859026944 1860050943 1024000 500M 83 Linux /dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended /dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap / Solaris /dev/sda6 1876439040 1981296639 104857600 50G 83 Linux /dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux ----- I will re-study what everyone has posted. My non-sys.admin. gut tells me to not try any real fixes without first getting confirmation here. Otherwise, I could easily make things worse.
Thank-you for your help so far. Bill.
On Wed, 17 May 2017 18:18:38 -0000 "William Mattison" mattison.computer@yahoo.com wrote:
Finally, I hope, a few useful clues. Rescue mode gave me enough information to make a lucky guess as to how to mount "/home" from within the dracut shell.
It isn't home you want to mount, it's /, the root filesystem. One of my earlier emails had instructions on how to create symlink to that partition, and then exit from dracut shell to reboot. Given the rest of your information, it seems you have a corrupted root filesystem on the hard drive, so it probably wouldn't have worked.
[snip]
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xfde8da65
Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT /dev/sda3 1859026944 1860050943 1024000 500M 83 Linux /dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended /dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap / Solaris /dev/sda6 1876439040 1981296639 104857600 50G 83 Linux /dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux
I will re-study what everyone has posted. My non-sys.admin. gut tells me to not try any real fixes without first getting confirmation here. Otherwise, I could easily make things worse.
We could be wrong, but when it matters like this it is certainly better to have more sets of eyes look at things.
From rescue mode, you need to run e2fsck (I'm assuming that the filesystems are one of ext[2, 3, 4]. If that isn't what lsblk shows, then you will have to use the appropriate tool for the filesystem you have. I think you want to use the -c and -v options to do a non destructive check first to see if there is anything wrong. You could look at the -k option, and the -c -c option, the -b option, and when you are ready to fix the filesystem, the -p option and possibly -y option. e.g. e2fsck -c -v /dev/sda6 from the rescue boot to check for errors. e2fsck -p -y /dev/sda6 to automatically fix any errors on the device.
It's possible that the drive is bad, and this should tell you that.
The time problem suggests that the little pancake battery on the MB that maintains the clock might be out of juice. I think these are 2032 style for PCs. It would be a good idea to replace it.
It isn't home you want to mount, it's /, the root filesystem.
I wanted /home as a place to copy log files to so I could then access them from the windows box. I originally wanted to copy them to a USB stick, but I couldn't get that to work.
I didn't know workstations nowadays had batteries. When the system is back on its feet, I'll try to check that. It was bought in 2013.
Based on the "fdisk -l" output that I put into my post earlier today, am I correct to conclude that my system uses a block device?
What's going on with the ACPI errors? Are those relevant in this situation?
On 05/17/2017 04:01 PM, William Mattison wrote:
It isn't home you want to mount, it's /, the root filesystem.
I wanted /home as a place to copy log files to so I could then access them from the windows box. I originally wanted to copy them to a USB stick, but I couldn't get that to work.
I didn't know workstations nowadays had batteries. When the system is back on its feet, I'll try to check that. It was bought in 2013.
There's a coin battery that keeps your BIOS and real time clock alive. Yes, you have to replace those periodically--especially if the machine starts to act oddly (forgets BIOS configs, clock loses time, etc.). Pretty cheap, but Google on how to open up your machine (laptops can be real bears to open--especially Macbooks).
Based on the "fdisk -l" output that I put into my post earlier today, am I correct to conclude that my system uses a block device?
Yes, it's a block device. Virtually all mass storage devices (hard disks, CDs, DVDs, FLASH drives, etc.) are block devices. In practice, the only mass storage that aren't block devices you're likely to see would be tape drives and they're fairly scarce now.
You have two primary partitions (/dev/sda1 and /dev/sda2) that are NTFS formatted. Smells like sda1 is a 100MB Windows recovery disk, but it could be just a bootloader partition. Methinks sda2 is an 886GB Windows C:\ drive.
You have a third primary partition (/dev/sda3) of 500MB that has Linux on it (probably the /boot filesystem). Finally you have an extended partition (/dev/sda4) which is split up into 3 sub-partitions, /dev/sda5, /dev/sda6 and /dev/sda7. That's just the way a DOS partition table works (up to three primary and one extended partition or up to four primary partitions).
The first of those sub partitions (/dev/sda5) is 7.8GB and is your swap partition. The second (/dev/sda6) is 50GB and is probably / (the root filesystem) and the last (/dev/sda7) is 918GB and is probably the /home filesystem. Just guesses, mind you.
Based on those guesses, if you're trying to mount the root filesystem of the drive to do some doctoring under a rescue boot, you'd want to mount /dev/sda6 at the /mnt/sysimage location:
mount /dev/sda6 /mnt/sysimage
Then do your doctoring on the stuff in /mnt/sysimage.
What's going on with the ACPI errors? Are those relevant in this situation?
Didn't see those in your post, sorry. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - 500: Internal Fortune Cookie Error - ----------------------------------------------------------------------
On 05/17/2017 05:11 PM, Rick Stevens wrote:
Based on those guesses, if you're trying to mount the root filesystem of the drive to do some doctoring under a rescue boot, you'd want to mount /dev/sda6 at the /mnt/sysimage location:
mount /dev/sda6 /mnt/sysimage
First, however, you need to create the mountpoint:
mkdir /mnt/sysimage
as it's not there by default.
Good afternoon,
Yesterday evening, a third IT grad student (PhD candidate specializing in cloud computing) came to help with this problem. After I showed him the log file and the discussion in this list, we booted, and of course it failed and dropped us into the dracut shell. He examined the rdsosreport.txt file. He ran "fdisk", but he typed too fast for me to see the whole command line. He responded 'y' to a few things, but it was too fast for me to see what. He then exited the dracut shell (I did not see him enter any "mount" commands.), and hit the hardware reset button. The system booted up successfully.
Later in the night, I shut the system down for the night. This morning it booted up fine. Early this afternoon, I did the weekly "dnf upgrade". Since the kernel was among the things patched, I shut the system down, and then booted it back up again. It booted successfully. I'm now willing to say the core problem is solved.
There are related questions that remain unanswered; I'll open new separate topics on them in the next few days. I see 10 list members (plus 4 off-list helpers) participated in this topic. I knew when the problem surfaced that this would be difficult. It turned out much more difficult, tedious, and time-consuming than I anticipated. But y'all got me through. Thank-you very much.
Bill.
On 05/11/2017 02:21 PM, Bill Mattison wrote:
Good afternoon,
This is an f24 system. I just (about 1pm US mountain time) completed my weekly "dnf upgrade", and I saw no hint of failure or trouble. But when I shut down the system, and then powered back up, the boot failed. The grub menu looked ok. The blue-and-white bar at the bottom of the boot screen did go most of the way normally. But it never got to the log in screen. There was some text being displayed, but I have no way of capturing it, and I don't remember what it said.
I'm no sys. admin. I have no idea what to do. Please help. (I'm using a windows 7 system for this e-mail.)
Thank-you in advance. Bill.
On 05/18/2017 02:40 PM, William wrote:
Good afternoon,
Yesterday evening, a third IT grad student (PhD candidate specializing in cloud computing) came to help with this problem. After I showed him the log file and the discussion in this list, we booted, and of course it failed and dropped us into the dracut shell. He examined the rdsosreport.txt file. He ran "fdisk", but he typed too fast for me to see the whole command line. He responded 'y' to a few things, but it was too fast for me to see what. He then exited the dracut shell (I did not see him enter any "mount" commands.), and hit the hardware reset button. The system booted up successfully.
Are you sure he ran "fdisk" and not "fsck"? fdisk wouldn't ask for "y" confirmations too often, whereas fsck ("file system check") that would prompt for "y" when it was trying to fix file system errors. You might ask your friend just what he did. This isn't a black art and since it's your machine, you should have some idea as to what he did.
Later in the night, I shut the system down for the night. This morning it booted up fine. Early this afternoon, I did the weekly "dnf upgrade". Since the kernel was among the things patched, I shut the system down, and then booted it back up again. It booted successfully. I'm now willing to say the core problem is solved> There are related questions that remain unanswered; I'll open new separate topics on them in the next few days. I see 10 list members (plus 4 off-list helpers) participated in this topic. I knew when the problem surfaced that this would be difficult. It turned out much more difficult, tedious, and time-consuming than I anticipated. But y'all got me through. Thank-you very much.
Just really glad you got it sorted out.
On 05/11/2017 02:21 PM, Bill Mattison wrote:
Good afternoon,
This is an f24 system. I just (about 1pm US mountain time) completed my weekly "dnf upgrade", and I saw no hint of failure or trouble. But when I shut down the system, and then powered back up, the boot failed. The grub menu looked ok. The blue-and-white bar at the bottom of the boot screen did go most of the way normally. But it never got to the log in screen. There was some text being displayed, but I have no way of capturing it, and I don't remember what it said.
I'm no sys. admin. I have no idea what to do. Please help. (I'm using a windows 7 system for this e-mail.)
Thank-you in advance. Bill.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
Well, as you yourself said in an earlier post on this topic, " Memory is the second thing to go, but I can't remember the first!"! You are almost certainly correct - it was "fsck", not "fdisk". I just typed the wrong thing into my posting. Another "senior moment".
This isn't a black art
To me, a home user, it sure seems like at least magic, maybe black magic! (just kidding, partially!) It amazes me what some of you, and those who engineer operating systems, boot scripts, etc., can do. I dread to think how many college (and graduate?) courses and how many years of experience it takes to do what you do. I guess that why they pay you the big bucks!
I should see my friend sometime next week or two. He wants me to help him practice his cloud computing paper before he presents it at some conference. (He's an international student.) I'll ask him about the fsck options then.
Bill.
Allegedly, on or about 18 May 2017, William sent:
Yesterday evening, a third IT grad student (PhD candidate specializing in cloud computing) came to help with this problem. After I showed him the log file and the discussion in this list, we booted, and of course it failed and dropped us into the dracut shell. He examined the rdsosreport.txt file. He ran "fdisk", but he typed too fast for me to see the whole command line. He responded 'y' to a few things, but it was too fast for me to see what...
Well, my advice would be: To see him again, mention that things are going well now, ask him what he had to do, take notes.
You're right.
I should see my friend sometime next week or two. He wants me to help him practice his cloud computing paper before he presents it at some conference. (He's an international student.) I'll ask him about the fsck options then.
Bill.
My friend was here earlier tonight. The command was "fsck /dev/sda6" (no options). He also said he's seen this kind of thing before.
Bill.