Linux-kysymyksiä & yleistä keskustelua Linuxista

Tänään oli kiirusta ja kerkesin alustavasti vain testaamaan mutta tuolla efibootmgr:lla ja sleep.conf:illa homma toimii unelmasti, ohittaa turhan grubinkin (tosin mulla on vain 2 sekunnin viive laitettu siihen menuun)! Kiitoksia!! Pitää huomenna/vkloppuna katsella tarkemmat toimenpiteet koko hommalle. Löysin tällaisen vielä jossa onkin apu tuohon sleep.conf:in kanssa kikkailuun.

Lopuksi pitäisi vielä keksiä miten voin tehdä skriptin työpöydälle jonka ajamiseen ei tarvita sudoa. Eli jos skripti "~/desktop/Winkkariin.sh" on about tällainen:
Koodi:
#!/bin/bash

sudo /path/to/enable-hibernate-reboot
sudo efibootmgr --bootnext 0004
sudo systemctl hibernate

Miten voin ilman mitään salasanoja käynnistää tuon skriptin? "/etc/sudoers":ia editoimalla? Voiko sinne lisätä vain tuon skriptitiedoston, vai pitääkö lisätä nuo kaikki (/path/to/enable-hibernate-reboot, efibootmgr, systemctl) sellaisiksi että ei kysytä sudoa ollenkaan? Jos vain jotenkin mahdollista niin mieluummin saisi vain tuon "Winkkariin.sh" ilman sudoa käynnistettäväksi.

EDIT: Ilmeisesti tuon saa ainakin tehtyä niin, että tekee vielä toisen skriptin ja kutsuu siinä "sudo Winkkariin.sh" joka siis on sudoers:issa laitettu sallituksi. Ei niin tyylikäs ratkaisu mutta jos toimii..

Käytännön vaihtoehdot taitavat olla
1. kaikki skriptissä käytetyt komennot listattuna sudoers ja käyttö "./sckripti.sh"
2. skripti itse sudoers, komennot sen sisällä ilman sudoa ja käyttö "sudo ./skripti.sh"
 
En saa sudoers hommaa toimimaan. :( Visudo:lla lisäsin tällaisen rivin:

fubar ALL=(ALL:ALL) NOPASSWD: /home/fubar/.bin/hibernate_and_reboot_to_windows.bash

Ja sitten on desktop-kansiossa ajettava tiedosto jossa:
Koodi:
#!/bin/bash
sudo /home/fubar/.bin/hibernate_and_reboot_to_windows.bash

Mutta tuon ajaminen kysyy salasanaa.

Lisäksi aiempaan linkkiin viitaten, en saa tätä osaa toimimaan:

And also, a disable-hibernate-reboot stored at the special folder /usr/lib/systemd/system-sleep:
Koodi:
#!/bin/bash

if [ -f /etc/systemd/sleep.conf.bak ] && [ $1 == "post" ] && [ $2 == "hibernate" ]; then
  mv /etc/systemd/sleep.conf.bak /etc/systemd/sleep.conf
fi

The script in this folder will be run after hibernation with $1="post" and $2="hibernate" (see sleep.conf.d manpage) when resuming from hibernation, thus restoring the old sleep.conf.
Linuxiin paluun jälkeen "sleep.conf.bak" on edelleen tuolla kansiossa ja "sleep.conf":ssa on vain "[Sleep]\nHibernateMode=reboot" joka kirjoitetaan aiemmassa vaiheessa. "disable-hibernate-reboot" on tehty sudolla ja sille on annettu ajo-oikeudet mutta jostain syystä sitä ei ajeta kun tullaan hibernatesta takaisin linuxiin. Ihmeen hankala tämäkin oli vaikka näytti helpoilta ohjeilta.
 
Sudosta en edes ala arvailemaan mitään, mutta syystä taikka toisesta ilmeisesti jotkut distrot odottavat löytävänsä tiettyjä systemd-juttuja /lib/systemd-hakemiston alta tuon /usr/lib/systemd:n sijaan. Eli jos tuolta hakemistosta ei ajeta ja /lib/systemd/system-sleep hakemisto löytyy, niin kokeile siirtää sinne. Ja muista chmod +x.
 
sudon salasana kyselystä pääsee eroon kun laittaa /etc/sudoers tiedoston perään seuraavan rivin:
<user> ALL=(ALL) NOPASSWD:ALL
<user> tilalle oma käyttäjätunnus.
Tämä poistaa sitten salasana kyselyn aina sudoa käytettäessä.
 
Toimiiko skriptin ajo sudon kanssa komentoriviltä? Auttaisko seuraava muutos:
Koodi:
fubar ALL=(ALL:ALL) NOPASSWD: /home/fubar/.bin/hibernate_and_reboot_to_windows.bash
->
fubar ALL=(ALL) NOPASSWD: /home/fubar/.bin/hibernate_and_reboot_to_windows.bash
 
Kannattaa lisäksi alkaa käyttää niitä .d-päätteisiä hakemistoja noihin omien konffien lisäilyyn. Eli älä muokkaa distron asentamaa /etc/sudoers-tiedostoa, vaan tee /etc/sudoers.d-hakemistoon uusi järkevän niminen tiedosto, johon laitat noi omat muutokset. Näin pysyy distron konffikset siistinä ja päivittyvät edelleen automaattisesti. Aika moni palvelu mahdollistaa jo tämän vastaavan tavan.
 
Mielenkiintoista vaan, että kun kovasti on ensin puhuttu tietoturvasta ja joistakin "puutteista" Linuxissa ja nyt sitten halutaan työpöydälle mahdollisuus ajaa skripti root oikeuksilla ilman mitään kyselyjä...
 
Eli jos tuolta hakemistosta ei ajeta ja /lib/systemd/system-sleep hakemisto löytyy, niin kokeile siirtää sinne.
Tämä ratkaisi homman, kiitoksia.

sudon salasana kyselystä pääsee eroon kun laittaa /etc/sudoers tiedoston perään seuraavan rivin:
<user> ALL=(ALL) NOPASSWD:ALL
<user> tilalle oma käyttäjätunnus.
Tämä poistaa sitten salasana kyselyn aina sudoa käytettäessä.
Tarkoitus ei ollut antaa täysiä oikeuksia tehdä mitä vaan. Ainoastaan vain yhden skriptin ajaminen halutaan sallituksi.

Selvisi miksi sudoers:iin laittamani rivi ei toiminut. Lisäsin alunperin rivin "User privilege specification" kommentoinnin ja sen alla olevan root ALL=(ALL:ALL) ALL rivin alle. Jostain kumman syystä tuohon paikkaan kun laittoi mitä vain, vaikka kaikki sallituksi tietylle käyttäjälle, niin se ei toimi jostain syystä. Oman lisäyksen jos laittaa ihan viimeiseksi riviksi niin sitten alkaa toimimaan.

Kannattaa lisäksi alkaa käyttää niitä .d-päätteisiä hakemistoja noihin omien konffien lisäilyyn.
Ja taas opitaan lisää. Kiitos. Teen tuolle sudoers-jutulle tuon ja myös sleep.conf:lle. Katsoin manuaalia ja siellä on listattu näin:
Koodi:
/etc/systemd/sleep.conf
  /etc/systemd/sleep.conf.d/*.conf
  /run/systemd/sleep.conf.d/*.conf
  /usr/lib/systemd/sleep.conf.d/*.conf
Mitähän noista sleep.conf.d-kansioista kannattaisi käyttää? Mitään noista sleep.conf.d-kansioita ei löydy.

Mielenkiintoista vaan, että kun kovasti on ensin puhuttu tietoturvasta ja joistakin "puutteista" Linuxissa ja nyt sitten halutaan työpöydälle mahdollisuus ajaa skripti root oikeuksilla ilman mitään kyselyjä...
"Yhdelle käyttäjälle annetaan lupa ajaa yksi oma skriptitiedosto ilman sudoa jossa vain pari komentoa" vertautuu "monissa *nix:issa kaikkien käyttäjien annetaan lukea kaikkien toisten tiedostot" miten?
 
"Yhdelle käyttäjälle annetaan lupa ajaa yksi oma skriptitiedosto ilman sudoa jossa vain pari komentoa" vertautuu "monissa *nix:issa kaikkien käyttäjien annetaan lukea kaikkien toisten tiedostot" miten?
Kyllä tuossa piilee vaaroja, kunhan vaan ihmettelin, ku niin tarkka muuten on tietoturvasta, mutta oma on koneesi ja saat tehdä niinkuin haluat, eipä mulla sen enempää tästä...
 
Kyllä tuossa piilee vaaroja, kunhan vaan ihmettelin, ku niin tarkka muuten on tietoturvasta
Henkilökohtainen tietoturva on AINA tasapainottelua käytettävyyden ja turvallisuuden välillä. Jos en tuota skriptitiedostoa lähde muuttamaan käsin niin en itse ainakaan tiedosta mitään vaaroja. Onko niitä?
 
Tein ohjeet tuolle "hibernate ja reboottaa windowsiin" hommallle, laitan sen tähän jos jotakuta kiinnostaa. Hibernate pitää olla erikseen säädetty toimimaan (siitäkin tein ohjeen, voin postata senkin jos jotakuta kiinnostaa). Huom! Ohje on markdown-syntaksilla (eli esim. 1 tai 3 backtick-merkkiä ( ` tai ``` ) merkkaa koodia ja niitä ei pidä copypastettaa).

**This has been tested to work with Linux Mint 20 Cinnamon.**

# 1. Create script

Create a new hidden `.bin` folder (if it doesn't exist) in your home folder for script files:

`[[ ! -d "$HOME/.bin" ]] && mkdir "$HOME/.bin"`

Create a new script file in the folder:

`touch "$HOME/.bin/hibernate_and_reboot_to_windows.bash"`

Restrict permissions and set execute permission for the file:

`chmod 0700 "$HOME/.bin/hibernate_and_reboot_to_windows.bash"`

Add the following code to the file:

```
#!/bin/bash

# Configure the system to reboot after hibernate.
# This script is going to be run with root privileges so no sudo is needed.

# Create a folder for the sleep.conf if it doesn't exist yet.
[[ ! -d "/etc/systemd/sleep.conf.d" ]] && mkdir "/etc/systemd/sleep.conf.d"

# Create a new sleep.conf configuration file.
touch "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf"

# Write configuration to the file.
printf "[Sleep]\nHibernateMode=reboot" > "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf"

# Configure system to boot to Windows OS just once.
# Automatically finds the correct boot entry code for Windows.
efibootmgr --bootnext "$( efibootmgr | grep -i windows | cut -c 5-8 )"

# Start hibernate
systemctl hibernate
```


# 2. Sudo permissions for the script

Create a new file that will be imported to sudoers file automatically:

`sudo touch "/etc/sudoers.d/hibernatescript"`

Restrict permissions for the file:

`sudo chmod 0440 "/etc/sudoers.d/hibernatescript"`

Open the file with visudo (always use visudo for editing sudoers files!):

`sudo visudo -f "/etc/sudoers.d/hibernatescript"`

Add the following line (change BOTH "username" strings to your actual username!):

`username ALL=(ALL:ALL) NOPASSWD: /home/username/.bin/hibernate_and_reboot_to_windows.bash`

Save the file with `CTRL+S`, and exit with `CTRL+X`


# 3. Configure system-sleep

Create a new script file to control the `sleep.conf` file created in `hibernate_and_reboot_to_windows.bash` script file:

`sudo touch "/lib/systemd/system-sleep/disable_hibernate_reboot"`

Restrict permissions and set execute permission for the file:

`sudo chmod 0700 "/lib/systemd/system-sleep/disable_hibernate_reboot"`

Add the following code to the file (open file as root):

```
#!/bin/bash

#
if [[ -f "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf" && "$1" == "post" && "$2" == "hibernate" ]]
then
rm "/etc/systemd/sleep.conf.d/hibernate_mode_reboot.conf"
fi
```


# 4. Create a launcher on the desktop

Right-click on your desktop and choose "Create a new launcher here..."

Add the following properties to the launcher (change "username" string to your actual username!):

Name = Boot to Windows
Command = sudo "/home/username/.bin/hibernate_and_reboot_to_windows.bash"

Change the the icon of the launcher by clicking the rocket icon. Search with "microsoft" (without quotes) and select the familiar microsoft windows icon for the launcher.


That's all! Double-clicking the "Boot to Windows" launcher will instantly hibernate linux and boot straight to Windows.
 
Mitenkäs olette ratkaisseet bios-kellon vaihtumisen dual-bootatessa? Windows tykkää käyttää paikallista aikaa, linux UTC:tä. Eli bios:in kello vaihtuu jatkuvasti dual-boottaillessa ja kellonajat käyttiksissä ovat jatkuvasti pielessä. Kumpaan käyttikseen kannattaisi tehdä muutos jotta tätä ei tapahdu. Yritin googlata mutta jotkut sanoo, että säädä windows käyttämään UTC:tä, toiset että säädä linux käyttämään paikallista aikaa. Onko sillä mitään väliä kumpaa kautta fiksaa ongelman?
 
Mitenkäs olette ratkaisseet bios-kellon vaihtumisen dual-bootatessa? Windows tykkää käyttää paikallista aikaa, linux UTC:tä. Eli bios:in kello vaihtuu jatkuvasti dual-boottaillessa ja kellonajat käyttiksissä ovat jatkuvasti pielessä. Kumpaan käyttikseen kannattaisi tehdä muutos jotta tätä ei tapahdu. Yritin googlata mutta jotkut sanoo, että säädä windows käyttämään UTC:tä, toiset että säädä linux käyttämään paikallista aikaa. Onko sillä mitään väliä kumpaa kautta fiksaa ongelman?
Jos distrohoppailet paljon niin on varmaan helpoin tehdä muutos windowssiin niin ei tarvitse jokaisen distron asennuksen jälkeen säätää.
 
Mitenkäs olette ratkaisseet bios-kellon vaihtumisen dual-bootatessa? Windows tykkää käyttää paikallista aikaa, linux UTC:tä. Eli bios:in kello vaihtuu jatkuvasti dual-boottaillessa ja kellonajat käyttiksissä ovat jatkuvasti pielessä. Kumpaan käyttikseen kannattaisi tehdä muutos jotta tätä ei tapahdu. Yritin googlata mutta jotkut sanoo, että säädä windows käyttämään UTC:tä, toiset että säädä linux käyttämään paikallista aikaa. Onko sillä mitään väliä kumpaa kautta fiksaa ongelman?

Jännä, että aina kun näistä etsii tietoa, niin melkein poikkeuksetta paras dokumentti ja ohje tulee vastaan archlinuxin wikistä. System time - ArchWiki
 
Mitenkäs olette ratkaisseet bios-kellon vaihtumisen dual-bootatessa? Windows tykkää käyttää paikallista aikaa, linux UTC:tä. Eli bios:in kello vaihtuu jatkuvasti dual-boottaillessa ja kellonajat käyttiksissä ovat jatkuvasti pielessä. Kumpaan käyttikseen kannattaisi tehdä muutos jotta tätä ei tapahdu. Yritin googlata mutta jotkut sanoo, että säädä windows käyttämään UTC:tä, toiset että säädä linux käyttämään paikallista aikaa. Onko sillä mitään väliä kumpaa kautta fiksaa ongelman?
Mulla on wintous universaalissa ajassa. Ei oo linuxin vika tuollainen ;)
 
Sudosta en edes ala arvailemaan mitään, mutta syystä taikka toisesta ilmeisesti jotkut distrot odottavat löytävänsä tiettyjä systemd-juttuja /lib/systemd-hakemiston alta tuon /usr/lib/systemd:n sijaan. Eli jos tuolta hakemistosta ei ajeta ja /lib/systemd/system-sleep hakemisto löytyy, niin kokeile siirtää sinne. Ja muista chmod +x.

Niin tai siis /lib/systemd kansioon menee kaikki systeemin asentamat rojut eli siis yleensä pakettien ja nämä on sellaisia joita käyttäjän ei tulisi koskaan muutella koska seuraavassa pakettipäivityksessä muutokset suurella todennäköisyydellä katoaa.
Sitä varten on /etc/systemd jonne käyttäjä konffit ja muutokset menee.
 
Niin tai siis /lib/systemd kansioon menee kaikki systeemin asentamat rojut eli siis yleensä pakettien ja nämä on sellaisia joita käyttäjän ei tulisi koskaan muutella koska seuraavassa pakettipäivityksessä muutokset suurella todennäköisyydellä katoaa.
Sitä varten on /etc/systemd jonne käyttäjä konffit ja muutokset menee.

Kyllä, käyttäjän konffit ja overridet menevät /etc/systemd:hen. Mutta kyse olikin system-sleep scripteistä ja ellei Lennart Poettering ole pyörtänyt viimeaikoinaan päätöstään olla tukematta mitään executableja /etc:n alla niin ei ne scriptit siellä paljoa lämmitä.

Vrt. Add support for /usr/local/lib/systemd/system-sleep/ · Issue #4927 · systemd/systemd
 
Kyllä, käyttäjän konffit ja overridet menevät /etc/systemd:hen. Mutta kyse olikin system-sleep scripteistä ja ellei Lennart Poettering ole pyörtänyt viimeaikoinaan päätöstään olla tukematta mitään executableja /etc:n alla niin ei ne scriptit siellä paljoa lämmitä.

Vrt. Add support for /usr/local/lib/systemd/system-sleep/ · Issue #4927 · systemd/systemd

Ja ihan oikeassa se on. Ajettavat tiedostot kuuluu muualle, koska porukka tekee varsin villejä virityksiä kuten noexec mountattua /etc jne...
 
Ja ihan oikeassa se on. Ajettavat tiedostot kuuluu muualle, koska porukka tekee varsin villejä virityksiä kuten noexec mountattua /etc jne...

No, SysV init scriptit ovat aika kauan majailleet /etc/init.d:ssä. Siinä kun mounttailee noexecinä, voipi iskeä masis.
Ei sillä että olisin eri mieltä, mutta systemd lasien läpihan Poettering asian näkee.
 
Jahas, grubista katosi windows-valinta kokonaan. Minttiin tuli jotain grub päivityksiä ja epäilen, että nuo tekivät jotain. Sudolla grub-install ja update-grub eivät palauta/löydä windowsia ollenkaan enää! Onko normaalia tällainen ja miten fiksaus?

EDIT: windowsiin boottaminen kyllä onnistuu, esim. sillä "boot to windows"-säädöllä. Grubiin en vain saa enää windows-valintaa jostain syystä. Vaikea googlettaakin kun tulokset ovat "windows tappoi grubin" eikä tavallaan toistepäin. Kokeilin "os-prober" ja update-grub:ia perään mutta ei. Mintti kyllä näkee windows-osion ja pystyy sen mounttaamaankin nemosta. Koneen bootissa voi F12:lla valita boottimanagerin ja windowsiin pääsee ihan ok. Grubiin ei vain millään saa windowsia.
 
Viimeksi muokattu:
Onko muilla kokemuksia DisplayLink + jonkin sortin erillinen läppärin dock lagaamisesta? Itsellä käytössä Ubuntu 20.04 ja Lenovon T14S + Thinkpadin oma Type-C dock. Tuon kun kytkee kiinni koneen ja näytön väliin niin kuva repeilee älyttömästi ja FPS viskoo 0-60 välillä koko ajan. Windowsilla ei tätä ongelmaa ole ja suoraan yhdistettynä näyttö koneeseen toimii normaalisti. Noista displaylinkin ongelmista on paljon netistä samanlaisia, mutta korjaukset tuntuvat olevan hyvin vähissä. Muuten dock toimii normaalisti.
Kyllä alkaa usko menemään koko Linux touhuun :tdown:
 
Hyvinkin vastaavat kokemukset HP:n telakasta / porttireplikaattorista. Sen kautta kuva pätkii / tulee viiveellä / repeilee ja muutenkin tuo tekele välillä sekoilee. Toisesa koneessa taas on oikea telakka ja se toimii moitteettomasti.
 
Jahas, grubista katosi windows-valinta kokonaan. Minttiin tuli jotain grub päivityksiä ja epäilen, että nuo tekivät jotain. Sudolla grub-install ja update-grub eivät palauta/löydä windowsia ollenkaan enää! Onko normaalia tällainen ja miten fiksaus?

Olen saanut grubin löytämään Windowsin vastaavassa tilanteessa käyttämällä Boot-Repair USB-tikkua.

Käyttöohje täällä:
 
Mistähän vois löytyä syy, että KDE:n radiowidgetit nimeltä Simple Radio Player tai Advanced Radio Player soittaa Fedoralla Radio Rockia osoitteesta:

https://digitacdn.akamaized.net/hls/live/629243/radiorock/master.m3u8 (Löytyy osoitteesta Radio Rock | nettiradio.fi)

Mutta meemidistro Arch ei soita kummallakaan widgetillä tuota kanavaa, eikä mitään muutakaan kanavaa oletuskanavien lisäksi?

Oletuskanavilla ääniasetukset näyttää plasmashellin, mutta kaikilla muilla kanavilla ei näy mitään. Kmixer on mikserinä.

Mitään muuta VLC:llä toimivaa urlia en ole Radio Rockille löytänyt. Onko joku löytänyt?
 

Liitteet

  • Screenshot_20201031_124836.png
    Screenshot_20201031_124836.png
    178,8 KB · Luettu: 27
Jahas, grubista katosi windows-valinta kokonaan. Minttiin tuli jotain grub päivityksiä ja epäilen, että nuo tekivät jotain. Sudolla grub-install ja update-grub eivät palauta/löydä windowsia ollenkaan enää! Onko normaalia tällainen ja miten fiksaus?

EDIT: windowsiin boottaminen kyllä onnistuu, esim. sillä "boot to windows"-säädöllä. Grubiin en vain saa enää windows-valintaa jostain syystä. Vaikea googlettaakin kun tulokset ovat "windows tappoi grubin" eikä tavallaan toistepäin. Kokeilin "os-prober" ja update-grub:ia perään mutta ei. Mintti kyllä näkee windows-osion ja pystyy sen mounttaamaankin nemosta. Koneen bootissa voi F12:lla valita boottimanagerin ja windowsiin pääsee ihan ok. Grubiin ei vain millään saa windowsia.

Ootko kokeillu lisätä Grubiin custom entryä?
 
Tuli itsekin asennettua Fedora x260 Thinkpadiin, en tiedä onko suoraan virallisesti tuettujen listalla, mutta kaikki toimii täysin samantein ilman mitään käyttäjän toimenpiteitä. Ainoa ilkeä vaan, että joutunee asentamaan uusiksi loppuvuodesta, koska Fedora siirtyy virallisesti BTRFS -tiedostojärjestelmään, jolloinka varmuuskopiointikin helpottuu melkoisesti snapshottien muodossa, onnistuuhan tuo nytkin manuaalisesti, mutta virallinen tuki nyt kuitenkin tuo lisää varmuutta toimivuuteen ja ominaisuuksiin...
Silloin myöskin siirtynen takaisin XFCE -työpöytään, asensin ihan default Gnomen nyt tuohon, ku ajattelin pitkästä aikaa kokeilla, josko siirtyisi, mutta ei se vaan maistu meikäläiselle, katsoo ny, muuttuuko mieli tässä syksyn mittaan, ennen uudelleen asennusta. On vaan tuo XFCE niin paljon kevyempi ja omaan silmään kivempi, ku en tarvii mitään animaatio sun muita silmäkarkkeja käyttöliittymään, haluan tehdä sillä hommia...

Ikinä ennen en ole käyttänyt Fedoraa, joten ajattelin sitten kokeilla ja tykästynyt kyllä sen toimintaan. Mukava keskitie Debian stable ja Arch rolling release välillä, eli mukavan tuoretta pakettia vakaassa systeemissä vaikuttaa toimivalta yhdistelmältä.

Toimiiko sormenjäljenlukijakin, jos sulla sellainen on? Mun T580:ssa ei toiminut suoraan ja sen takia siirryin Archiin. Ei Fedorassa ole mitään vikaa, mutta en jaksa opetella dnf:ää.

Fedoran ja Lenovon virallinen yhteistyö on kyllä erittäin iloinen asia. Vielä kun saatais Suomeenkin Fedora vaihtoehdoksi uusiin Thinkpadeihin ja AMD-pohjaisille myös.

Tää podcast on kyllä mainio, harmittavasti se on vaan saanu pirun vähän katsojia.
Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.
 
Mikä on oikea tapa konfiguroida grub(2?):ia käsipelillä? Alustana on Debian Buster, jos sillä on merkitystä.

ZFS-levyjumpassa mm. asennusohjelman ystävällisesti mitään kysymättä luoma EFI-hakemisto jäi jyrän alle ja systeemilevykin on eri SATA-portissa kiinni kuin alussa.

Grub:ssa root-osion oletetaan olevan absoluuttinen (hdN,msdosM) kun se tätä nykyä on (hdX,msdosY). Lisäksi kernelin root-parametri osoittaa osioon, jota ei ehkä ole enää olemassa.

Boottaaminen onnistuu, kun grub:ssa korjaa asetukset käsin. Miten grub-valikon saisi korjattua niin, että boot toimisi automaattisesti? Olisi myös toivottavaa, että initrd- tai grub-päivitykset eivät ylikirjoittaisi omia muutoksia.
 
Mikä on oikea tapa konfiguroida grub(2?):ia käsipelillä? Alustana on Debian Buster, jos sillä on merkitystä.

ZFS-levyjumpassa mm. asennusohjelman ystävällisesti mitään kysymättä luoma EFI-hakemisto jäi jyrän alle ja systeemilevykin on eri SATA-portissa kiinni kuin alussa.

Grub:ssa root-osion oletetaan olevan absoluuttinen (hdN,msdosM) kun se tätä nykyä on (hdX,msdosY). Lisäksi kernelin root-parametri osoittaa osioon, jota ei ehkä ole enää olemassa.

Boottaaminen onnistuu, kun grub:ssa korjaa asetukset käsin. Miten grub-valikon saisi korjattua niin, että boot toimisi automaattisesti? Olisi myös toivottavaa, että initrd- tai grub-päivitykset eivät ylikirjoittaisi omia muutoksia.

/etc/grub.d kautta on se suositus. Ja sitten /etc/sysconfig/grub ja /etc/default/grub
Mutta tää on toki niin distrosta riippuvaista että miten hoidetaan, mutta grub.cfg:ssä ei nykyään muutokset taida monessakaan distrossa kestää kernel päivitystä.

EDIT:Absoluuttiset asemaosoitukset on pahasta, ei pitäisi enää moista tehdä, lisäät yhden levyn tai poistat niin voi hajota koko paska. Conffit olis hyvä tehdä UUID pohjalta.

Toimiiko sormenjäljenlukijakin, jos sulla sellainen on? Mun T580:ssa ei toiminut suoraan ja sen takia siirryin Archiin. Ei Fedorassa ole mitään vikaa, mutta en jaksa opetella dnf:ää.

Mikäs dnf:ssä on ongelmana? Oli siinä toki ittelläkin alkuun hiukan totuttelemista mutta nyt kun on päässy jyvälle niin varsin kätevä ja hyvinkin paljon aikaansaava paketinhallinta johon ihan ok graafinen kikotinkin löytyy.
Itte vetelen mieluummin promptin kautta.
 
Viimeksi muokattu:
Toimiiko sormenjäljenlukijakin, jos sulla sellainen on? Mun T580:ssa ei toiminut suoraan ja sen takia siirryin Archiin. Ei Fedorassa ole mitään vikaa, mutta en jaksa opetella dnf:ää.
Mulla ei ole sormenjälkilukijaa tässä mallissa.

Mikäs dnf:ssä on ongelmana? Oli siinä toki ittelläkin alkuun hiukan totuttelemista mutta nyt kun on päässy jyvälle niin varsin kätevä ja hyvinkin paljon aikaansaava paketinhallinta johon ihan ok graafinen kikotinkin löytyy.
Itte vetelen mieluummin promptin kautta.
DNF on kyllä hyvä paketinhallinta, mutta välillä vaan meinaa hidastella.
Ja hassusti kyl suositellaan päivitykset aina tekemään terminaalissa, eikä tuolla graafisella, mutta softien haku ja asennus kyl voi tehdä sen kautta.

Olen kylläkin siirtymässä OpenSUSEa kokeilemaan, koska pitäisi Fedora asentaa uusiksi, jotta siinäkin pääsisi BTRFS hyötyjä käyttämään. Meinasin kokeilla Tumbleweed rolling release ja katsoa mitenkä se toimii.
 
DNF on kyllä hyvä paketinhallinta, mutta välillä vaan meinaa hidastella.

Hidastelu johtuu varmaan pitkälti siitä miten paljon tarvii riippuvuuksia tarkistella. Ainakin itte huomannut että silloin kun paketissa on paljon riippuvuuksia niin se on sellainen lumipalloefekti että sitten kolutaan läpitte aika paljon tavaraa.

Ja hassusti kyl suositellaan päivitykset aina tekemään terminaalissa, eikä tuolla graafisella, mutta softien haku ja asennus kyl voi tehdä sen kautta.

Varmaan sen takia että se graafinen kikotin ei tunnu tukevan pluginnejä ainakaan kaikkia eli on ns. basic ominaisuuksilla. Tuossa just Fedora 33 ajossa niin huomasin kun kodi on siinä rikki ja käänsin itte vanhemman version ja laitoin version lokkiin sen niin tää graafinen kikotin haluais sitä kovasti päivittää.

Olen kylläkin siirtymässä OpenSUSEa kokeilemaan, koska pitäisi Fedora asentaa uusiksi, jotta siinäkin pääsisi BTRFS hyötyjä käyttämään. Meinasin kokeilla Tumbleweed rolling release ja katsoa mitenkä se toimii.

Susessa oliko se zypper, joskus tullu sitä testailtua, mutta pysyny kuitenkin näissä dnf pohjaisissa. Yhden kun opettelee niin saa ittelle riittää. apt esim. on ittelle ihan kryptinen kikotin, en ole ikinä päässyt sinuiksi sen kanssa. Eniten ihmetyttää kun saman asian tekemiseen on niin monta eri biniä, on apt, apt-get, dpkg ja mitä vielä. Taino onhan fedorassakin dnf ja rpm..
 
Kun otsikko haluaa kysymystä, laitan kysymysmuotoon: Eikös nyt vaan ole kunnollista? Kyllä kelpaa emuloida. Toimii ilmeisesti myös kosketusnäytöillä.

Electron :sick:
Ei kiitos, pitäydyn edelleen URxvt:ssä. Tai ennemmin vaikka XTermissä kuin sotkeudun mihinkään webbikyhäelmään perusasioissa.
 
Ja matka jatkuu linux-maailmassa. Windowsissa on Lenovon oma Vantage ohjelma josta saa akulle "conservation" moodin päälle kun läppäri on verkkovirrassa (lataa akkua vain 55-60%) ja huomasin, että sen kun laittaa päälle niin mintissä lataus myös pysyi samassa (tosin hassusti koko ajan sanoi, että ladataan ja arvio latauksen kestosta vaikka ei ladannut oikeasti). Oikein mukava juttu, paitsi, hibernate/shutdown jotenkin "nollaa" tuon Lenovon asetuksen (samaa ovat jotkin muutkin raportoineet windowsinkin puolella tapahtuvan), eli valmistajan bugi(?). Etsinnässä olisi nyt sitten säätö linuxiin jossa voisi rajoittaa akun latausta. Löysin TLP:n mutta näköjään vain Lenovon Thinkpadeilla toimii TLP:n kautta säädettävä akun "threshold" arvot. "tlp-stat" komennolla "battery features" kohdasta löytyy kaikista kohdista "inactive (laptop not supported)" eli ei onnistu. Olisiko jotain muuta tapaa hoitaa tuo?

Kannattaako tuota TLP:tä asentaa ollenkaan jos noita battery featureita ei ole tuettuna? Onko siitä jotain muuta hyötyä?
 
Olin jo hypännyt uuden haasteen kimppuun kun luulin tuon aiemman ratkenneen. Olen yrittänyt saada toimimaan "suspend then hibernate" toimintoa, on googlattu, luettu archin wikiä ja man:eja mutta en ihan saa finaaliin asiaa. Tein "/etc/systemd/sleep.d/" kansioon uuden .conf-tiedoston ja yritin sitä kautta asiaa saada toimimaan.

Koodi:
[Sleep]
AllowSuspendThenHibernate=yes
SuspendMode=suspend-then-hibernate
SuspendState=mem standby freeze
HibernateDelaySec=10min

Tuo "SuspendMode" säätö estää mintistä suspendin kokonaan, ei näy sammutusvalikossa, ei power optioneissa, eikä esim. läppärin kannen sulkeminen tee mitään.

HibernateDelaySec säätö toimii kyllä, sitä olen testannut terminaalista "sudo systemctl suspend-then-hibernate".

Löysin tällaisen blogitekstin viime vuodelta:
suspend-then-hibernate to the rescue
Well it seems on Ubuntu there is already a service which can achieve this. The service is called suspend-then-hibernate.service. To get this working instead of the normal systemd-suspend.service you need to edit the file /etc/systemd/logind.conf. Change all the suspend triggering keys and switch to suspend-then-hibernate from systemd-suspend (or suspend). Make sure you un-comment those changed keys as well. But that’s comes with one caveat, that is if the system goes to suspend by suspend timeout while you are on battery or if a program triggers the system to go into suspend mode the hibernation will not work since you are invoking systemd-suspend. To get around this you can simply do the following instead of editing the above file,

WARNING: but be sure you know what you are doing.

Koodi:
sudo rm -f /etc/systemd/system/systemd-suspend.service

sudo ln -s /usr/lib/systemd/system/systemd-suspend-then-hibernate.service /etc/systemd/system/systemd-suspend.service

Here you will be remove the default systemd-suspend.service symbolic link and create a new one which point to systemd-suspend-then-hibernate.service. So when ever the system is asked to suspend by running the systemd service systemd-suspend.service it will trigger the systemd-suspend-then-hibernate.service instead.

Now if you want to increase or reduce the time that it takes to hibernate after suspend, You need to create the following file and add the following content.

/etc/systemd/sleep.conf

[Sleep]
HibernateDelaySec=3600
Onko tuo suspend servicen korvaaminen suspend-then-hibernate servicellä järkevää? Voiko tulla jotain ongelmia?
 
Itsellä myös legion peli-lenovo, mint cinnamon. Tuo slimbookin softa näyttäisi käyttävän TLP:tä taustalla ainakin johonkin. Kommenteissa oli jonnin verran ongelmaa raportoitu notta en tiedä otanko käyttöön, joku oli kokeillut, tullut ongelmia ja poistanut ja silti jäi jotain ongelmaa.
 
Onko tuo suspend servicen korvaaminen suspend-then-hibernate servicellä järkevää? Voiko tulla jotain ongelmia?
Unohdin kysyä lisäksi, että onko tuo sellainen säätö jonka joku update voi resetoida? Eli varmaan pitäisi, jos tuota kikkaa on ok käyttää, tehdä päivittäinen cronjobi?
 
Tästä ketjusta varmaan saa vastauksen:

Minulla on eräässä testipenkissä Ubuntu 20.04 LTSB -asennus 250-gigaisella S-ATA HDD:llä. Tuo kovo on jeesuksen aikainen ja ruksuttelee pahaenteisesti toisinaan. Mikä olisi yksinkertaisin tapa kloonata tuo levy A) toiselle samanlaiselle levylle B) uudelle 120-gigaiselle SSD:lle siten, että voin lennosta korvata nykyisen levyn uudella ja homma toimii suoraan, eli on tarkka "peilikuva" nykyisestä levystä? Jos mitään merkitystä, niin emo on joku Asuksen H61-sarjalainen pakettikoneen emo Core i3:lla ja 8 gigalla muistia.
 
Tästä ketjusta varmaan saa vastauksen:

Minulla on eräässä testipenkissä Ubuntu 20.04 LTSB -asennus 250-gigaisella S-ATA HDD:llä. Tuo kovo on jeesuksen aikainen ja ruksuttelee pahaenteisesti toisinaan. Mikä olisi yksinkertaisin tapa kloonata tuo levy A) toiselle samanlaiselle levylle B) uudelle 120-gigaiselle SSD:lle siten, että voin lennosta korvata nykyisen levyn uudella ja homma toimii suoraan, eli on tarkka "peilikuva" nykyisestä levystä? Jos mitään merkitystä, niin emo on joku Asuksen H61-sarjalainen pakettikoneen emo Core i3:lla ja 8 gigalla muistia.
Eikö kannata vaan vetää kotikansiosta backup ja asentaa uusiksi siitä palauttaen?
 
Tästä ketjusta varmaan saa vastauksen:

Minulla on eräässä testipenkissä Ubuntu 20.04 LTSB -asennus 250-gigaisella S-ATA HDD:llä. Tuo kovo on jeesuksen aikainen ja ruksuttelee pahaenteisesti toisinaan. Mikä olisi yksinkertaisin tapa kloonata tuo levy A) toiselle samanlaiselle levylle B) uudelle 120-gigaiselle SSD:lle siten, että voin lennosta korvata nykyisen levyn uudella ja homma toimii suoraan, eli on tarkka "peilikuva" nykyisestä levystä? Jos mitään merkitystä, niin emo on joku Asuksen H61-sarjalainen pakettikoneen emo Core i3:lla ja 8 gigalla muistia.

Melkein lähtisin liikkeelle tekemällä boottaavan Clonezilla USB-tikun ja tutustumalla dokumentointiin. Pitäisi onnistua kumpi tahansa vaihtoehto.
 
Koodi:
dd if=/dev/vanhalevy of=/dev/uusilevy bs=1024k

dd- kopio ei vältämättä toimi suoraan jos on käytetty mountissa levyn uuid:tä, se yleensä vaihtuu levyn mukana.
Ainakin itse olen joutunut päivittämään uuid:t fstabissa ja päivittämään grubin uudelle levylle ennen kuin kone boottaa siltä. Tosin viimeisin klooni on ennen uefi- aikaa, saattaa toimia nykykoneissa eri tavalla.

Samoin jos levyn geometria/blokkikoko on sopivasti eri kuin vanhassa niin saattaa vaatia säätöä.

Viimeksi vaihdoin levyn asentamalla suoraan uudelle levylle (sama käyttisversio) ja sen jälkeen vanhasta tarpeelliset asetukset ja data kopiona uuteen.
 
dd- kopio ei vältämättä toimi suoraan jos on käytetty mountissa levyn uuid:tä, se yleensä vaihtuu levyn mukana.
Ainakin itse olen joutunut päivittämään uuid:t fstabissa ja päivittämään grubin uudelle levylle ennen kuin kone boottaa siltä. Tosin viimeisin klooni on ennen uefi- aikaa, saattaa toimia nykykoneissa eri tavalla.

Itse ainakin mounttaan partitioiden UUID:illa, jotka toki kopioituvat. Ongelmia syntyisi vain siitä, jos pitäisi molemmat levyt samaan aikaan kytkettynä kloonauksen jälkeen.

Samoin jos levyn geometria/blokkikoko on sopivasti eri kuin vanhassa niin saattaa vaatia säätöä.

Toki, mutta kysyjä halusi "tarkkaa peilikuvaa" ja oli mahdollisesti kopioimassa identtiselle perinteiselle levylle. Silloin dd:llä koko devicen kopioiminen on erittäin helppo ja toimiva ratkaisu.
 
Itse ainakin mounttaan partitioiden UUID:illa, jotka toki kopioituvat. Ongelmia syntyisi vain siitä, jos pitäisi molemmat levyt samaan aikaan kytkettynä kloonauksen jälkeen.

Toki, mutta kysyjä halusi "tarkkaa peilikuvaa" ja oli mahdollisesti kopioimassa identtiselle perinteiselle levylle. Silloin dd:llä koko devicen kopioiminen on erittäin helppo ja toimiva ratkaisu.

Tottakai, olem itsekin useasti tehnyt kloonin dd:llä. Mutta mielestäni on aiheellista itse komennon lisäksi muistuttaa siihen mahdollisesti liittyvistä asioista.

Varsinkin kun kysymyksistä ei sina tiedä riittääkö vastaukseksi pelkkä "dd", komentorivi tai pidempi selitys.
Ja olihan tuossa kysymyksessä maininta että toiselle hddlle tai ssdlle jolloin suora dd ei välttämättä ole se oikea...
 
Tässä vielä yksi step by step -ohje, miten tehdään identtinen kopio kovalevystä toiselle levylle linuxin dd-komennolla, mukana runsaasti rautalankaa:
 
Kiitoksia vastanneille, näillä varmasti päästään haluttuun ratkaisuun :)
 
Itsellä myös legion peli-lenovo, mint cinnamon. Tuo slimbookin softa näyttäisi käyttävän TLP:tä taustalla ainakin johonkin. Kommenteissa oli jonnin verran ongelmaa raportoitu notta en tiedä otanko käyttöön, joku oli kokeillut, tullut ongelmia ja poistanut ja silti jäi jotain ongelmaa.
Ai niin. On hyvä olla tuo win2go. Taas oli Bios-päivitys. Mutta sulla tais olla win ja mintti samassa koneessa.
 
Taas oli Bios-päivitys. Mutta sulla tais olla win ja mintti samassa koneessa.
Joo dual-boot. Muuten, vinkkinä, lenovon vantage softan päivitysten haku ei itsellä tarjonnut ollenkaan "Intel Management Engine 12.0 Firmware" päivitystä kun vertailin mitä ajureita windows automaattisesti asensi heti kättelyssä puhtaaseen asennukseen Vs. mitä ajureita Vantage sen jälkeen tarjosi Vs. mitä lenovon tämän läppärin ajurien lataussivulla oli tarjolla. Uusimman biosin BHCN39WW olin kerinnyt asentaa nettisivujen kautta ennen tätä vertailua joten en tiedä olisiko sitä tarjottu vai ei. Vantage löysi vain kaksi Vantageen (edge/gaming jos muistan oikein) liittyvää päivitystä ja GeForce Experience paketin. Windows oli asentanut kaikki muut ajurit ja ne versiot olivat suurimmaksi osaksi samat lenovon sivuilla olevien kanssa, paitsi kolmessa tapauksessa windows oli asentanut uudemman ajurin mitä lenovo tarjosi. Joutuu siis aina välillä kurkkaamaan lenovon sivuilta ne ajurilistat läpi.

/offtopic
 
Viimeksi muokattu:
Onko tuo suspend servicen korvaaminen suspend-then-hibernate servicellä järkevää? Voiko tulla jotain ongelmia?
Palatakseni vielä tähän jos jotain jäi kiinnostamaan, löysin tällaisen ratkaisun asiaan:

Tee uusi tiedosto /etc/systemd/system/systemd-suspend.service.d/override.conf ja sinne sisään:
Koodi:
[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-sleep suspend-then-hibernate
Tuo "systemd-sleep" löytyy mintistä/ubuntusta tuolta, toisissa distroissa voi olla esim. "/usr/lib/..." alla.

Toinen uusi tiedosto (tiedoston nimi omavalintainen kunhan päättyy .conf) /etc/systemd/sleep.conf.d/suspend_then_hibernate_delay.conf ja sisään (jos haluaa 2h suspendin jälkeen hibernaten):
Koodi:
[Sleep]
HibernateDelaySec=2h

Tämän säädön jälkeen aina kun systeemi tekee suspendin (lid close, manuaalisesti, jne.) niin se oikeasti tekeekin suspend-then-hibernate:n.

EDIT: Ja jos olen oikein ymmärtänyt, niin minkään päivityksen ei pitäisi nollata näitä säätöjä.
 
Viimeksi muokattu:

Statistiikka

Viestiketjuista
301 323
Viestejä
5 130 339
Jäsenet
81 972
Uusin jäsen
JM24

Hinta.fi

Back
Ylös Bottom