Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: linux_noob 06. 10. 2015, 09:29:49
-
Zdravim,
nějakou dobu po koupi SSD disku jsem si užíval rychlý boot (Startup finished in 7.449s (firmware) + 2.173s (loader) + 2.688s (kernel) + 2.363s (initrd) + 6.040s (userspace) = 20.715s). Nicméně po několika měsících (mezitím jsem upgradoval distro, ale nemyslím si, že by se problém vyskytl hned po upgradu) používání jsem se dostal na následující čísla (Startup finished in 15.758s (firmware) + 2.901s (loader) + 11.753s (kernel) + 20.835s (initrd) + 2.630s (userspace) = 53.878s), pak po nějakém čase a upgradu kernelu a network manageru jsem se dostal na (Startup finished in 19.186s (firmware) + 2.341s (loader) + 2.675s (kernel) + 31.292s (initrd) + 9.336s (userspace) = 1min 4.830s) kde rozdíl v userspace dělá NetworkManager-wait-online.service (6.969s). Těch 7s bych ještě NetworkManageru nechal, ale fakt nechápu těch 30s v initrd.
Setkal se někdo s něčím podobným? Problém je v tom, že ani nevím do jakých logů bych se měl dívat, abych odhalil kde může být problém, v dmesg během těch 30s nic není, nevím jestli tak má být nebo ne. Taky mě trochu znepokojuje to zpomalení firmwarové části bootu, snad to není nějaký HW problém.
Distribuce Fedora 22 x86_64, windows 8 bootujou pořád stejně rychle, takže s diskem snad problém nebude.
Díky.
-
Zkuste postupně odpojovat vše z čeho se nebootuje. U mě takhle "zlobí" DVD rom.
-
Díky za návrh, ale moc toho nebude :-) Jedná se o notebook, DVD mechaniku jsem nahradil právě tím SSDčkem, takže můžu zkusit odpojit maximálně USB myš a síťovej kabel. Bez HDD bych stejně nenabootoval, protože ho mountuju při bootu.
-
tak jsem zkusil odpojit co se dalo a jedinej výsledek byl ten, že networkmanager doběhl o 1.5s dřív.
-
Pred drahnou let me na laptopu zdrzoval network manager pri sprave wifi sitovky, stacilo ji vypnout a jelo to. Od te doby jsem to na jinem laptopu uz nezazil.
-
journalctl
dmesg
zkuste :
dnf --releasever=23 distro-sync
!!! zatim je to beta !!
me notas s fedorou na SSD startoval porad ve vterinach - a to FC21,22,23 v prubehu asi 5 mesicu, asi to bude nejaka zaludnost ...
-
v tom initrd se mozna kontroluje disk, nejlip by bylo se podivat, tedy hledej jak ve fedore zakazat splashscreen behem bootu
-
Plymouth mám zakázanej.
Btw: koukám do dmesg a journalctl a narazil jsem na zajímavej rozdíl v časech:
dmesg
[ 4.039180] Switched to clocksource tsc
[ 32.714148] random: systemd urandom read with 29 bits of entropy available
journalctl
říj 06 13:01:25 noob-pc kernel: Switched to clocksource tsc
říj 06 13:01:25 noob-pc kernel: random: systemd urandom read with 29 bitže ten čas je z budoucnosti asi bude špatně nastaveným časovým pásmem v biosu, jde mi o relativní rozdíl v časech těch 2 záznamů.
S upgradem na fedoru 23 počkám až bude hotová.
-
v biosu byva ted casovy pasmo? spis jestli mas dobre nastaveny hwclock local a ne ut? (kvuli windowsum)
tak kdyz mas zakazany splash, tak proste koukej, co se pri bootu vypisuje a to uvidis, kde se to zdrzuje 30 sekund v prubehu toho initrd
-
@trubicoid2: Během těch 30s se nevypisuje nic, disk nejeví žádnou aktivitu, ... osobně si myslím, že se někde čeká na nějakej timeout. Až po těch 30s se začnou vypisovat starty služeb. Teď mě teda napadá, že první co se po těch 30s vypíše je výsledek nějaký kontroly disku (tuším root oddíl a ještě něco), ale tu tam mám odjakživa a nikdy mi to problém nedělalo.
-
Neremcej, mezitim si můžeš v initu zahrát systemd-tetris. ;D
-
@trubicoid2: Během těch 30s se nevypisuje nic, disk nejeví žádnou aktivitu, ... osobně si myslím, že se někde čeká na nějakej timeout. Až po těch 30s se začnou vypisovat starty služeb. Teď mě teda napadá, že první co se po těch 30s vypíše je výsledek nějaký kontroly disku (tuším root oddíl a ještě něco), ale tu tam mám odjakživa a nikdy mi to problém nedělalo.
No dobře, tak co je poslední na obrazovce, než se systém na 30s odmlčí? A jak se rozjede, tak to píše co? Pár řádků před a po prostě. Může to čekat na btrfs, lvm, mdadm nebo cryptsetup. Asi by pomohlo přegenerovat initrd
-
@trubicoid: Než se to na 30s odmlčí tak akorát bliká kurzor (_), potom to vypíše výsledek kontroly disku (která by neměla trvat 30s) a začne to spouštět služby. Btrfs, lvm, mdadm ani cryptsetup nepoužívám (nebo o tom aspoň nevím :)). Initrd jsem zkoušel přegenerovat (navíc se stejně generujou pro každou novou verzi kernelu, ne?) a nepomohlo :(
Asi je jasný, že je potřeba nejdřív zjistit co se během těch 30s opravdu děje, bohužel netuším jak. Neví někdo?
-
Nepouziva fedora nahodou systemd? Od te doby, co je systemd v debianu, tak zazivam obcas taky zvlastni chovani pri startech. A logy mlci. Zlate vypisy pri sysvinit.
-
fedora systemd používá.
-
Jakože vůbec nic předtím na obrazovce není? To je divný. Nemáš parametr jádra quiet? To smaž. A loglevel= kolik? Buď smaž, nebo dej 6 nebo 7.
-
jeste muzes nabootovat z liveCD/USB a zkontrolovat ten disk
e2fsck -f -y -D /dev/sda1
jaky mas jadro a jaky SSD? byval problem s mount volbou discard u Samsungu a mozna i jinde, mas to namountovany s discard nebo ne?
mount
-
@trubicoid2: Máš pravdu, měl jsem quiet ;) Tak jsem nastavil loglevel=7, teď už to něco píše i před tou 30s přestávkou, ale stejně se to zasekne na
[ 4.037599] Switched to clocksource tsc, pak těch 30s nic a pak to vybleje spoustu informací, takže z toho stejně nic nevyčtu :(
BTW: jde nějak vypsat přesně to co se vypisuje při bootu?
Kernel 4.1.8, discard zapnutej nemám (volám ručně jednou za čas fstrim), SSD je Crucial MX100 256GB.
-
ad jak vypsat co se vypíše při bootu:
dmesg
případně
dmesg | less
-
@Danny: to nevypíše přesně to co se vypíše při bootu, je tam něco navíc a něco tam zase chybí, např. spouštění služeb.
-
no zbytek je v /var/log/...
taky se hodi bootovat s parametrem init=1, to by se pak nemela smazat obrazovka (nebo musis mit v /etc/inittab ... /sbin/agetty --noclear 38400 tty1 linux)
no vypada to, ze po tom tvym Switching se rezervuje IO a MEM pro pci/ACPI atd., takze mozna jedna periferie ma najednou divny pozadavky? nejde neco v boisu vypnout? nebo si hrat s volbama pci=noacpi, pci=nomsi, pcie_aspm=off, nevim, mozna i pci=off
no a initrd ve fedore dela dracut? to by mohly pomoct parametry jadra rd.debug a rd.udev.debug
tech 30s je nejakej timeout pro udev, tady nasli, ze to dela zrovna modul rtl8192se, ale muze to byt i jinej
https://bbs.archlinux.org/viewtopic.php?id=134012 (https://bbs.archlinux.org/viewtopic.php?id=134012)
-
jeste treba pnpacpi=off
-
Tohle se občas děje, pokud nemáš nainstalovanej firmware pro nějakej HW. Typicky například firmware pro nějakej radeon. Buď je potřeba radeon zkompilovat v jádře jako modul, nebo přidat firmware přímo do jádra, nebo to nacpat do initrd. Nebo ho blacklistnout a nainstalovat proprietální ovladač. (osobně jsem pro ten z jádra, pokud nejsi nějakej hardcore Linux gamer, rozdíl v rychlosti není zásadní a navíc to umožňuje na NB za chodu přepínat grafiky)
-
muzu nekam postnout video, jak fedora startuje - FC23 - 30 sekund z normalniho 2,5" plotnovyho disku
-
@Tuxik: Mám v notebooku radeona a používám svobodný ovladače, už dlouho (tz. předtím než začali tyhle potíže). Ve fedoře je nějakej balík linux-firmware, to je ono ne?
@fedorac: 30s? To sotva vylejzam z grubu :(
@trubicoid2: rd.debug a rd.udev.debug a stejně je po [ 4.037599] Switched to clocksource tsc 30s mezera
-
Ano, linux-firmware by měl obsahovat firmwary k běžnému HW. Jako rychlý test doporučuju jako parametr jádra při bootu zadat
modprobe.blacklist=radeonlogicky ti asi nenaběhne grafika, tak se nelekni, ale uvidíš, jak rychle to nabootuje.
-
jak rika tuxik, tak nejaky firmware by to mohlo byt, ted zjistit ktery no
radeon asi bude modul, ne? po rozjeti X dej lsmod
nebo nemeni se nahodou po tech 30s rozliseni konzole? pouzivas kms? pak ten radeon modul a fw musi byt v initrd
nebo naopak kms zakaz parametrem nomodeset
-
respektive ve tvým případě to vypadá, že buď není radeon zkompilovanej jako modul, ale napřímo do jádra, nebo je modul v initrd a není v něm firmware. Jenom na Fedoru zrovna expert nejsem, tak nevím, jak moc si to pořeší automaticky, nebo jak moc to budeš muset řešit ručně... možná to bude chtít předělat initrd, což se nějak dělá přes dracut, ale víc po mě nechtěj, když u toho nesedím, tak to dohromady nedám.
-
Předtím jsem zkoušel zakázat tu radeonku přímo v biosu a nepomohlo, má teda cenu vůbec zkoušet zakázat ten modul? Rozlišení konzole se nemění, jestli používám KMS to nevím, ale podle tohohle "Kernel mode setting (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default. " asi teda jo, protože mám integrovanou intel hd 4000 grafiku.
-
Normálně v grubu edituj parametry jádra a zkus postupně nebo najednou to nomodeset a modprobe.blacklist=radeon . Za zkoušku nic nedáš nabootuješ, restartuješ a nic se neděje. Co přepíšeš v grubu je jednorázovka, která se nikam neukládá.
-
radeon zakazanej v biosu si linux stejne najde, musi se to zakazovat jinak, bud tim modulem a pak jeste
sudo echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
-
uplne zakazat kartu v linuxu udelas timto parametrem: pcistub="pci-stub.ids=1002:6718"
ty dve cisla ziskas pomoci lspci -nn, cisla v zavorce [] u toho postizeneho zarizeni
kdyby to nakonec radeon nedelal, tak muzes zkusit pokusne zablokovat eth, wlan, nebo co tam jeste mas
-
blacklist radeonu ani nomodeset nepomohl :(
-
zkusil jsem
modprobe.blacklist=ath9k,ath3k,bluetooth,r8169 a pořád nic (akorát už nezdržoval networkmanager :D).
-
tak aspon neco :)
co je vlastne v /etc/dracut.conf ?
-
cat /etc/dracut.conf
# PUT YOUR CONFIG HERE OR IN separate files named *.conf
# in /etc/dracut.conf.d
# SEE man dracut.conf(5)
# Sample dracut config file
#logfile=/var/log/dracut.log
#fileloglvl=6
# Exact list of dracut modules to use. Modules not listed here are not going
# to be included. If you only want to add some optional modules use
# add_dracutmodules option instead.
#dracutmodules+=""
# dracut modules to omit
#omit_dracutmodules+=""
# dracut modules to add to the default
#add_dracutmodules+=""
# additional kernel modules to the default
#add_drivers+=""
# list of kernel filesystem modules to be included in the generic initramfs
#filesystems+=""
# build initrd only to boot current hardware
#hostonly="yes"
#
# install local /etc/mdadm.conf
#mdadmconf="no"
# install local /etc/lvm/lvm.conf
#lvmconf="no"
# A list of fsck tools to install. If it's not specified, module's hardcoded
# default is used, currently: "umount mount /sbin/fsck* xfs_db xfs_check
# xfs_repair e2fsck jfs_fsck reiserfsck btrfsck". The installation is
# opportunistic, so non-existing tools are just ignored.
#fscks=""
# inhibit installation of any fsck tools
#nofscks="yes"
# mount / and /usr read-only by default
#ro_mnt="no"
# set the directory for temporary files
# default: /var/tmp
#tmpdir=/tmp
v /etc/dracut.conf.d není nic.
-
von se tedy bude ridit tim, co mas zablacklistovany v /etc/modprobe.d/
takze ten modul asi v initrd bude, jeste bych zkusil
radeon.modeset=0 rd.driver.blacklist=radeon nomodeset
nebo
radeon.modeset=0 rd.blacklist=radeon nomodeset
nebo ten trik s pci-stub
-
pak se pro jistotu podivej, jestli se radeon predse jen nenatahne (lsmod) a jestli si na firmware nahodou nestezuje
dmesg | grep -i radeon
dmesg | grep -i firm
-
Gůůůglil jsem malinko a zkus parametr kernelu
tpm_tis.force=1
-
noflame ;) Xubuntu 14.04 LTS (No SysTemD)... od enter v grub do nabehle plochy za 6s, za dalsi 2s nm pripoji wifi...
Samsung SSD + CPU i5 2520M (oboje +4roky stare)...
co mas za HW ze i kdyz ti to jelo dle tebe rychle, to bylo pomale jak snek ? :)
-
Gůůůglil jsem malinko a zkus parametr kernelu
tpm_tis.force=1
co to ma za laptop vlastne? ma tpm?
-
Zrovna přemýšlím nad tím, jestli není čas na konec střílení od boku a na začátek seriózního výzkumu... tak třeba výstuo z
uname -aněkam uploadnout komplet výstup dmesg
hodit sem výstup z
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
no a pak se uvidí
-
@nobody: tak jsem to měl taky (+-) než se to rozbilo :(
Notebook je HP ProBook 4540s - i5-3210M CPU, 8GB RAM, AMD Radeon 7650M, SSD jak jsem už psal je Crucial MX100 256GB (zhruba 3-4 měsíce starý). Jestli má tpm nevím.
$ uname -a
Linux noob-pc 4.1.8-200.fc22.x86_64 #1 SMP Tue Sep 22 12:13:21 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
dmesg - http://pastebin.com/TY5uHRgq
-
tpm_tis.force=1 nepomohlo. Navíc se mi zdá, že se ta initrd část pomalu protahuje, teď už jsem na
Startup finished in 17.210s (firmware) + 1.356s (loader) + 2.758s (kernel) + 34.062s (initrd) + 12.567s (userspace) = 1min 7.955s
-
ještě možná lsmod taky asi na pastebin prosím
-
ještě možná... jak se chová fedora... máš k dispozici i starší jádra, nebo jen jedno?
-
lsmod http://pastebin.com/vT136bDb
Nejstarší dostupnej kernel mi to ukazuje 4.0.4. Jinak aktuálně nainstalovaný mám 4.1.6 - 4.1.8.
-
A zkoušel jsi ten starší?
-
hmm ať koukám jak koukám, nic nevidím... ještě zkus parametr jádra
clocksource=hpet
-
Pravdupovediac, este som toto neskusal, ale co tak:
https://wiki.archlinux.org/index.php/Improve_boot_performance
Vyhodou systemd by malo byt moznost debugovat prave takteto problemy...
Co teda napr. pise:
systemd-analyze blame
systemd-analyze critical-chain
?
A nevidno nieco na tomto obrazku
systemd-analyze plot > plot.svg
??
-
Tak radeon tam je, zkus pridat do /etc/modprobe/blacklist.conf
blacklist radeon
Udělej nový initrd a zkus ty parametry, co pisu jako posledni, tj. ty s rd.blacklist=radeon nebo rd.driver.blacklist=radeon
Podle dmesg si ale na firmware nestezuje, mozna teda to je necim jinym.
Mezi modulama vidim mei, to mi blblo na desktopu. Prodluzovalo to boot, ze by stopa? :)
Mam v /etc/modprobe/blacklist.conf
blacklist mei
blacklist mei_me
Novy initrd, mozna parametry jadra, jestli se bude porad v lsmod
-
Jinak hw vypadá, ze nema ipm, tak ho muzes taky blacklistovat, i kdyz to nebude ten hlavni problem, tak usetris milisekundu :)
-
Popravdě jako starýmu Gentooistovi se mi otvírá nožík v kapse, když vidím 100+ načtených modulů... v tom aby se prase vyznalo... osobně bych začal kompilací vlastního jádra na míru, většina lidí nepotřebuje na svým PC provozovat NAT, bridge a další síťařiny, dále je k zamyšlení, jestli používáš IPv6 (pokud máš k dispozici, samozřejmě používej), jestli opravdu používáš na něco paralelní port atd. Ono se to nezdá, ale je to zlomek vteřiny tu, zlomek tam a pak se lidi diví, když mi NB naběhne do sddm za 4 vteřiny a za další 3 vteřiny po přihlášení už mám spuštěný KDE.
Tohle je prostě daň za univerzálnost současných dister, snaží se to běžet na všem, ale nikde pořádně :(
No každopádně znovu koukám do dmesg jak puk a žádnej zásadní problém nevidím :( , zkus starší jádro, případně změnit ten clocksource a pak bych možná zkusil chování nějakýho live distra, ideálně něco založenýho na fedoře?
-
@Tuxik: IPv6 k dispozici většinou mám, paralelní port určitě nepoužívám. Jinak jsem spíš BFU, takže Gentoo asi nebude pro mě.
Jinak vzhledem k tomu, že v dmesg Switched to clocksource tsc, tak bych si myslel, že ta hláška se vypisuje až po přepnutí toho clocksource a tudíž už zdržovat nemůže. Pak by teda muselo zdržovat buď něco co v dmesg není nebo random: systemd urandom read with 34 bits of entropy available
Starší jádro asi nevyzkouším, protože mě ho fedora nenechá nainstalovat. Live distro zkusit můžu, ale tam mě zase bude zpomalovat USB 2.
@monitor: Z toho nic nevyčteš, protože veškerý zdržení je v initrd části bootu a o tý se nic nepíše, v plotu je jenom dlouhá čára, nijak to není rozepsaný.
-
Změna clocksource nepomohla, akorát zmizela ta řádka Switched clocksource ... z dmesg.
-
no sice tě na Live bude zdržovat USB2, ale buď tam bude 30s mezera, nebo ne. Pokud ano, bude to dělat nějaký HW (nemusí být zrovna vadný, třeba jen problém s modulem, nebo cokoliv), pokud ne, zaměřil bych se na verzi jádra a zkusil tam dostat něco jinýho. V Grubu nemáš na výběr víc jader? Pouze nejnovější?
-
@Tuxik: v grubu mam 4.1.6 - 4.1.8, děje se to u všech. Zkusím teda to live distro.
-
Ještě zkus tohle (jako root)
systemd-analyze plot > boot.svga obrázek někam uploadni..
-
@Tuxik: tak mám špatný zprávy, na live distru (fedora 22) to dělá taky, teda v trochu jiný variantě - po switched clocksource to čeká nějakejch 15s na usb ovladače nebo tak něco a pak až to čeká těch 30s na tu řádku s random. Navíc to ještě nakonec ani nenabootovalo (asi proto, že ten oddíl má špatnej label, budu muset opravit).
Jinak jak řikám, na tom plotu není nic vidět, ale když fakt jinak nedáte - http://ulozto.cz/xAtbEyEA/boot-svg (pokuď existuje nějaká rozumná služba na nahrávání obrázků v svg tak jsem ji nenašel :( )
-
No a možná začínáme být doma, oprav label a ještě zkontroluj fstab, jestli tam nemáš nějakej zapomenutej nepořádek, třeba swap, kterej už v systému není? možná můžeš nahodit výstupy
lsblk -o name,mountpoint,label,uuid
cat /etc/fstab
a mohl by být zajímavej možná i grub.cfg
-
@Tuxik: myslel jsem label ty flashky.
$ lsblk -o name,mountpoint,label,uuid
NAME MOUNTPOINT LABEL UUID
sda
├─sda1 [SWAP] 251066fe-187f-424f-a8cd-86f6ad941ca5
├─sda2 /mnt/d 01D076CCCBE71770
├─sda3 /var/lib/mysql 9c5dddb8-5e1e-487b-b1f5-af964c1b8f94
├─sda4 1FA5-AE1A
└─sda5 53267267-c3d9-47cb-9ff1-70be5a97cb4c
sdb
├─sdb1 Recovery 01D0745865E9CE70
├─sdb2 /boot/efi 684E-9970
├─sdb3
├─sdb4 /mnt/c 3A5800A258005ECF
├─sdb5 / 6a51c4df-8a5c-47b2-897e-2b2c0faad42d
├─sdb6 /home f70efa11-33c7-4473-83dc-0d40e99a22a9
├─sdb7 F4E2-2D63
├─sdb8 /boot 6f116b55-cf41-47ca-bf0b-ae89e0c93848
└─sdb9 /mnt/e 01D076CCCE0DEF10
sdc
└─sdc1 UUI 1C06-3B48
$ cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Tue Apr 14 19:28:31 2015
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=6a51c4df-8a5c-47b2-897e-2b2c0faad42d / ext4 defaults,noatime 1 1
UUID=6f116b55-cf41-47ca-bf0b-ae89e0c93848 /boot ext4 defaults,noatime 1 2
UUID=684E-9970 /boot/efi vfat umask=0077,shortname=winnt 0 0
UUID=f70efa11-33c7-4473-83dc-0d40e99a22a9 /home ext4 defaults,noatime 1 2
UUID=251066fe-187f-424f-a8cd-86f6ad941ca5 swap swap defaults 0 0
/dev/sdb4 /mnt/c ntfs defaults,noatime 0 0
/dev/sda2 /mnt/d ntfs defaults 0 0
/dev/sdb9 /mnt/e ntfs defaults,noatime 0 0
/dev/sda3 /var/lib/mysql ext4 defaults 0 0
$ cat /boot/efi/EFI/fedora/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set pager=1
if [ -s $prefix/grubenv ]; then
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="${saved_entry}"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
terminal_output console
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (4.1.8-200.fc22.x86_64) 22 (Twenty Two)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.19.3-200.fc21.x86_64-advanced-6a51c4df-8a5c-47b2-897e-2b2c0faad42d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt8 --hint-efi=hd1,gpt8 --hint-baremetal=ahci1,gpt8 6f116b55-cf41-47ca-bf0b-ae89e0c93848
else
search --no-floppy --fs-uuid --set=root 6f116b55-cf41-47ca-bf0b-ae89e0c93848
fi
linuxefi /vmlinuz-4.1.8-200.fc22.x86_64 root=UUID=6a51c4df-8a5c-47b2-897e-2b2c0faad42d ro rd.lvm=0 plymouth.enable=0 rhgb LANG=cs_CZ.UTF-8
initrdefi /initramfs-4.1.8-200.fc22.x86_64.img
}
menuentry 'Fedora (4.1.7-200.fc22.x86_64) 22 (Twenty Two)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.19.3-200.fc21.x86_64-advanced-6a51c4df-8a5c-47b2-897e-2b2c0faad42d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt8 --hint-efi=hd1,gpt8 --hint-baremetal=ahci1,gpt8 6f116b55-cf41-47ca-bf0b-ae89e0c93848
else
search --no-floppy --fs-uuid --set=root 6f116b55-cf41-47ca-bf0b-ae89e0c93848
fi
linuxefi /vmlinuz-4.1.7-200.fc22.x86_64 root=UUID=6a51c4df-8a5c-47b2-897e-2b2c0faad42d ro rd.lvm=0 plymouth.enable=0 rhgb quiet LANG=cs_CZ.UTF-8
initrdefi /initramfs-4.1.7-200.fc22.x86_64.img
}
menuentry 'Fedora (4.1.6-201.fc22.x86_64) 22 (Twenty Two)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.19.3-200.fc21.x86_64-advanced-6a51c4df-8a5c-47b2-897e-2b2c0faad42d' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt8 --hint-efi=hd1,gpt8 --hint-baremetal=ahci1,gpt8 6f116b55-cf41-47ca-bf0b-ae89e0c93848
else
search --no-floppy --fs-uuid --set=root 6f116b55-cf41-47ca-bf0b-ae89e0c93848
fi
linuxefi /vmlinuz-4.1.6-201.fc22.x86_64 root=UUID=6a51c4df-8a5c-47b2-897e-2b2c0faad42d ro rd.lvm=0 plymouth.enable=0 rhgb quiet LANG=cs_CZ.UTF-8
initrdefi /initramfs-4.1.6-201.fc22.x86_64.img
}
menuentry 'Fedora, with Linux 0-rescue-34162f2703b84209af8437791d8790b9' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-34162f2703b84209af8437791d8790b9-advanced-6a51c4df-8a5c-47b2-897e-2b2c0faad42d' {
load_video
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt8 --hint-efi=hd1,gpt8 --hint-baremetal=ahci1,gpt8 6f116b55-cf41-47ca-bf0b-ae89e0c93848
else
search --no-floppy --fs-uuid --set=root 6f116b55-cf41-47ca-bf0b-ae89e0c93848
fi
linuxefi /vmlinuz-0-rescue-34162f2703b84209af8437791d8790b9 root=UUID=6a51c4df-8a5c-47b2-897e-2b2c0faad42d ro rd.lvm=0 plymouth.enable=0 rhgb quiet
initrdefi /initramfs-0-rescue-34162f2703b84209af8437791d8790b9.img
}
menuentry 'Fedora, with Linux 0-rescue-571a391aa8f94a64a5a58006c226887e' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-571a391aa8f94a64a5a58006c226887e-advanced-6a51c4df-8a5c-47b2-897e-2b2c0faad42d' {
load_video
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt8'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt8 --hint-efi=hd1,gpt8 --hint-baremetal=ahci1,gpt8 6f116b55-cf41-47ca-bf0b-ae89e0c93848
else
search --no-floppy --fs-uuid --set=root 6f116b55-cf41-47ca-bf0b-ae89e0c93848
fi
linuxefi /vmlinuz-0-rescue-571a391aa8f94a64a5a58006c226887e root=UUID=6a51c4df-8a5c-47b2-897e-2b2c0faad42d ro rd.lvm=0 plymouth.enable=0 rhgb quiet
initrdefi /initramfs-0-rescue-571a391aa8f94a64a5a58006c226887e.img
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/20_ppc_terminfo ###
### END /etc/grub.d/20_ppc_terminfo ###
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sdb2)' --class windows --class os $menuentry_id_option 'osprober-efi-684E-9970' {
insmod part_gpt
insmod fat
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 684E-9970
else
search --no-floppy --fs-uuid --set=root 684E-9970
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
swap je tam jenom jeden, tak snad dobrý. sda je HDD, sdb je SSD.
-
Tak se to děje i na ubuntu :( Tady je dmesg z ubuntu - http://pastebin.com/iLksdkw7
-
Jsem normálně ztracenej.... už mě napadá snad jen zkusit vyhodit oba disky a pak zkusit znovu Live z USB...
-
Tonoucí se stébla chytá.
Máš v pořádku /etc/hosts? Jednou mi to dělalo podobné problémy. Systém čekal na timeout když neměl v pořádku hostname -f.
hostname
hostname -f
hostname -a
-
@P@ja: To by nevysvětlovalo proč se to začalo dít z ničeho nic a proč to nejde při bootu z live usb.
@Tuxik: Zkusím, ale pokud by to bylo diskem (nebo nedejbože SATA portem) tak je to stejně docela blbý. Stejně jsem už začínal uvažovat nad upgradem (tak v horizontu půl roku - rok) a teď ještě vyšel Skylake, tak snad budou nějaký dobrý notebooky :)
-
Hele, zkusils zablacklstovat ten mei, jak jsem kousek dozadu navrhoval? Vypada to, ze tvuj notebook to ma, takze je to mozny. Mozna to měl v biosu vypnuty, nebo s updatem. Intel Management Engine Interface = mei
-
@Tuxik: odpojení obou disků (+ baterie, kdyby náhodou) nepomohlo. :(
@trubicoid2: dal jsem to do blacklist.conf, v lsmod už se ani jeden nevypisuje a boot je pořád pomalej.
Asi se holt budu muset spokojit s vysvětlením - blíže neurčená závada hardwaru.
-
asi to teda nebude mei ani radeon no :( jen bych zkusil jeste pregenerovat initrd, do blacklist.conf neni ze zacatku bootu videt, ale měl by se dat do initrd při jeho pregenerovani; pro jistotu jeste pouzit blokovaci parametry jadra
Ten initrd vsechno stejne komplikuje, jako pokus bych dal bez nej, nevim vsak, jestli fedori jadro dojde do zdarneho konce, no aspoň treba by se videlo, jestli bude ta prodleva nebo ne i kdyz se system nakonec nerozjede
No a co postupne blokovat vse z lspci pres ten parametr pci_stub? Tim by se zjistilo, co to je.
-
@Trubicoid2: Zkoušel jsem bootovat bez initrd ale myslím, trvalo to tuším stejně dlouho (ještě zkusím dneska večer). To blokování těch pci zařízení - je to opravdu dobrý nápad? některý asi budu potřebovat ne?
-
to jo, to vetsinu budes asi potrebovat ;)
blokovat jsem myslel je jen docasne, jen abys konecne zjistil, ktery zarizeni to dela; postupoval bych odspodu vypisu lspci, vzdy po jednom
idealni by bylo, kdyz by bez initrd doslo az na shell a tam pomoci lsmod potvrdit, ze prislusny modul se ani nechtel natahnou, ale to mozna neprojde a zkolabuje, protoze nenamountuje root; mozna pomuze parametr jadra root=/dev/sda3 rootfstype=ext4, vono myslim to vsechno ted jede pres initrd a pak fstab, ktery je v initrd a zadny parametr root tam ted nemas, nebo?
-
Popravdě jako starýmu Gentooistovi se mi otvírá nožík v kapse, když vidím 100+ načtených modulů... v tom aby se prase vyznalo...
to je tedy opravdu divny, no; muze to nekdo s fedorou potvrdit, ze to je normalni? 135 modulu mi prijde prehnany, v ubuntu lts vidim ted 72 a to si tam par sam dam; v gentoo mam trebas 3, se zfs 5 :)
neni rozbity nejaky to detekovadlo hardware, co se driv v redhatu jmenovalo snad anaconda?
-
@trubicoid2: Nevím jestli je to normální, ale je klidně možný, že se tam doinstalovali pozdějc s nějakým balastem co jsem si nainstaloval :) Teď jsem zkoušel bootovat bez initrd pomocí root=/dev/sdb5 rootfstype=ext4 a dostal jsem kernel panic že se nepodařilo namountovat :( Tak nevím co jsem udělal blbě, tuším že minule jsem taky nejdřív dostával kernel panic a pak jsem to nějak rozchodil, ale už nevím jak.
Jinak k tomu blokování pco zařízení, stačí teda to předat přes parameter pci_stub=... do kernelu, nebo je ještě něco potřeba? Plánuju to zakázat všechno najednou (kromě těch úplně nejzákladnějších věcí) a pokud to pomůže tak ubírat - např. bez čtěčky SD karet bych se určitě obešel :-)
-
No nevim, ext4 neni modul, tak by to melo jit. Co rika pred panicem?
Ale mozna je to jedno, prodlevu bys mel vidět i tak pred panicem, jen nemuzes udelat lsmod
Jo, i kdyz ja bych to zkousel po jednom :)
Parametr pro tři zařízení: pci-stub.ids=1002:6719,1002:aa80,10de:0392
Čísla z lspci -nn
-
Jeste od jádra 4.1 je tu nový vfio-pci, pry lepsi nez pci-stub?
Mozna zkus vfio-pci.ids=ty cisla
-
Hlavně mi přijde divný, že to dělá i Live a dokonce i jiný distro... kvůli tomu asi nebudu spát... už jsem našel asi milión příčin a řešení v podstatě toho samýho, jedno z nich byl reset BIOSu do dafaultu. Asi bych to ještě zkusil, je to evidentně něco specifickýho pro tvůj stroj, ale nevěřím tomu, že máš nějakej HW problém. To by to něco psalo. Pak je ještě možnost přegenerovat ten initrd, tuším je to
dracut --forcemělo by to snad přegenerovat aktuální, jenom si raději zazálohuj původní. Ještě to má někde konfigurák, předpokládám /etc/dracut.conf tam se dá nastavit, co se do initrd nacpe.
ještě koukám, zkus ještě parametry jádra
rd.shell rd.debugmělo by to snad logovat víc z initrd... možná... jetli už jsi to teda nezkoušel, začínám se v tom ztrácet a už se mi to nechce celý znovu pročítat :D
Jinak osobně jsem zastánce žádnýho initrd (v podstatě jen dyž je někde potřeba bootovat ze SW RAIDu) a kde to jde, žádný moduly. (ono to teda jde taky jen někdy, na NB mám jediný dva moduly, oba na bezdrát). A to se to potom panečku debuguje
# lsmod
Module Size Used by
iwldvm 119965 0
iwlwifi 99243 1 iwldvm
toť vše
-
@Tuxik: rd.debug jsem už zkoušel a nic navíc to v průběhu tý 30s pauzy nevypsalo. Initrd jsem už zkoušel přegenerovat a opět by to nevysvětlovalo proč se to děje i na live distru.
-
No nevim, ext4 neni modul, tak by to melo jit.
Možná nemá v jádře driver pro řadič. Co říká lspci -k?
-
tak jsem zkoušel
linuxefi /vmlinuz-4.1.8-200.fc22.x86_64 root=UUID=6a51c4df-8a5c-47b2-897e-2b2c0faad42d ro rd.lvm=0 plymouth.enable=0 rhgb LANG=cs_CZ.UTF-8 vfio-pci.ids=8086:1e31,8086:1e3a,8086:1e2d,8086:1e20,8086:1e26,8086:1e59,1002:6841,197b:2392,197b:2391,197b:2393,168c:0036,10ec:8168
a neudělalo to nic (patrně proto, že ten modul se nenačetl - po startu není v lsmod). Zkoušel jsem přidat rd.modules-load=vfio-pci a tak nic (to jsem vygooglil, takže nevím jestli je to vůbec správnej příkaz ;))
$ lspci -k
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
Subsystem: Hewlett-Packard Company ProBook 4540s
Kernel driver in use: ivb_uncore
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
DeviceName: 64
Subsystem: Hewlett-Packard Company Device 17f4
Kernel driver in use: i915
Kernel modules: i915
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: mei_me
Kernel modules: mei_me
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 6 (rev c4)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: ahci
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Thames [Radeon HD 7550M/7570M/7650M] (rev ff)
Kernel driver in use: radeon
Kernel modules: radeon
03:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller (rev 30)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: sdhci-pci
Kernel modules: sdhci_pci
03:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller (rev 30)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel modules: sdhci_pci
03:00.3 System peripheral: JMicron Technology Corp. MS Host Controller (rev 30)
Subsystem: Hewlett-Packard Company Device 17f6
Kernel driver in use: jmb38x_ms
Kernel modules: jmb38x_ms
04:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)
DeviceName: WLAN
Subsystem: Hewlett-Packard Company Device 18e3
Kernel driver in use: ath9k
Kernel modules: ath9k
05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
Subsystem: Hewlett-Packard Company Device 17f3
Kernel driver in use: r8169
Kernel modules: r8169
-
Jinak na HW chybu podlě me ukazuje i to, že část bootu ještě před zobrazením HP loga se prodloužila z původních 1-2s na 10-15s (5s mám nastavenou prodlevu na úvodní obrazovce).
-
Mozna nemas modul vfio-pci, zkus ten pci-stub
Ty j-micron bych vsechny zakazal ;D
-
@trubicoid2: modprobe vfio-pci prošel.
-
Možná bych zkusil ten reset BIOSu (nebo co to má) na nějaký výchozí nastavení. Určitě to tam bude mít i nějakou rychlou diagnostiku... pořád se mi nezdá, že by to mělo nějakou HW chybu, ale neřvalo by to nic...
-
Ahci ani ext4 neni v modulech, tak si myslím, ze by to namountovat / melo bez initrd normalne. I kdyz to tedy neni nezbytne
To prodlouzeni bootu před logem je divny, to nebude uplne ok. Nemas v biosu hp diagnostiku? Nebo ve widlach?
-
@trubicoid2: modprobe vfio-pci prošel.
No akorat to uz potom na nic neni, to uz je pozde, po te 30s prodleve. Ty moguly jsou velka otrava ;D
-
Diagnostiku v biosu mám, zkoušel jsem pouštět rychlou (~12 min) a nic to nenašlo. Resetovat nastavení BIOSU můžu zkusit, ale vzhledem k tomu, že to potom nastavím zas úplně stejně nechápu proč to vlastně budu dělat :) Taky nevím jestli pak ještě nabootuju (tuším, že jsem musel nějak příšerně prasit to nastavení, abych vůbec rozchodil UEFI boot pod linuxem, ikdyž možná jsem to pořešil jinak, když jsem přecházel na ssd).
-
Ne ne ne, nic nenastavovat, prostě default. Pokud to nenabootuje, nezoufej, zkus znovu to Live a až pak se kdyžtak vrhni na znovunastavení. Jde o to najít nějakou příčinu divného chování, pokud se u toho rozdrbe víc věcí, dají se pak postupně dořešit.
-
jinak bych se možná na UEFI vykašlal, vypnout to předpokládám ještě jde. Různých bugů v UEFI už bylo tolik, že bych se nedivil ničemu. To mě ještě napadá, update desky jsi zkoušel?
-
To live distro bootuje taky jako uefi nebo normal? Mozna by stalo za to normal live boot, jestli to taky bude blbnout a pak jeste přitom odpojit to podezrely ssd
-
To live distro bootuje taky jako uefi nebo normal? Mozna by stalo za to normal live boot, jestli to taky bude blbnout a pak jeste přitom odpojit to podezrely ssd
tak nějak podobně jsem to myslel. Jinak už jsem fakt asi v koncích... už jsem přečetl půl gůůůglu a podobnej problém se vyskytuje na různých strojích, různých distrech, řešení je snad milión. Stejně za to může SystemD, protože je to satan černý chlupatý smradlavý americký. Ukažme si na něj, může za všechno světové zlo.
Ještě bych zkusil stáhnout Gentoo minimal install, hodit na flashku a nabootovat. Uvidíš, co z toho bude. Nikdy se mi nestalo, že by to někde mělo nějakej problém s bootem (jakejkoliv).
-
Update na firmware pokud vím pro můj notebook není. SSD není podezřelý ;-) Zítra kouknu co to tam vlastně mám nastavený a kdyžtak zkusím resetovat. Ale stejně je divný, že widle bootujou pořád rychle (už proto vylučuju problémy s diskem). Jinak bug v uefi klidně být může, ale pak by se buď neprojevoval při bootu z live (kde je zase kernel 3.19, na kterým to určitě šlo rychle) a projevoval by se odjakživa. Nebo to klidně může být nějaký zabudovaný kurvítko, notebook už mám víc než 2.5 roku, takže už to bezpečně může přestat fungovat ;D
-
Kurvítko to nebude, na to nejsou v Linuxu ovladače, takže není aktivní :D Bude to nějaká strašná kravina... něco dementního, otázka dvou vteřin... jenom vědět, kam sáhnout :(
-
@Tuxik: Může to být časově podmíněná chyba ve firmwaru, určitě by se to dalo udělat tak, aby to vypadalo jako chyba, ale jak říká Microsoft - it's not a bug, it's a feature ;D Navíc pokuď to je nějaká kravina tak co potom to prodloužení doby než se vůbec zobrazí bootovací obrazovka?
-
@Tuxik: rd.debug jsem už zkoušel a nic navíc to v průběhu tý 30s pauzy nevypsalo.
No, a co tak skusit ten rd.shell a rd.debug
a nehladat extra vypisy na obrazovke, ale v logu?
# journalctl -a | less
# dmesg | less
https://fedoraproject.org/wiki/How_to_debug_Dracut_problems
-
Asi to je blbost, ale prece jen, kdyz vsechno ostatni zatim zklamalo: neni tam nekde strcena treba pametova karta, kterou si system snazi osahat a najit na ni filesystem?
-
@monitor: Jak už jsem říkal, rd.debug nepřidal žádnej záznam do tý 30s mezery v dmesg ani v journalctl.
@Pavel Tisnovsky: není a dokonce ani nikdy nebyla :)
Jako ještě bych mohl jít do extrémů a vytahovat jednotlivý ramky, ale myslím, že to už je přehnaný, navíc se z těch notebookovejch slotů docela blbě vyndávaj.
-
no a nebo disketa :-D
-
linux_noob: zkus to ssd vrazit do jineho hw, jak se bude chovat tam ;)
-
@nobody: momentálně nemám k dispozici jinej HW, každopádně selskej rozum říká, že když se to děje i bez něho, tak v něm patrně chyba nebude.
-
@nobody: momentálně nemám k dispozici jinej HW, každopádně selskej rozum říká, že když se to děje i bez něho, tak v něm patrně chyba nebude.
bez nej? si zkusil nabootovat to live a pri tom mit odpojeny ssd? vono je mozny, ze pri bootu z live to ssd nejak bude brzdit, jestli je nemocny, nebo se na nem proveruji ty vselijaky uefi partice, nebo nevim; proste odpojit ssd a zkusit live pro jistotu
-
@trubicoid2: Ano, bez hdd, ssd a baterky a pořád tam byla ta 30s pauza.
-
A nějaké live CD s (výrazně) starším jádrem se zkoušelo?
-
Nebo zkusit live bez Systemd.
-
@Jakub Galgonek: Zkoušel jsem ubuntu 14.04 LTS, který má údajně kernel 3.19, na kterým to ještě určitě fungovalo normálně.
@vitekpin: Můžu zkusit, třeba nějaký starší ubuntu, to by snad mohlo nabootovat i s UEFI.
-
@vitekpin: Můžu zkusit, třeba nějaký starší ubuntu, to by snad mohlo nabootovat i s UEFI.
A co zkusit i legacy boot?
-
@Jakub Galgonek: No to mě *****, fakt to pomohlo. dmesg http://pastebin.com/RWi9wAHW Tak teď mi ale někdo vysvětlete, kde došlo k chybě, když to dřív fungovalo v pohodě? Zkusím ještě asi stáhnout fedoru 21, na který to 100% fungovalo. Nebo že by bylo v tom UEFI fakt nějaký kurvítko? ::)
-
Ještě dodám, že UEFI se rozhodně nezbavím, protože Windows 8 jsou pro mě bohužel nutnost :(
-
WTF pokračuje, teď jsem z live ubuntu nabootoval s UEFI a rychle. dmesg http://pastebin.com/P2QJDte7 (posledních pár řádek s časem 100+ se zalogovalo až po startu).
-
Takže teď už funguje i moje fedora. Nakonec pomohlo přepnout na legacy boot a zase zpátky. Výsledný boot-time
Startup finished in 9.385s (firmware) + 1.867s (loader) + 2.751s (kernel) + 2.044s (initrd) + 9.535s (userspace) = 25.584s
Všímněte si, že se výrazně zkrátilo i čekání ve firmwaru, teď ještě poladit ten NetworkManager, ale to už si snad nějak vyřeším.
Díky všem za pomoc.
-
Hmhmhmmmmm mrkev v zimě... ale hlavně že to jede :)
-
to si teda budu muset poznacit: a zkousel jste uz uefi vypnout a zapnout? ;D
-
UEFI je někde na úrovni IPv6, myšlenka pěkná, ale implementace totálně dovrtaná...