Riippuu tosiaan siitä moodista. CentOS 8 esim boottaa ihan ok windows uefi moodissa, kun taas Rocky Linux joka on CentOS förkki ei boottaa. Ilmeisesti siis CentOS on RH:lta saanut käyttöön virallisen avaimen. Ja jos windows virtuaalikoneen pykää qemun alle virtio ajureilla niin homma kosahtaa boottiin koska noi julkiset virtio ajurit ei ole virallisella avaimella signattu. Virtio ajurit virallisella signauksella saa vaan maksaneet RHEL käyttäjät.
Eikun perhana, näkyyhän se noin olevan mullakin.OK. Tekeeköhän se tässä Asuksen P8Z77VPro: ssa saman.
Asensin tuon Linuxin kun OS Type oli Windows UEFI mode.
Jos tuon OS Typen vaihtaa Other OS ja tallentaa asetukset, niin Linux kyllä käynnistyy ja kun menee uudestaan katsomaan BIOS: sta BOOT asetuksia, niin tuo Platform Key (PK) on muuttunut "Unloaded", mutta Secure Boot state on edelleen "Enable"
Eli onko tässä Secure Boot päällä vai ei kun OS Type on "Other OS"
Tuon ymmärtämiseksi pitää tietää sellainen juttu, että jos Secure Bootin PK eli Platform Key on tyhjä, silloin voimassa on "Secure Boot Setup Mode", eli firmis kertoo käyttöjärjestelmälle tuntevansa Secure Boot-toiminnot, mutta boottaa silti ihan mitä tahansa, oli siinä pätevä Secure Boot-allekirjoitus tai ei. Tämä on Secure Boot-määrityksen mukainen tila joka on tarkoitettu käytettäväksi siinä vaiheessa kun uusia Secure Boot-avaimia ollaan ottamassa käyttöön: Setup Modessa kaikkia Secure Bootin muita avainvarastoja saa päivittää käyttöjärjestelmästä käsin vapaasti.
Kiitos hyvästä selitykestä! Itse kuulun tähän kategoriaan ja ensimmäinen asia, jonka teen jokaisessa omassa koneessa on 'Secure boot' -> 'Disabled'. Uskoisin, että kukaan Linux käyttäjä ei ole koskaan ollut tilanteessa, että VAU, onneksi sattui olemaan Secure Boot enabloituna.
No, siinä tuli paljon asiaa.
Jos käytät esim VMware Playeria tai muita asioita joissa on omia kernel-ajureita niin suosittelen securebootin laittamista pois päältä, ainakin itselläni jokaisen kernel-päivityksen jälkeen joutuu manuaalisesti allekirjoittamaan vmwaren verkkoajurit joka on pidemmän päälle aika ärsyttävää. Toki itselläni on tuohon jo valmis skripti jonka ajan kernelin päivittämisen jälkeen mutta kuitenkin.No, siinä tuli paljon asiaa.
Varmaan joku tuosta jotain ymmärtää...minä en
Voitko antaa yksinkertaista vastausta kuinka nuo asetukset kannattaisi laittaa ennen Linux Mintin asennusta tässä emolevyssä ?
Näin minulla on ne ollut Windows 10: ssä
1. Launch CSM > Disable.
2. Secure Boot state > enable
3. OS Type > Windows UEFI mode
Launch CSM on syytä jättää Disable-asentoon, tai muuten on riski saada aikaan harmia väärän boottitavan kanssa.
Se että salasanan syöttökehotteeseen kirjoitettaessa näkyviin ei tule mitään on Unix-maailmassa jokseenkin normaali (perinteinen) tapa. Salasana pitää vain kirjoittaa täysin sokkona.
Tämä selvä, pidetään Launch CSM "Disable" asennossa. Niin en ole asentamassa mitään tuplaboottijärjestelmää, vaan tarkoituksena on opetella tätä Linux Minttiä, aikaa ei ole ENÄÄN kun viisi vuotta kun minun koneissani ei "toimi" enään Windows
OK, pidetään mielessä. Minulla on vanhempiakin koneita missä ei ole ollenkaan koko "secure boottia", hyvä tietää että se ei ole välttämätön Linuxillekkaan.
Itse valitsisin tähän kyllä. Oikeasti nykyään tulee käytettyä vain btrfs:ää, mutta LVM on kyllä edelleen ihan käyttökelpoinen verrattuna ihan raakoihin osioihin.
Kotona olevaan, pöytäkoneeseen en laittaisi ikinä salausta käyttöön. Jossain muualla sijaitseva pöytäkone, niin kyllä varmuuden vuoksi ja läppäriin käytön ja oman harkinnan mukaan. Hidastaa konetta kuitenkin ja lisää prossun, levyn ja virrankäyttöä.
Oho, hämmästyttävää !!!
Näyttää ihan vakiolta GRUB- valikolta. Alareunassa näkyy myös kuvan ottohetkellä 13s jäljellä että valittu suoritetaan.Oho, hämmästyttävää !!!
Kiitos tästä tiedosta.
Koitin nyt vielä vastoin asiantuntijoiden suositusta asentaa Linuxin Secure bootissa ja lisäsin tuon LVM: n.
Nyt tuo Enroll MOK meni ilmeisesti niin kuin pitikin, kun sen salasanan TIESIN "ilmaan kirjoittaa"
Mutta nyt jokaisen bootin jälkeen tulee tällainen valikko ennen kuin käyttöjärjestelmä käynnistyy, johtuuko tuo nyt siittä secure bootista tai LVM: stä ?
Toivottavasti kuvasta saa selvää.
Minä olen nyt useamman kerran jo tuon Mintin asentanut tällä viikolla ja nyt viimeisimmän asennuksen jälkeen alkoi tulla tuollainen valikko bootissa.
/etc/default/grub tiedoston GRUB_TIMEOUT=0 ja sitten suorita komento 'update-grub', molemmat toki root käyttäjänä tai käyttäen sudo:a.
Ei ymmärrä.
Vaikuttaa siltä, että joku ylikirjoittaa kyseisen asetuksen, mikä on sinänsä kyllä outoa. Itselle kyllä Linux Mint on kyllä vieraampi distro, joten tähän voi löytyä joku ihan helppokin selitys. Seuraava paikka on sitten ihan käytössä oleva grub.cfg, jos voit postata /boot/grub2/grub.cfg sisällön, niin ihmetellään, että mitä sieltä löytyy.
Eihän siinä GRUB_TIMEOUTin edessä ole risuaitaa? Ja onhan se nolla heittomerkkien sisällä (GRUB_TIMEOUT="0")? Noin se itselläni on ja toimii kuten pitääkin (Mint 20.2). Itse kyllä pitäisin tuon buuttivalikon edes muutaman sekunnin viipeellä. Helpottaa asioita, jos jostain syystä joku kernel-päivitys menee reisille (valikosta voi helposti valita edellisen). Ja aja se sudo update-grub, jos teet jotain muutoksia tuohon tiedostoon.
Molempien pitäisi toimia shellissä normaalisti, mutta lainausmerkit toki silloin jos useampi "sana".
TEST=0
echo $TEST
0
TEST2="0"
echo $TEST2
0Ehdottomasti samaa mieltä! Toki jos haluaa elää reunalla ja chroot ympäristön käyttö on tuttua, niin ei tämä toki välttämätöntä ole...
Muutenkin tulee itse käytettyä suspendia, kun en koneita käytä, joten kyllähän sitä saattaa mennä viikko(ja) ilman boottausta, vaikka kerneli olisikin päivittynyt tässä välissä monta kertaa.Tuo on tosiaan normaali GRUB-boottivalikko, silloin kun ei ole asennettuna mitään erityistä GRUB-teemaa joka tekisi siitä "hienomman" näköisen. Asentamalla jonkin sopivan boottiteeman tuon tilalle saa joko jonkin vakiokuvan/logon tai sitten jopa omavalintaisen kuvan jos viitsii vähän säätää.
/etc/udev/rules.d/10-wakeup.rules tiedoston ja lisäsin sinne ("idVendor" ja "idProduct" poimittu lsusb-komennolla):ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", ATTR{power/wakeup}="enabled"sudo udevadm control --reload-rules (en ole varma oliko tämä pakko tehdä).grep . /sys/bus/usb/devices/*/product näyttää Logitechin usb-pulikalle näin (kun yhdessä ulkoisen monitorin usb-paikassa kiinni):/sys/bus/usb/devices/1-1.3/product:USB Receivergrep . /sys/bus/usb/devices/*/power/wakeup näkee kaikkien wakeup-tilat, esim.:/sys/bus/usb/devices/1-1.3/power/wakeup:disabled
/sys/bus/usb/devices/1-14/power/wakeup:disabled
/sys/bus/usb/devices/1-1/power/wakeup:disabled
/sys/bus/usb/devices/1-9/power/wakeup:enabled
/sys/bus/usb/devices/usb1/power/wakeup:disabled
/sys/bus/usb/devices/usb2/power/wakeup:disabled
/sys/bus/usb/devices/usb3/power/wakeup:disabled
/sys/bus/usb/devices/usb4/power/wakeup:disabledACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b" RUN+="/bin/sh -c 'echo enabled > /sys/bus/usb/devices/1-1.3/power/wakeup'"Näytössä oleva usb hub sotkee hommaa?
Voi olla. Voisiko tätä asiaa jotenkin tutkia jotain kautta? Vai pitääkö tässä vain käyttää tuota kakkoskeinoa ja kirjoittaa siihen skripti joka etsii ja enabloi ainoastaan tietyn vendor&product id:n omaavat laitteet.. vähän purkka ratkaisu, mieluummin selvittäisin miksi ensimmäinen keino ei toimi ulkoisen monitorin usb-porttien kanssa.
Tuommoisen tiedoston koneestani löysin, tällaistako tarkoitit ?
Taitaa kyllä sellainen olla minulla edessä näihin koneisiin, missä BIOS: ssa ei saa hiljennettyä tarpeeksi.
GRUBissa on joku "recordfail" toiminto joka näyttää valikon 30 sekuntia ainakin virhetilanteissa. Tuota voi säätää lisäämällä
/etc/default/grub tiedostoon rivin esim. GRUB_RECORDFAIL_TIMEOUT=2 (lopuksi vielä sudo update-grub komento editoinnin jälkeen!). Itsellä on tuo ja GRUB_TIMEOUT laitettu molemmat kahteen sekuntiin. Itsellä hibernate toiminnon kanssa voi tulla joskus "Acpi hardware changed while hibernated success doubtful" viestiä/tilannetta (vaikka hibernate toimii ihan ok) ja se aktivoi tuon GRUBin "recordfail" toiminnon.Siis tuo 30 sekunnin kesto on joku virhetilanne, uudessa asennuksessa...?
Koodasin sitten tällaisen ratkaisun. Laitan tähän jos sattuisi jotakuta kiinnostamaan.
/etc/udev/rules.d/10-wakeup.rules (idVendor ja idProduct kohtaan hae oikeat arvot lsusb komennolla):ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b" RUN+="/bin/bash -c '/path/to/script/udev_wakeup_rule.bash'"sudo udevadm control --reload-rules/path/to/script/udev_wakeup_rule.bash sisälle seuraavat rivit (tänne myös oikeat idVendor ja idProduct arvot, ja muista muuttaa myös execute permissionit tiedostolle):#!/bin/bash
while IFS= read -r -d '' var
do
if [[ "$( grep -s . "$var/idVendor" )" == "046d" \
&& "$( grep -s . "$var/idProduct" )" == "c52b" ]]
then
echo enabled > "$var/power/wakeup"
fi
done < <( find "/sys/bus/usb/devices/" -maxdepth 1 -mindepth 1 -type l -print0 )Itse en ole GRUBin sielunelämään kovin paljon tutustunut joten en osaa tarkemmin kertoa. Mutta jos haluat muuttaa valikon odotusaikoja niin voit muuttaa molempia
GRUB_TIMEOUT ja GRUB_RECORDFAIL_TIMEOUT asetuksia.OK, mutta taitaa ainakin toistaiseksi jäädä minulta säätämättä.
Linuxissa tämä pitää tehdä komentorivillä, etenkin siihen asti, että emolevy ja tuulettimet on tunnistettu.
github.com
Komentorivi tulee olemaan Linux maailmassa "ystävä", oikeastaan kaikki muu onnistuu suoraan komentoriviltä, paitsi webbiselailu kunnon kuvilla.
Tätä enemmän tai vähemmän sivuten, huutelen täältä viereisestä pöydästä ihan yleisenä huomiona että jos suunnittelee Linuxiin siirtymistä niin kannattaa (jatkossa ainakin) katsoa etukäteen mitä rautaa koneeseen laittaa. Emolevyvalmistajille riittää että Windows toimii jotenkuten, pääsääntöisesti muuta tukea ei edes mainita, tai jos mainitaankin markkinointimateriaalissa niin sen arvo on 0. Tai oikeastaan negatiivinen koska saattaa antaa kuvan toimivuudesta.
En tiedä enään kuinka, mutta sain pari päivää sitten tuulettimienkin kierrosnopeudet näkymään tuolla "komentorivillä" myös paljon muitakin lämpöantureita tuli näkyville. Kone niitä tuulettimia testasikin, laittoi ne täydelle nopeudelle ja testasi millä arvoilla ne pysähtyy.
Niin kai.
Pidetään mielessä, vaikka kun seuraavan kerran uutta rautaa ostan, niin kyllä siihen tulee erittäin todennäköisesti Windows. Ainakin tällä hetkellä tämä Linux tuntuu aivan käsittämättömältä. Firefox selaimen osaan aukaista.
Merkillistä. Mikä emo se on ?
Prime x470-PRO.
Asenna lm-sensors-niminen paketti ja aja sudo sensors-detect.
Ymmärtääkseni tuo lm-sensors paketti on siellä, kun sitä ei voi tuolta "Ohjelmistohallinnasta" muuta kuin poistaa ja sen kohdalla on tuollainen vihreä merkki. Mutta ei näy tuulettimia kun ajaa sudo sensors-detect.
No juu toki niinkuin @Juha Uotila tuossa mainitsikin, niin varmasti ilman komentoriviäkin selviää. Todellisuudessa siinä ei ole mitään sen kummallisempaa, kuin käyttöliittymissäkään, jotkut asiat on vaan huomattavasti näppärämpi hoitaa komentorivillä.
Vastailitko niihin kysymyksiin YES/NO ?
Kyllä vastailin, olen sen tehnyt jo moneen kertaan, joskus vastailin kaikkiin YES ja joskus painelin vain Enteriä. En tiedä mitä silloin kerran tein, että sain ne tuulettimet näkyville.
Ei näy muita kuin muutamia lämpötiloja.
Kysymyksessä on isoilla kirjaimilla se vaihtoehto jota käytetään jos vain enter.
OK, minä myös.
Näyttääkö siinä outputissa, että olisi tunnistanut emolevyn?
Siis kun tuon sudo sensor-detect käynnistää, niin kyllä siinä heti alussa näkyy emolevyni ja prossuni.
Entäs sen jälkeen Success! ja Yes rivit ja tämä kohta:
Now follows a summary of the probes I have just done.
Just press ENTER to continue:
Driver `coretemp':
* Chip `Intel digital thermal sensor' (confidence: 9)
Driver `nct6775':
* ISA bus, address 0x290
Chip `Nuvoton NCT6791D Super IO Sensors' (confidence: 9)
Do you want to overwrite /etc/conf.d/lm_sensors? (YES/no): YESSiis kun olen ajanut sen sudo sensor-detect ja vastannut kaikkiin "yes" niin minulla tuo kohta on tällainen
sudo modprobe coretemp nct6775sudo dmidecode -t 2
