View previous topic :: View next topic |
Author |
Message |
acidrums4 Tux's lil' helper
Joined: 05 Feb 2009 Posts: 147 Location: Al otro lado del monitor
|
Posted: Sat Feb 04, 2017 6:28 pm Post subject: /dev/sda moved to /dev/sdb, and slow boot |
|
|
Hello there,
I screwed my old HP Pavilion DV2000 (had 9 years with it) so I needed to get another computer. As I'm broke and can't afford a modern one, all I could get was an also old Compaq C700.
As both this Compaq C700 and HP DV200 have a quite similar hardware, I just moved the hard disk from one to other. But (I really don't know why) the hard disk is now at /dev/sdb, not on /dev/sda. So I had to edit the grub stuff and resume partition path on kernel config to be able to boot.
Everytime I let a USB plugged on the computer while booting, there's a kernel panic. And /dev/sda still exists, but nothing is on it. If I boot onto a live USB distro, it lists the hard drive on /dev/sda.
Can't tell if this is related to the hard drive path thing, but boot time is insanely slow. Here's the output of systemd-analyze blame:
Code: |
10.151s dev-sdb1.device
6.855s polkit.service
4.584s upower.service
3.968s systemd-journal-flush.service
2.789s systemd-fsck@dev-disk-by\x2duuid-d6621936\x2d0690\x2d439d\x2d8be3\x2d7e53143830b9.service
2.613s NetworkManager.service
1.967s dev-disk-by\x2duuid-43f68a5c\x2d464b\x2d41ef\x2d93eb\x2d1205ea8d8de6.swap
1.897s systemd-vconsole-setup.service
1.791s systemd-udevd.service
1.508s systemd-fsck-root.service
1.484s systemd-remount-fs.service
1.171s wpa_supplicant.service
1.170s systemd-journald.service
1.057s udisks2.service
1.024s home.mount
963ms systemd-logind.service
926ms systemd-readahead-collect.service
899ms systemd-readahead-replay.service
847ms sys-kernel-debug.mount
772ms kmod-static-nodes.service
708ms dev-mqueue.mount
704ms tmp.mount
495ms bluetooth.service
470ms dev-hugepages.mount
464ms systemd-sysctl.service
381ms user@1000.service
353ms avahi-daemon.service
344ms systemd-udev-trigger.service
239ms systemd-tmpfiles-setup.service
201ms systemd-timesyncd.service
152ms systemd-update-utmp.service
118ms systemd-tmpfiles-setup-dev.service
107ms systemd-tmpfiles-clean.service
106ms user@130.service
35ms systemd-hostnamed.service
24ms systemd-user-sessions.service
15ms systemd-random-seed.service
12ms systemd-readahead-done.service
10ms gentoo-local-baselayout1.service
8ms systemd-backlight@backlight:acpi_video0.service
4ms systemd-rfkill@rfkill0.service
|
Yep, 10 secs on 'dev-sdb1.service'. No /etc/conf.d/keymaps. What the hell? systemd-analyze critical-chain shows this:
Code: |
graphical.target @1min 34.049s
└─multi-user.target @1min 34.049s
└─getty.target @1min 34.049s
|
And my /etc/fstab contains this:
Code: |
UUID=819d503d-ed93-435c-baad-440d90c0df67 / ext4 noatime,defaults,errors=remount-ro 0 1
UUID=43f68a5c-464b-41ef-93eb-1205ea8d8de6 none swap sw 0 0
UUID=d6621936-0690-439d-8be3-7e53143830b9 /home ext4 defaults,noatime,x-systemd.automount 0 2
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
proc /proc proc nodev,nosuid,noexec 0 0
|
dmesg output can be found at http://pastebin.ca/3763634 - My very limited knowledge didn't let me see anything strange there.
I don't even know if it's for the same reason, but after booting KDE seems to crash and it goes back to SDDM login screen. After login, a popup message appears: "Could not start ksmserver. Check your installation". That didn't happen before.
Any idea about this annoying situation? Excuse me for my bad english. Any help would be appreciated. |
|
Back to top |
|
|
Roman_Gruber Advocate
Joined: 03 Oct 2006 Posts: 3846 Location: Austro Bavaria
|
Posted: Sat Feb 04, 2017 10:11 pm Post subject: |
|
|
Code: | 12.163399] EXT4-fs (sdb1): couldn't mount as ext3 due to feature incompatibilities
[ 12.165818] EXT4-fs (sdb1): couldn't mount as ext2 due to feature incompatibilities |
no ext4 support in kernel?
Quote: | [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/kernel-4.9.0-pf4 root=/dev/sdb1 ro init=/usr/lib/systemd/systemd |
change root to real_root= and to a way which is bootable, e.g. UUID, PARTUUID=. Please refer to the gentoo handbook, arch / gentoo wiki regarding the syntax.
--
Does a live-cd boots? and runs flawless?
--
Quote: | [ 0.000000] DMI: Hewlett-Packard Compaq Presario C700 Notebook PC/30D9, BIOS F.34 09/25/2008 |
fix your bios please
http://support.hp.com/us-en/drivers/selfservice/Compaq-Presario-C700-Notebook-PC-series/3466274/model/3559276
Quote: | F.35 Rev. A 2.1 MB Apr 9, 2010 |
|
|
Back to top |
|
|
acidrums4 Tux's lil' helper
Joined: 05 Feb 2009 Posts: 147 Location: Al otro lado del monitor
|
Posted: Sat Feb 04, 2017 11:21 pm Post subject: |
|
|
Thanks for your kindly answer,
Roman_Gruber wrote: | no ext4 support in kernel? |
Actually there is ext4 support in kernel (if not, it won't even boot at all...). I don't know why that message appears.
Quote: | change root to real_root= and to a way which is bootable, e.g. UUID, PARTUUID=. |
I just did that, but everything is the same. Slow boot and KDE/X/something crashes and goes back to SSDM.
Quote: | Does a live-cd boots? and runs flawless? |
Yes, as I mentioned on OP live-cd boots flawlessly. I tested Fedora, Elementary and a lightweight XFCE distro I can't recall at this moment. ~1 min between BIOS and a loaded desktop.
Quote: | fix your bios please |
Going to do that, but I won't hold my breath...
Thanks again for your answer |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21631
|
Posted: Sun Feb 05, 2017 12:18 am Post subject: |
|
|
OP: you get that ext4 diagnostic because you did not specify the rootfstype, so the kernel tries to guess. After a few guesses, it picks ext4, which works. You could save a fraction of a second if you suppress the guessing, but that is not related to your main problem.
Roman_Gruber wrote: | Code: | 12.163399] EXT4-fs (sdb1): couldn't mount as ext3 due to feature incompatibilities
[ 12.165818] EXT4-fs (sdb1): couldn't mount as ext2 due to feature incompatibilities |
no ext4 support in kernel? | Why would he get messages from the ext4 driver if he had no ext4 driver in the kernel?
Roman_Gruber wrote: | Code: | [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/kernel-4.9.0-pf4 root=/dev/sdb1 ro init=/usr/lib/systemd/systemd |
change root to real_root= and to a way which is bootable, e.g. UUID, PARTUUID=. Please refer to the gentoo handbook, arch / gentoo wiki regarding the syntax. | What do you think is wrong with his current setup, that would be right with your proposed changes? If systemd's analyze blames a systemd service, then the problem must be after the service starts, which cannot happen until after root has mounted, since the service is stored on root. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sun Feb 05, 2017 12:33 am Post subject: |
|
|
acidrums4 wrote: | Actually there is ext4 support in kernel (if not, it won't even boot at all...). I don't know why that message appears. |
This is quite normal when ext4 is enabled to support ext2/ext3 in the kernel. The kernel first tries ext2. it doesn't work so it issues a message and tries ext3. When THAT doesn't work either (because the partition is really ext4 using ext4 features), the kernel issues another message and finally tries ext4 which works so no message. Don't give it another thought. The alternative is clutter your kernel with ext2 and ext3 drivers that you won't ever use. Just disregard the messages. |
|
Back to top |
|
|
acidrums4 Tux's lil' helper
Joined: 05 Feb 2009 Posts: 147 Location: Al otro lado del monitor
|
Posted: Sun Feb 05, 2017 1:03 am Post subject: |
|
|
Yup, I just added Code: | GRUB_CMDLINE_LINUX_DEFAULT="rootfstype=ext4" | to /etc/default/grub and that message is gone. Thanks for your answers.
But that wasn't the reason of this thread: dev-sdb1.service is still taking a ridiculous amount of time on loading... |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sun Feb 05, 2017 2:00 am Post subject: |
|
|
Sorry, can't help with systemd. Good luck! |
|
Back to top |
|
|
Roman_Gruber Advocate
Joined: 03 Oct 2006 Posts: 3846 Location: Austro Bavaria
|
Posted: Sun Feb 05, 2017 6:49 pm Post subject: |
|
|
Hu wrote: | OP: you get that ext4 diagnostic because you did not specify the rootfstype, so the kernel tries to guess. After a few guesses, it picks ext4, which works. You could save a fraction of a second if you suppress the guessing, but that is not related to your main problem.
Roman_Gruber wrote: | Code: | 12.163399] EXT4-fs (sdb1): couldn't mount as ext3 due to feature incompatibilities
[ 12.165818] EXT4-fs (sdb1): couldn't mount as ext2 due to feature incompatibilities |
no ext4 support in kernel? | Why would he get messages from the ext4 driver if he had no ext4 driver in the kernel?
Roman_Gruber wrote: | Code: | [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/kernel-4.9.0-pf4 root=/dev/sdb1 ro init=/usr/lib/systemd/systemd |
change root to real_root= and to a way which is bootable, e.g. UUID, PARTUUID=. Please refer to the gentoo handbook, arch / gentoo wiki regarding the syntax. | What do you think is wrong with his current setup, that would be right with your proposed changes? If systemd's analyze blames a systemd service, then the problem must be after the service starts, which cannot happen until after root has mounted, since the service is stored on root. |
Quote: | But (I really don't know why) the hard disk is now at /dev/sdb, not on /dev/sda. So I had to edit the grub stuff and resume partition path on kernel config to be able to boot. |
My motivation why I suggested to the unique adressing of real_root, aka old root.
I have read the log. Than I decided on which things I had done first.
Thanks for your feedback.
The bios update may fix for a very low chance a few of thse ACPI errors. A better solution is to Fix the DSDT
OFFTOPIC: We all know that systemd is a niche product and therefore hardly anyone has expierence with it, or know how to fix it |
|
Back to top |
|
|
acidrums4 Tux's lil' helper
Joined: 05 Feb 2009 Posts: 147 Location: Al otro lado del monitor
|
Posted: Sun Feb 05, 2017 7:50 pm Post subject: |
|
|
Just an update.
Turns out *part* of this wasn't systemd or BIOS related, but a kernel bug.
Digging into journalctl I found the following creepy line:
Code: | WARNING: CPU: 0 PID: 1768 at drivers/gpu/drm/drm_irq.c:1268 drm_wait_one_vblank+0x200/0x210 [drm]( |
that turned out to be some bug with kernel's old Intel GPU drivers. Its weird because the late HP Pavilion DV2000 and this Compaq C700 have the same video card model (GM965/GL960) but this issue just came to the surface now.
As pointed on this freedesktop.org bug report, a workaround about that is adding "video=SVIDEO-1:d" on kernel boot command.
And voila! Magically the hard drive is back on /dev/sda, and "dev-sda1.device" (aka "dev-sdb1.device") got a more decent time (9.970s).
Now, the thing with KDE loading, allegedly crashing and going back to SDDM login screen and the "Could not start ksmserver. Check your installation" popup still happens. But another line on journalctl seems suspicious and relevant to this:
Code: | "Qt: Session management error: networkIdsList argument is NULL" |
I'm gonna keep looking for this. Thank you all for your help. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|